[PATCH] D68209: [LiveDebugValues] Introduce entry values of unmodified params
Djordje Todorovic via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 23 04:13:51 PDT 2019
djtodoro added a comment.
@jmorse Thanks for the comments!
> With that in mind, this code makes sense. My understanding of what's happening here is that whenever there's a register-copy-transfer, if it's from an entry-value-location then DebugEntryVals map records the transfer destination. Then, if another DBG_VALUE for the same variable is encountered specifying the same destination, it's interpreted as being caused by the register-copy, and so entry values can be propagated over it.
That is right.
> I think what's missing is handling of control flow branching / merging. As far as I can see, DebugEntryVals is a single map, that gets updated whenever a block is processed. If we had a standard diamond control flow like this:
> entry:
> setcc %somereg
> jnz block2
> block1:
> mov %rax, %rcx
> jmp exit
> block2:
> mov %rcx, %rdx
> jmp exit
> Then the reverse-post-order order that LiveDebugValues follows will mean it visits blocks in the order {entry, block1, block2, exit} [1]. Isn't there a risk that changes to DebugEntryVals when processing block1, will be visible / will affect the handling of block2?
That could be a problem as well as tracking of clobbering of the register holding the copy of the debug entry value. I work on that as well as on a NFC that should simplify the code a bit.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D68209/new/
https://reviews.llvm.org/D68209
More information about the llvm-commits
mailing list