[NFC][CodeGenPrepare] Match against the correct instruction when checking...

[NFC][CodeGenPrepare] Match against the correct instruction when checking profitability of folding an address

The "nested" `AddressingModeMatcher`s 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.

Reviewed By: mkazantsev

Differential Revision: https://reviews.llvm.org/D143896