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

Frédéric Riss via llvm-dev
Fri, 06 May 2016 23:45:06 -0000

> On May 6, 2016, at 4:38 PM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>
>>
>> On May 6, 2016, at 4:06 PM, Adrian Prantl <aprantl at apple.com>
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;
>
>
> There is still a piece I'm missing: in this example the enum is used to
initialize "i", which will have an edge to the CU to be kept alive,
and this CU should retain the enum.

The debug info doesn’t desire the RHS of the assignment. It just says there’s a
variable i of type int. The enum is not mentioned anywhere in this case. But you
still want to be able to use 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
<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
>
> "still useful" is hand-wavy. That is not clear to me (other than
a programmer saying "I want a pony”).

You want to be able to use symbolic constants in the debugger expression
evaluator, even if the variable has been propagated and optimized away.

Fred

>
>>>>> - 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.
>
> I meant the exception is the specific use case of -gfull. Not the enum
case.
>
> --
> Mehdi
>
>
> _______________________________________________
> 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/20160506/60180dd5/attachment.html>