llvm dev - May 2016 - RFC: metadata attachments for global variables

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>

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.

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.

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

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>

> 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
<mailto:dblaikie at gmail.com>> wrote:
> 
> 
> On Mon, May 9, 2016 at 3:38 PM, Peter Collingbourne <peter at pcc.me.uk
<mailto:peter at pcc.me.uk>> wrote:
> 
> 
> On Mon, May 9, 2016 at 3:17 PM, Peter Collingbourne <peter at pcc.me.uk
<mailto:peter at pcc.me.uk>> wrote:
> 
> 
> On Mon, May 9, 2016 at 2:33 PM, David Blaikie <dblaikie at gmail.com
<mailto:dblaikie at gmail.com>> wrote:
> 
> 
> On Mon, May 9, 2016 at 1:53 PM, Peter Collingbourne <peter at pcc.me.uk
<mailto:peter at pcc.me.uk>> wrote:
> 
> 
> On Fri, May 6, 2016 at 2:10 PM, David Blaikie <dblaikie at gmail.com
<mailto:dblaikie at gmail.com>> wrote:
> 
> 
> On Fri, May 6, 2016 at 2:09 PM, David Blaikie <dblaikie at gmail.com
<mailto: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 <mailto: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 <mailto:dexonsmith at apple.com>> wrote:
> 
> > On 2016-May-06, at 13:17, Peter Collingbourne <peter at pcc.me.uk
<mailto: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
<http://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.
-- 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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/1b8a3eb2/attachment-0001.html>

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>