[PATCH] D25611: When moving a zext near to its associated load, do not retain the origial debug location.

[Andrea Di Biagio via llvm-commits]

andreadb added a comment.

In https://reviews.llvm.org/D25611#570583, @andreadb wrote:

> In https://reviews.llvm.org/D25611#570512, @danielcdh wrote:
>
> > But to fix the debug info problem in the given test case, it's better to fix it the place closest to the problem, which is ISel. (I do not mean that the CGP fix in this patch is wrong, it's worth fixing too)
> >
> > In the generated assembly, we did not see the zext instruction, there is only one movl instruction.
>
>
> <snip>
>
> > Both MOV32rm and SUBREG_TO_REG are attributed to !dbg !8, while MOV32rm should be attributed to !dbg !7 instead. In this way we will not see line 6 attributed to the movl instruction.
>
> That's very interesting. I agree that the problem could have been avoided if only the MOV32rm had the correct line associated. On x86 that SUBREG_TO_REG is effectively a noop copy from GR32 to GR64. I will definitely investigate further to figure out what is going on here.


So, I further investigated on this.
It turns out that the reason why we get the same line for the MOV32rm  and the SUBREG_TO_REG is because the DAGCombiner triggers the following rule:

  (zext (load x))  --> zextload x

The new zextload node obtains the debug location from the zext. So, we end up with a zextload associated to line 6. Later on, ISel matches the zextload as the sequence  MOV32rm + SUBREG_TO_REG.
However, at this point we have lost the information that the original load was from line 3. The debug location used for the two nodes after ISel is the same as the debug location from the zextload.
That is why we end up with the two line 6 instructions.


https://reviews.llvm.org/D25611