[PATCH] D45637: [DebugInfo] Ignore DBG_VALUE instructions in PostRA Machine Sink

[Bjorn Pettersson via Phabricator via llvm-commits]

bjope added a comment.

In https://reviews.llvm.org/D45637#1130313, @mattd wrote:

> @bjope , Thanks for your review and example!   I agree that any changes to improve performSink/collectDebugValues should probably be in another patch.
>
> I agree, after spending some time with your hypothetical case, I can imagine there are some other cases that might result in old/intermediate values in the user's variable, at least for a short period of time.
>
> In https://reviews.llvm.org/D45637#1129560, @bjope wrote:
>
> >   ...
> >   renamable $eax = COPY $edi
> >   DBG_VALUE debug-use $eax, debug-use $noreg, !14, !DIExpression(), debug-location !16
> >   $esi = ADD $edi, 7
> >   DBG_VALUE debug-use $esi, debug-use $noreg, !14, !DIExpression(), debug-location !17
> >   ...
> >   
>
>
> Excuse me if I am getting this wrong, the following is my interpretation of your example.   Let's assume this example lives in bb0.   In the example, sticking with x86_64, the ADD (or ADD32ri) instruction expects tied physical registers, something like `$edi = ADD32ri $edi, 7`  However, that case would prevent the COPY from sinking, I'm guessing due to a register def.  If we were to make this `$esi = ADD32ri $esi, 7`, that would allow for the COPY to be sunk.  Variable !14 would truly be $esi +7 at that program point in bb0, because the DBG_VALUE you introduced will associate $esi as the value for !14.  The sunken copy, presumably in bb1, would be the value copied from $edi, and probably the value that a user would expect.  Single stepping from the ADD to the sunken COPY would show !14 as being an intermediate or 'old' value until the sunken copy is reached.  This doesn't seem wrong to me.  It just could present unexpected values to the user, when inspecting !14 between the ADD and sunken COPY. Perhaps, if we were to delete just the DBG_VALUE associated to the  ADD  in bb0 ,  perhaps that would encourage a debugger to present 'optimized-out' in this case. I agree with you, any refinements to performSink or collectDebugValues should probably be for another patch.  Thanks again for your review.


I think you got it (even though I see the value from "debug location !16" as the old value, so by reordering the DBG_VALUE statements it will look like the variable first gets the value from "debug location !17" and then the value from "debug location !16", which could be the opposite from what is expressed in the source code that we debug).

Btw, the "ADD" was just an example. We can even skip the "ADD" and make the DBG_VALUE refer to a constant value:

    ...
  bb.0:
    $edi = "load variabel !14"
    renamable $eax = COPY $edi
    DBG_VALUE debug-use $eax, debug-use $noreg, !14, !DIExpression(), debug-location !16
    <some code allowing the COPY to be sunk past this>
    DBG_VALUE i32 555, debug-use $noreg, !14, !DIExpression(), debug-location !17
    ...
  bb.1:
    ....

let's say this origins from C code like this

  int var14 = X;           // Some stack allocated variable
  ...
  int tmp = Var14;     // location !16
  ...
  Var14 = 555;           // location !17
  if (<some cond>) {
    bar = tmp;
    <code block A>
    return;
  }
  ...

My concern was more about what value var14 (that is !14) will appear as having in <code block A>. If we reorder the DBG_VALUE instructions, then !14 might appear as having the old value X in <code block A> (even if we have stepped past both location !16 and !17).


https://reviews.llvm.org/D45637