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

[Hal Finkel via llvm-commits]

On 08/01/2017 11:54 AM, Adrian Prantl wrote:
>
>> On Aug 1, 2017, at 9:42 AM, Hal Finkel <hfinkel at anl.gov 
>> <mailto:hfinkel at anl.gov>> wrote:
>>
>>
>> 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.
>
> Are you saying the two values may be arbitrary values and not only 0 
> and 1?

Yes, I believe that's correct.

  -Hal

>
> -- adrian
>>
>>  -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
>

-- 
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/9c81a117/attachment.html>