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

[David Blaikie via llvm-commits]

On Tue, Aug 1, 2017 at 9:04 AM Adrian Prantl via Phabricator <
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).

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.

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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170801/dd77ddcf/attachment.html>