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

Tue May 10 15:28:23 PDT 2016

On Tue, May 10, 2016 at 3:03 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> On May 9, 2016, at 4:42 PM, Peter Collingbourne via llvm-dev <
> llvm-dev at lists.llvm.org> 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
>
>
> I would prefer a DIExpression field for holding the constant value.
> Besides it being generally useful; if we use a constant, GlobalOpts will
> believe the constant to be dead and remove it.
> Such as the problem with ASAN GEPs outlined in
> http://reviews.llvm.org/D18109.
>

Would that work though? Unless I'm misunderstanding something, the
DIExpression would appear as a DW_AT_location attribute on the global
variable, which would tell the debugger how to calculate its address. But
if the global has no address we would instead need a DW_AT_const_value
attribute to represent the value, wouldn't we?

Peter

-- adrian
>
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>

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