[PATCH] D35994: Debug info for variables whos type is shrinked to bool

[Adrian Prantl via llvm-commits]

> On Aug 1, 2017, at 9:24 AM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Tue, Aug 1, 2017 at 9:04 AM Adrian Prantl via Phabricator <reviews at reviews.llvm.org <mailto:reviews at reviews.llvm.org>> wrote:
> aprantl added inline comments.
> 
> 
> ================
> Comment at: lib/Transforms/IPO/GlobalOpt.cpp:1577
> +  for(auto *GV : GVs)
> +    NewGV->addDebugInfo(GV);
> +
> ----------------
> NikolaPrica wrote:
> > aprantl wrote:
> > > I'm not familiar with this transformation: Do we need to add a DIExpression to mask out all but the first bit (i.e. can multiple bools be packed into the same uint32_t such that it could confuse debuggers)?
> > The debug info which is provided here with addDebugInfo later generates address of the variable (DW_OP_addr: xxxx) in DW_AT_location. If we provide here metadata which is for 1byte variable  the debugger would get confused because the enum type is written as 4-byte and he would try to read 4 bytes. This is just temporary fix until proper way to handle this is found.
> If I understood you correctly then the best way to represent this would be a `DW_OP_LLVM_fragment /*offset*/0 /*bitsize*/1 (or 8?)`
> expression. This will get lowered into a DW_OP_bit_piece to tell the debugger that this location is describing of the first n bits of the variable.
> 
> A slight problem with this is that at least GDB won't print a single value if it's partially unavailable (eg: if it's a struct and the fragment describes one member but not the othe,r I think that's OK - but if it's a single int and only one out of 4 bytes are described - well, the value is known/unknowable).
> 

A debugger would have to print the value as something like 0x??????01 to indicate that pieces are missing. But no debugger I'm aware of does that.

> If this optimization is really based on the proof that the other bytes are unused, never written to or read, then a fragment describing the other bytes as constant zero would be good to have as well.

Agreed, that would be the most practical solution — if we can prove that it is correct.

-- adrian
> 
> But I doubt that's the case - no doubt if we can see all the reads and writes, we optimize away the writes if we know they won't be read, so we may end up with only the one byte. C'est la vie.
> 
> Just mention it to check/understand what the optimization is/isn't doing, etc.
>  
> 
> 
> https://reviews.llvm.org/D35994 <https://reviews.llvm.org/D35994>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170801/edb6bf9c/attachment.html>