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

[Adrian Prantl via llvm-dev]

> On May 6, 2016, at 4:06 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
>> 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.

The IR that I have in mind for this is an orphaned DIGlobalVariable (orphaned because the constant that had a !dbg attachment referencing it has been optimized away) with a DIExpression that holding the constant value. If the constant GlobalObject is still live, we don’t need the DIExpression and can just reference it via a !dbg attachment directly.

-- adrian

> 
> 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
>> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev