[PATCH] D35475: [PATCH] [GVN] Ensure replacement instruction dominates its uses

Pedro Ferreira via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 17 08:35:31 PDT 2017


PFerreira added a comment.

I set a breakpoint in the R->moveBefore(I) which I added and this was the block in question:

  L.LB1_346:                                        ; preds = %L.LB1_423
    %6 = sext i32 %1 to i64
    %7 = mul i64 %6, 4
    %8 = getelementptr i8, i8* null, i64 %7
    %9 = bitcast void (...)* @poisn2_ to void ([...])*
    call [...]
    %.pre = sext i32 %1 to i64
    br label %L.LB1_350

The way I debugged this was to track the creation of the "%.pre" instruction. This led me to "GVN::performScalarPREInsertion". I set a breakpoint in that function and it gets hit before the BasicBlock above has a chance to go through "processBlock" (during iterateOnFunction). Hence the %7 has not been found yet (not yet in the leader list). This violates the assumption in performScalarPREInsertion, as you stated before (I think) which is documented by the comment in that function:

  // Because we are going top-down through the block, all value numbers
  // will be available in the predecessor by the time we need them.

Thus "%.pre" gets created.
The iteration order doesn't process %7's parent block due to a loop.

Does that make sense?


https://reviews.llvm.org/D35475





More information about the llvm-commits mailing list