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

Tue May 10 14:24:55 PDT 2016

On Tue, May 10, 2016 at 12:28 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:

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

Not quite following there.

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

Yeah, probably not a bad place to start/incremental progress, etc.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/bccad83b/attachment.html>