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

[Peter Collingbourne via llvm-dev]

On Fri, May 6, 2016 at 3:41 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:

>
>
> On Fri, 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.
>> 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;
>>   }
>>
>
> Yes, that does seem to make things more complicated than I thought. I
> suppose we would have to at least for the moment preserve the global named
> metadata node and the global variable list on DISubprogram. In the long
> term we could perhaps consider preserving these variables on a global named
> metadata node like I was mentioning on the other subthread with David. We'd
> still need to have a global metadata node, so maybe it wouldn't be much
> better.
>

After thinking a little more about this, I suppose that one benefit of
attaching entities such as unreferenced globals and macros to a named
metadata node is that in something like a ThinLTO scenario we could reduce
the amount of work required to import entities into a module by somehow
arranging to only load the named metadata node when compiling the module
itself, and not when we import it into other modules.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160509/2caac4fb/attachment.html>