[PATCH] D23283: Debugging of optimized code: When locals have their address taken as part of a call use their stack slots as location expressions for debug info.

[Wolfgang Pieb via llvm-commits]

wolfgangp added a comment.

In https://reviews.llvm.org/D23283#510083, @aprantl wrote:

> Thanks!
>
> Why does this need to be restricted to "simple" derefs? I understand that it's easier to convince ourselves that a single DW_OP_deref is correct, but do you have a counterexample where checking whether the first opcode in the expression is a deref would not be correct?


No, I don't have a counterexample, but this was conservatively directed at locals that have their address taken as part of a call, based on code in LowerDbgDeclare() in Local.cpp that explicitly generates a single DW_op_deref in that case. It may be possible to improve on it, but I haven't had time to look at any more complex examples yet.

> I haven't checked the code yet, but maybe you already know the answer: Does this also work if the variable has more than one value? If the FrameIndexDbgValue also gets lowered into DBG_VALUE we should be fine. If it ends up as a stack slot entry in the MMI table the following example should break:

> 

>   int foo(bool c) {

>     int i = 0;

>     if (c)

>       i = 1;

>     else

>       bar(&i)

>     return i;

>   }

> 


The frameindex is preserved in the DBG_VALUEs, the actual stack slot doesn't get assigned until the PrologueEpilogueInserter/Frame Finalization pass, so I think from that point of view it's fine, but your example actually does not benefit from the change. It does what it used to do, i.e. generate an indirect reg+0 DBG_VALUE. I have to check why.


https://reviews.llvm.org/D23283