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

Tue May 10 12:28:52 PDT 2016

On Tue, May 10, 2016 at 11:45 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Mon, May 9, 2016 at 4:42 PM, Peter Collingbourne <peter at pcc.me.uk>
> wrote:
>
>>
>>
>> On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, May 9, 2016 at 3:38 PM, Peter Collingbourne <peter at pcc.me.uk>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, May 9, 2016 at 3:17 PM, Peter Collingbourne <peter at pcc.me.uk>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, May 9, 2016 at 2:33 PM, David Blaikie <dblaikie at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, May 9, 2016 at 1:53 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.
>>>>>>>>
>>>>>>>
>>>>>>> It looks like this is how debug info for static data members used to
>>>>>>> look until r172591 landed back in 2013.
>>>>>>>
>>>>>>
>>>>>> Could you explain more what you mean by "<this> is how it worked
>>>>>> until" - 'this' being how it used to work and how you're proposing to make
>>>>>> it work? I'm not quite following.
>>>>>>
>>>>>
>>>>> Sorry, I meant that prior to r172591 we would represent a static data
>>>>> member with something that looked like what a DIGlobalVariable looks like
>>>>> today, but with a ConstantInt representing the initializer in the variable
>>>>> field (which is where the GlobalVariable is normally stored). The change
>>>>> moved the initializer to an associated "static member type" (yes, it's not
>>>>> really a type), which as a side effect caused us to (as far as I can tell)
>>>>> no longer store ConstantInts in the variable field.
>>>>>
>>>>
>>>> Actually this isn't accurate, we still produce a ConstantInt in the
>>>> variable field of DIGlobalVariable for constants in the global scope (e.g.
>>>> test/CodeGen/2010-08-10-DbgConstant.c in clang). I'll have to think more
>>>> about what the right representation is for that then.
>>>>
>>>
>>> Looks like this might be broken/have regressed at some point:
>>>
>>> static const int x = 3;
>>> void f1(int);
>>> void f2(int*);
>>> void f3() {
>>>   f1(x);
>>>   f2(&x);
>>> }
>>>
>>> Now we generate two global variables named 'x', one with a constant
>>> value, the other with an address.
>>>
>>> We probably only want the one with the address. (but, then again, we
>>> probably want to turn the one with an address to having a constant value if
>>> its storage gets optimized away)
>>>
>>
>> Thanks David. I was thinking about this representational change for
>> DIGlobalVariable:
>>
>> 1) replace the Variable field with a Value field of type ConstantData,
>> and use it exclusively for constant initializers
>> 2) change the logic in the debug info emitter
>> (DwarfCompileUnit::getOrCreateGlobalVariableDIE) to look like this:
>>
>> if (the DIGlobalVariable was attached to a GlobalVariable) {
>>   // add a location to the variable DIE
>> } else if (the DIGlobalVariable has an associated value) {
>>   // add a constant to the variable DIE
>> }
>>
>> It seems that this way we would be able to do "emit an address, or a
>> constant if optimized away" if we modify clang to emit a single
>> DIGlobalVariable for constant globals with an appropriate initializer, and
>> add it to the list of globals in the DICompileUnit.
>>
>
> Something like that sounds plausible.
>
> Though it seems a minor pity if we have to carry the value (albeit null)
> in all the non-optimized cases.
>

Yes, though I suppose that if it mattered we could change globaldce to pull
the initializer out of the constant when it removes a constant.

Also when optimized away to a constant we might still want to keep the link
> inverted so we don't re-emit the same constant global variable into every
> CU that uses it (nor have to import it multiple times, etc). So we could
> have a separate named metadata node that just lists all the constant
> globals and they point back to their respective CU and that list can be
> uniqued when linking.
>
> But I don't know how much any of it matters, how much work it'd be, etc.
>

Yes, this is essentially what I was mentioning in my mail yesterday to
Adrian. I think that as a first step we can keep the globals list on the CU
and move it to separate named metadata if it makes sense/is sufficiently
beneficial.

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