[PATCH] D16440: [ThinLTO] Link in only necessary DICompileUnit operands

[Duncan P. N. Exon Smith via llvm-commits]

> On 2016-Apr-25, at 08:36, Teresa Johnson <tejohnson at google.com> wrote:
> 
> tejohnson added a comment.
> 
> In http://reviews.llvm.org/D16440#410434, @joker.eph wrote:
> 
>> I wonder if your approach here has still any gain with the new DebugInfo representation that Adrian and Duncan worked on?
> 
> 
> At the very least it is stale with Duncan's change in r267296 to eliminate remove MDString-based type references and Adrian's change in r266446 to remove the DISubprogramArray from the DICompileUnit.
> 
> For now the retainedTypes list still exists on the DICompileUnit, however, in Duncan's r267296 from this weekend he notes that the retainedTypes list is now unnecessary, so I assume he is removing that imminently?

The retainedTypes list won't completely disappear, but after my changes it should usually be empty, and otherwise be very short.  I think you can probably ignore it.

It still allows a frontend to guarantee that a type won't be optimized away.  I think that's uncommon enough that it's not worth thinking about.

> Once the retainedTypes list is gone, most of this is unnecessary. However, this patch was also nulling out several other fields on the imported DICompileUnit, namely EnumTypes, GlobalVariables, ImportedEntities 

I don't have immediate plans to make it happen, but I think these fields should all be removed, or lazily built somehow.  Global variables I think can use something similar to the subprogram model.  Imported entities should somehow be associated with the scope they're being imported into.  I suspect an interested party could design the enums field away as well (probably DIEnumerator would need to gain a 'scope:' field).

> and Macros.

Clang doesn't build the macros field by default.  If a client that fills this field wants to use -flto=thin, then probably DICompileUnit should be modified on import.

> What is the plan for those? Gping forward, should the DICompileUnit still be modified in some way when it is imported?



> 
> 
> http://reviews.llvm.org/D16440
> 
> 
>