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

Tue May 10 17:03:31 PDT 2016

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

>
> On May 10, 2016, at 3:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>
>
>
> 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?
>
>
> What I’m envisioning is that we would have a DIExpression(DW_OP_constu,
> <the constant value>, DW_OP_stack_value), which we then could either
> directly emit as DWARF 5 or translate into a DW_AT_const_value in the Dwarf
> backend for better compatibility and more efficient encoding. This way we
> don’t need to fear the optimization passes, and get to use complex
> expressions on global variables.
>

I see, I wasn't aware of DW_OP_stack_value. Yes, I suppose that could work,
thanks.

Peter

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

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