ScalarEvolution can't find iteration count without tail duplication #1473
Comments
|
This makes sense. The tail duplication pass does "loop rotation". This moves the exit condition from Before: Loop: After: if !condition goto Out without this transformation, it is significantly harder to determine the trip count of the loop. |
|
Also, specifically answering your question, it's not safe to disable those checks. Doing so makes the trip In this specific case, it would also be safe to check to see if the loop exit block is the loop header. I'll |
|
urg, due to recent bytecode format changes, I can't read your .bc files. Can you please attach a .ll file for Thanks, -Chris |
|
I figured out my own testcase. Testcase here: Patch here: -Chris |
* [flang][driver] Extend support for LLVM IR/BC files Before this change, `clangDriver` (i.e. the compiles driver library) would always use `clang` to compile LLVM IR or LLVM BC files (even when `flang-new` was used to invoke the driver). With this change, Flang will finally accept LLVM IR and LLVM BC alongside e.g. Fortran input files. This means that from now on it is up to the user to decide whether to use Flang or Clang to compile an LLVM file (`flang-new -c file.bc` and `clang -c file.bc`, respectively). To complement this, support for generating LLVM BC files is added. This requires the `BitcodeWriterPass` pass to be run on the input LLVM IR module and is implemented as a dedicated frontend aciton. The new functionality as seen by the user: 1. LLVM BC file generation (`flang-new -c -emit-llvm file.90` or `flang-new -fc1 -emit-llvm-bc file.f90`) 2. Ability to consume LLVM IR and BC files and to lower them to object files (`flang-new -c file.bc` or `flang-new -c file.ll`) The new behaviour is consistent with `clang` and `clang -cc1`. * [flang][driver] Add support for `-save-temps` This patch adds support for `-save-temps` in `flang-new`, Flang's compiler driver. The semantics of this option are inherited from Clang. The file extension for temporary Fortran preprocessed files is set to `i`. This is identical to what Clang uses for C (or C++) preprocessed files. I have tried researching what other compilers do here, but I couldn't find any definitive answers. One GFortran thread [1] suggests that indeed it is not clear what the right approach should be. As `-save-temps` makes the compiler run every phase separately, in Flang one currently has to use it with `-fno-integrated-as`. Otherwise, an invocation to the integrated assembler driver is generated (i.e. something equivalent to `clang -cc1as` from Clang), but this is not yet implemented in Flang. [1] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=81615 * Add missing llvm-dis dependency * Add MacOSX to the list of supported OSes The PR for this branch was reverted due to failures in our MacOS CI. I'm enabling support for MacOS to verify that this is sufficient for the tests to pass. * Simplify test
Extended Description
Hi, the TOT llvm can't find the iteration count without tail duplication, I
guess it's caused by the following code in
ScalaEvoluation.cpp:
// Currently we check for this by checking to see if the Exit branch goes to
// the loop header. If so, we know it will always execute the same number of
// times as the loop. More extensive analysis could be done to handle more
// cases here.
if (ExitBr->getSuccessor(0) != L->getHeader() &&
ExitBr->getSuccessor(1) != L->getHeader())
return UnknownValue;
I need to disable tail duplication because it changes a while loop to a do-
while loop by moving the exiting branch to the end of the loop body.
I attached two files: (1) foo.bc : a simple loop without tail duplication
(2) foo.taildup.bc: a simple loop with tail duplication. I ran "opt -indvar" on
these two files, llvm failed to find trip count on the first example; but if I
comment those three lines, it works fine and report the correct iteration
count. Based on my understanding, those checking are not necessary since
scalarevoluation works normally even the checking fails.
Thanks.
The text was updated successfully, but these errors were encountered: