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

[Hal Finkel via llvm-commits]

On 08/01/2017 11:28 AM, Adrian Prantl via llvm-commits wrote:
>
>> On Aug 1, 2017, at 9:24 AM, David Blaikie <dblaikie at gmail.com 
>> <mailto: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.

No, it is more complicated than that. See TryToShrinkGlobalToBoolean in 
lib/Transforms/IPO/GlobalOpt.cpp. It is looking for cases where the 
global is only set to one initialized value and one other value. In that 
case, it can make a Boolean global and replace uses of that Global with 
selects over that value. I think you actually want to generate a DWARF 
expression for these.

  -Hal

>
> 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
>>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170801/1e6f6ff8/attachment.html>