[PATCH] [LCSSA] Handle PHI insertion in disjoint loops

Chandler Carruth chandlerc at gmail.com
Mon Dec 15 11:19:40 PST 2014


REPOSITORY
  rL LLVM

================
Comment at: lib/Transforms/Utils/LCSSA.cpp:97
@@ -96,2 +96,3 @@
   SmallVector<PHINode *, 16> AddedPHIs;
+  SmallPtrSet<PHINode *, 8> PostProcessPHIs;
 
----------------
Rather than a set pointing into AddedPHIs, just keep a list? We don't put PHI nodes into AddedPHIs more than once, so there is no need for set logic, just a separate list for the ones needing post-processing?

================
Comment at: lib/Transforms/Utils/LCSSA.cpp:136-137
@@ +135,4 @@
+
+    // LoopSimplify might skip to simplify some loops (e.g. when indirect
+    // branches are involved). In such situations, it might happen that an exit
+    // for Loop L1 is the header of a disjoint Loop L2. Thus, when we create
----------------
I would say "LoopSimplify might fail to simplify some loops (...)."

================
Comment at: lib/Transforms/Utils/LCSSA.cpp:139
@@ +138,3 @@
+    // for Loop L1 is the header of a disjoint Loop L2. Thus, when we create
+    // PHIs in one of such exits we are also inserting PHIs in L2 header. This
+    // could break LCSSA form for L2 because these inserted PHIs can also have
----------------
"PHIs in such an exit block, we are also inserting PHIs into L2's header." reads a bit better to me.

================
Comment at: lib/Transforms/Utils/LCSSA.cpp:141
@@ +140,3 @@
+    // could break LCSSA form for L2 because these inserted PHIs can also have
+    // uses in L2 exits. Remember all PHIs in such situation as to revisit than
+    // later on.  FIXME: Remove this if indirectbr support into LoopSimplify
----------------
"can also have uses outside of L2."? It doesn't matter where the uses are, the key is that we're inserting a loop value in the form of a PHI node in the header.

================
Comment at: lib/Transforms/Utils/LCSSA.cpp:182-192
@@ -164,2 +181,13 @@
+
+  // Post process PHI instructions that were inserted into another disjoint loop
+  // and update their exits properly.
+  for (auto *I : PostProcessPHIs) {
+    BasicBlock *PHIBB = I->getParent();
+    Loop *OtherLoop = LI->getLoopFor(PHIBB);
+    SmallVector<BasicBlock *, 8> EBs;
+    OtherLoop->getExitBlocks(EBs);
+    if (EBs.empty())
+      continue;
+    processInstruction(*OtherLoop, *I, DT, EBs, PredCache, LI);
   }
 
----------------
Add a comment that we specifically recurse here?

Note that I can probably blow out the stack here with a suitably horrible crafted IR: simply set up a chain of loops such as this that is arbitrarily long. It's pretty contrived, but at least leave a FIXME that we should really convert this entire thing to a worklist approach where we process a vector of instructions...

http://reviews.llvm.org/D6624

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list