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

[Peter Collingbourne via llvm-dev]

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.

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