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

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

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

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

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

> 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