[llvm-dev] RFC: metadata attachments for global variables

[David Blaikie via llvm-dev]

On Fri, May 6, 2016 at 2:14 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:

>
>
> On Fri, May 6, 2016 at 2:10 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>>
>>
>> On Fri, May 6, 2016 at 2:09 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, May 6, 2016 at 1:55 PM, Peter Collingbourne via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>>
>>>>
>>>> On Fri, May 6, 2016 at 1:21 PM, Duncan P. N. Exon Smith <
>>>> dexonsmith at apple.com> wrote:
>>>>
>>>>>
>>>>> > On 2016-May-06, at 13:17, Peter Collingbourne <peter at pcc.me.uk>
>>>>> wrote:
>>>>> >
>>>>> > Hi all,
>>>>> >
>>>>> > I'd like to add support for metadata attachments for global
>>>>> variables in the same way as we did for functions.
>>>>> >
>>>>> > Syntax would be pretty simple:
>>>>> > @foo = global i32 0, !foo !0, !bar !1
>>>>> > (the extra commas are required to disambiguate from a named metadata
>>>>> on the next line)
>>>>>
>>>>> SGTM.
>>>>>
>>>>> > Benefits:
>>>>> > 1) Lets us reverse the DIGlobalVariable -> GlobalVariable edge,
>>>>> which should hopefully clear the way for removing the llvm.dbg.cu
>>>>> named metadata node.
>>>>>
>>>>> A little harder than it sounds (need to somehow support a
>>>>> GlobalVariable that is RAUW'ed with a ConstantInt), but I think this is
>>>>> important to do.
>>>>>
>>>>
>>>> How can a GlobalVariable be replaced with a ConstantInt? Wouldn't that
>>>> just be an absolute address?
>>>>
>>>
>>> If the global variable has a known constant value & the address is never
>>> needed, then we might optimize away the storage and still want debug info
>>> describing the constant.
>>>
>>
>> I'm not sure under what conditions, if any, that currently works - so
>> this may be more of a "nice to have" or "be good to think about how any
>> future design wouldn't preclude fixing this gap" sort of thing.
>>
>
> I see. This does seem a lot like something like macro expansions where the
> entity doesn't have a direct correspondent in the IR.
>

Ish - macros disappear in the frontend, so, yes, when we're preserving them
we just attach them to the CU.


> So perhaps any pass that would want to preserve debug info in such a case
> could call some utility function that would move the DIGlobalVariable to (I
> suppose it would have to be) some named metadata node to which we'd attach
> things like macro expansions.
>

Yep, something like that. But many passes might just blindly RAUW loads of
the pointer to the global with the constant & then the global just quietly
disappears due to lack of use (probably some cleanup path). But this seems
to already be happening today - Duncan, do you know any cases where we do
successfully describe a global via a constant value that would be the value
of the global, not its address? My simple cases just seemed to lose the
location entirely if the constant's storage was optimized away.

- David


>
> Thanks,
> --
> --
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160506/69c17834/attachment.html>