[PATCH] Output debug information for structure members only referenced by a pointer or typedef

David Blaikie dblaikie at gmail.com
Thu Jun 20 15:53:06 PDT 2013


On Thu, Jun 20, 2013 at 3:40 PM, Renato Golin <renato.golin at linaro.org> wrote:
> On 20 June 2013 23:04, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> Not really - the backend doesn't really know when/how to make that
>> choice & just because we've optimized away all the code is no reason
>> not to emit it. (& types especially don't necessarily connect to any
>> code - or at least not in any way that is easily distinguishable
>> between declaration and definition type uses).
>
>
> I'm quite likely being too shallow in my analysis, but IIRC, types in
> metadata are nodes that get created when a variable or structure is defined,
> so you can point the uses and declarations to it. This is why you want to
> cache them, to have the same type metadata for all uses, or you'd end up
> with many different "INT" types and so on.

Kind of - some of that is just compile time optimization. If we
created two "int" types in LLVM IR metadata debug info then the
metadata uniquing would kick in & it'd be fine. Not so clear with user
defined types (structs, etc) which can have circular type references &
the like which would be harder to break.

> If the last user unlinks against a type, it means that type is unused, so
> when emitting the Dwarf table you only emit the types with use count > 0.
> Each compile unit can remove unused types (if they come from a header or
> forward declaration), since other CUs will have them anyway, and when you
> link them all together, assuming name mangling is universal, it should just
> click.
>
> But that's probably wrong... ;)

Somewhat - uses in source don't correlate exactly with where the debug
info is wired into the IR so we can't just rely on IR optimizations to
preserve or drop debug info perfectly. At the moment there are cases
where we aren't emitting types into the debug info where we should be
- because we only emit them in particular cases. There are broader
ways we can do this, but it's still a choice about when/where we do
it.

- David



More information about the cfe-commits mailing list