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

> On May 6, 2016, at 3:48 PM, Adrian Prantl via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
>> 
>> On May 6, 2016, at 3:40 PM, Mehdi Amini <mehdi.amini at
apple.com> wrote:
>> 
>> 
>>> On May 6, 2016, at 3:17 PM, Adrian Prantl <aprantl at
apple.com> wrote:
>>> 
>>> 
>>>> On May 6, 2016, at 1:17 PM, Peter Collingbourne via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>> 1) Lets us reverse the DIGlobalVariable -> GlobalVariable
edge, which should hopefully clear the way for removing the llvm.dbg.cu named
metadata node.
>>> 
>>> Not to spoil all the fun, but I’m not sure if this will bring us
much closer to removing the llvm.dbg.cu node. The reason the llvm.dbg.cu node
exits is so we can find all DICompileUnits, because the DICompileUnit holds
debug info that is not referenced by any IR. This includes things like
DIImportedEntity (think C++ “using”), enums, and macros.
>> 
>> I understand the fact that DICompileUnit holds debug information that
are useful and not referenced directly from the IR.
>> 
>> What I wonder is, after all edges are pointing from the IR toward the
metadata graph, why do you need to keep a compile unit (and the associated
retained informations) if nothing in the IR (transitively) points to this
compile unit? (i.e. it is unreachable from the IR)
> 
> Couple of examples:
> - because the compile unit could contain definitions for an enum that is
useful during expression evaluation
> - because it contains constants that are useful (XNU for example has this
version.c file:
http://opensource.apple.com/source/xnu/xnu-1456.1.26/config/version.c).
> - When clang compiles debug info for a module it compiles an otherwise
empty CU with debug info for all types in the module.
- (something we recently discussed on cfe-commits for better supporting
dtrace/ctfconvert) because the frontend implemented a -gfull option that added
all types to the CU’s list retained types.
> -- adrian
> 
>> -- 
>> Mehdi
>> 
>> 
>>> We will also need a story for preserving DIGlobalVariables that are
constants and have their GlobalObject optimized away. We can definitely remove
all the global variables that are referenced from GlobalObjects’ !dbg
attachments from the DICompileUnit’s list of globals, but we will need to retain
all constants. Really, we should also retain all non-constant globals that had
their storage optimized away, because they may shadow other variables. For
example:
>>> 
>>> int i;
>>> void f() {
>>>  static int i; // may get optimized away
>>>  // if I’m stopped here, in the debugger, “i” should always refer
to the inner i;
>>> }
>>> 
>>> -- adrian
>> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> On May 6, 2016, at 3:53 PM, Adrian Prantl <aprantl at apple.com>
wrote:
> 
>> 
>> On May 6, 2016, at 3:48 PM, Adrian Prantl via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>>> 
>>> On May 6, 2016, at 3:40 PM, Mehdi Amini <mehdi.amini at
apple.com> wrote:
>>> 
>>> 
>>>> On May 6, 2016, at 3:17 PM, Adrian Prantl <aprantl at
apple.com> wrote:
>>>> 
>>>> 
>>>>> On May 6, 2016, at 1:17 PM, Peter Collingbourne via
llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>> 1) Lets us reverse the DIGlobalVariable ->
GlobalVariable edge, which should hopefully clear the way for removing the
llvm.dbg.cu named metadata node.
>>>> 
>>>> Not to spoil all the fun, but I’m not sure if this will bring
us much closer to removing the llvm.dbg.cu node. The reason the llvm.dbg.cu node
exits is so we can find all DICompileUnits, because the DICompileUnit holds
debug info that is not referenced by any IR. This includes things like
DIImportedEntity (think C++ “using”), enums, and macros.
>>> 
>>> I understand the fact that DICompileUnit holds debug information
that are useful and not referenced directly from the IR.
>>> 
>>> What I wonder is, after all edges are pointing from the IR toward
the metadata graph, why do you need to keep a compile unit (and the associated
retained informations) if nothing in the IR (transitively) points to this
compile unit? (i.e. it is unreachable from the IR)
>> 
>> Couple of examples:
>> - because the compile unit could contain definitions for an enum that
is useful during expression evaluation
Do we need to preserve an enum type that is not used anywhere in the program?
(i.e. we dropped all functions that were using it)
>> - because it contains constants that are useful (XNU for example has
this version.c file:
http://opensource.apple.com/source/xnu/xnu-1456.1.26/config/version.c).
Is it a feature that we need to keep the debug info for a constant global even
though we dead-strip the global?
I'd have assumed that the constant being present in the binary, you
wouldn't duplicate the initializer of the constant in the dwarf itself and
that accessing the constant was enough.

>> - When clang compiles debug info for a module it compiles an otherwise
empty CU with debug info for all types in the module.
> 
> - (something we recently discussed on cfe-commits for better supporting
dtrace/ctfconvert) because the frontend implemented a -gfull option that added
all types to the CU’s list retained types.
Ok, you can have the named metadata to retain specific CU, but that could be the
exception and not the rule.

-- 
Mehdi

> On May 6, 2016, at 4:01 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 
> 
>> On May 6, 2016, at 3:53 PM, Adrian Prantl <aprantl at apple.com>
wrote:
>> 
>>> 
>>> On May 6, 2016, at 3:48 PM, Adrian Prantl via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>>> 
>>>> 
>>>> On May 6, 2016, at 3:40 PM, Mehdi Amini <mehdi.amini at
apple.com> wrote:
>>>> 
>>>> 
>>>>> On May 6, 2016, at 3:17 PM, Adrian Prantl <aprantl at
apple.com> wrote:
>>>>> 
>>>>> 
>>>>>> On May 6, 2016, at 1:17 PM, Peter Collingbourne via
llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>>> 1) Lets us reverse the DIGlobalVariable ->
GlobalVariable edge, which should hopefully clear the way for removing the
llvm.dbg.cu named metadata node.
>>>>> 
>>>>> Not to spoil all the fun, but I’m not sure if this will
bring us much closer to removing the llvm.dbg.cu node. The reason the
llvm.dbg.cu node exits is so we can find all DICompileUnits, because the
DICompileUnit holds debug info that is not referenced by any IR. This includes
things like DIImportedEntity (think C++ “using”), enums, and macros.
>>>> 
>>>> I understand the fact that DICompileUnit holds debug
information that are useful and not referenced directly from the IR.
>>>> 
>>>> What I wonder is, after all edges are pointing from the IR
toward the metadata graph, why do you need to keep a compile unit (and the
associated retained informations) if nothing in the IR (transitively) points to
this compile unit? (i.e. it is unreachable from the IR)
>>> 
>>> Couple of examples:
>>> - because the compile unit could contain definitions for an enum
that is useful during expression evaluation
> 
> Do we need to preserve an enum type that is not used anywhere in the
program? (i.e. we dropped all functions that were using it)
Yes, to support code like:

enum {
MY_CONSTANT = 42;
};

int i = MY_CONSTANT;
> 
>>> - because it contains constants that are useful (XNU for example
has this version.c file:
http://opensource.apple.com/source/xnu/xnu-1456.1.26/config/version.c).
> 
> Is it a feature that we need to keep the debug info for a constant global
even though we dead-strip the global?
> I'd have assumed that the constant being present in the binary, you
wouldn't duplicate the initializer of the constant in the dwarf itself and
that accessing the constant was enough.
Similar example as above:

const int my_magic_number = ...; // gets optimized away, but is still useful
> 
>>> - When clang compiles debug info for a module it compiles an
otherwise empty CU with debug info for all types in the module.
>> 
>> - (something we recently discussed on cfe-commits for better supporting
dtrace/ctfconvert) because the frontend implemented a -gfull option that added
all types to the CU’s list retained types.
> 
> Ok, you can have the named metadata to retain specific CU, but that could
be the exception and not the rule.
Given the enum example, I’m not entirely convinced that there will be many CUs
that are not the exception, but generally, yes, that would work.

-- adrian
> 
> -- 
> Mehdi
>