[PATCH] D23911: [SimplifyCFG] Change the algorithm in SinkThenElseCodeToEnd

Hans Wennborg via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 29 14:32:13 PDT 2016


hans added inline comments.

================
Comment at: lib/Transforms/Utils/SimplifyCFG.cpp:1351
@@ +1350,3 @@
+  // stores, check the only user of each is a PHI or in the same block as the
+  // instruction, because if if a user is in the same block as an instruction
+  // we're contemplating sinking, it must already be determined to be sinkable.
----------------
"if if"

================
Comment at: lib/Transforms/Utils/SimplifyCFG.cpp:1369
@@ -1431,3 +1368,3 @@
     };
     if (!all_of(Insts, SameAsI0)) {
       if (I0->mustOperandBeConstant(OI))
----------------
I'm still wondering how this code knows that I0 and I have the same number of operands. It looks like it assumed this before too. What am I missing?

The situation I was thinking off was calls with different number of arguments. Are we just getting lucky because of the "Don't create indirect calls" below?

If we assume the instructions have the same number of arguments, we should assert it, and otherwise we should bail. I suppose.

================
Comment at: lib/Transforms/Utils/SimplifyCFG.cpp:1489
@@ +1488,3 @@
+  // each block upwards in lockstep. If the n'th instruction from the end of each
+  // block can be sunk, those instructions are added to ValuesToSink and we
+  // carry on. If we can sink an instruction but need to PHI-merge some operands
----------------
maybe rename ValuesToSink to InstructionsToSink?

================
Comment at: lib/Transforms/Utils/SimplifyCFG.cpp:1496
@@ +1495,3 @@
+  DenseMap<Instruction*, SmallVector<Value*,4>> PHIOperands;
+  while (PopulateInsts(ScanIdx) &&
+         canSinkInstructions(Insts, PHIOperands)) {
----------------
calling PopulateInsts with an increasing index like this is O(n^2). Maybe it doesn't matter much in practice (since n is number of sinkable instructions, large n would be rare?)

Would it be very impractical to just do a single reverse iteration over all the blocks instead of starting over from the back each time?


Repository:
  rL LLVM

https://reviews.llvm.org/D23911





More information about the llvm-commits mailing list