On Thu, Jun 20, 2013 at 3:40 PM, Renato Golin <[email protected]> wrote: > On 20 June 2013 23:04, David Blaikie <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
