[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