[PATCH] D68209: WIP: [LiveDebugValues] Introduce entry values of unmodified/modified params

Jeremy Morse via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 3 03:07:26 PDT 2019


jmorse added a comment.

Hi Djordje,

Djordje wrote:

> [...] due to various LLVM optimizations, a variable’s value could be just moved around from one register to another (and there will be additional DBG_VALUEs describing the same variable), so we have to recognize such situation (otherwise, we will lose a lot of entry values) and salvage the debug entry value.

The chain of patches I have in D67393 <https://reviews.llvm.org/D67393> / D67398 <https://reviews.llvm.org/D67398> / D67500 <https://reviews.llvm.org/D67500> could be useful here -- the DBG_VALUEs that LiveDebugValues inserts for transfers can cause other problems, and in those patches I've attempted to delay their creation until after LiveDebugValues is finished. In particular, from the summary of D67398 <https://reviews.llvm.org/D67398>,

I wrote:

> previously VarLocs could effectively build long chains where the MI field referred to the previous transfer DBG_VALUE, eventually rooted in a [non-transfer] DBG_VALUE. Now, however, VarLocs can only ever refer to the [non-transfer] DBG_VALUE, which I think is slightly neater

This means that whenever a transfer is created by transferRegisterCopy, no DBG_VALUE is created, instead a VarLoc is created that points back to the "original" DBG_VALUE. If I understand you correctly (75% confidence), with those patches you would be able to identify whether a location is the entry value by examining the VarLoc's MI field, even if the location has been transferred in the meantime.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68209/new/

https://reviews.llvm.org/D68209





More information about the llvm-commits mailing list