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

[Bjorn Pettersson via Phabricator via llvm-commits]

bjope added a comment.

Basically looks good to me now, as I think that getting rid of the debug-invariant problem is important.
When it comes to the sinking of DBG_VALUE instructions I believe that will be as good as the pre-RA version of MachineSinking. I think that could be enough to land this (as getting rid of the debug-invariance probably is more important).

It is probably easy, at least by hand, to write some MIR-tests that show that the sinking of DBG_VALUE instruction could be more complicated in general, compared to what performSink currently can handle.
I'm thinking about something like this:

  ...
  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
  ...

In the above code code the variable !14 is given a new value after the ADD. Afaict the performSink method (or actually collectDebugValues) simply decides to sink all DBG_VALUE instructions that is using $eax when sinking the COPY defining $eax. But if we sink the first DBG_VALUE past the second DBG_VALUE it will look as if the variable will get the old value when single-stepping past the sunken COPY. I'm not sure, but I don't think that it should be like that.

I think that performSink should look at other DBG_VALUE instructions to see if they refer to the same variable, and if so probably drop the DBG_VALUE (unless it can be salvaged in some way) instead of sinking it. Although I'm not sure how common code patterns like the one above are in reality. Maybe we can improve performSink in a later patch.


https://reviews.llvm.org/D45637