The "nested" AddressingModeMatchers in
AddressingModeMatcher::isProfitableToFoldIntoAddressingMode are constructed
using the original memory instruction, even though they check whether the
address operand of a differrent memory instructon is foldable. The memory
instruction is used only for a dominance check (when not checking for
profitability), and using the wrong memory instruction does not change the
outcome of the test - if an address is foldable, the dominance test afects which
of the two possible ways to fold is chosen, but this result is discarded.
As an example, in
target triple = "x86_64-linux" declare i1 @check(i64, i64) define i32 @f(i1 %cc, ptr %p, ptr %q, i64 %n) { entry: br label %loop loop: %iv = phi i64 [ %i, %C ], [ 0, %entry ] %offs = mul i64 %iv, 4 %c.0 = icmp ult i64 %iv, %n br i1 %c.0, label %A, label %fail A: br i1 %cc, label %B, label %C C: %u = phi i32 [0, %A], [%w, %B] %i = add i64 %iv, 1 %a.0 = getelementptr i8, ptr %p, i64 %offs %a.1 = getelementptr i8, ptr %a.0, i64 4 %v = load i32, ptr %a.1 %c.1 = icmp eq i32 %v, %u br i1 %c.1, label %exit, label %loop B: %a.2 = getelementptr i8, ptr %p, i64 %offs %a.3 = getelementptr i8, ptr %a.2, i64 4 %w = load i32, ptr %a.3 br label %C exit: ret i32 -1 fail: ret i32 0 }
the dominance test is perfomed between %i = ... and %v = ... at the moment
we're checking whether %a3 = ... is foldable
Using the memory instruction, which uses the interesting address is "more
correct" and this change is needed by a future patch.