[PATCH] D35994: Debug info for variables whos type is shrinked to bool
Hal Finkel via llvm-commits
llvm-commits at lists.llvm.org
Tue Aug 1 10:18:31 PDT 2017
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>
More information about the llvm-commits
mailing list