[LLVMdev] [Debug Info + LTO] Type Uniquing for C types?

[Manman Ren]

On Fri, Oct 11, 2013 at 12:07 PM, Eric Christopher <echristo at gmail.com>wrote:

> >
> > Since we don't have ODR, we may have macros defined differently for a
> struct
> > in a .h file,
> > thus having two versions of the struct from two different CU. It seems
> that
> > we can't assume
> > structs with the same name and defined in the same file/line/column are
> the
> > same.
> >
>
> Ah right sorry, I remember this. Also, macros are evil, just ask the
> modules guys :)
>
> > Hashing the types can happen either at the front end or at IR level.
> That is
> > our first design choice :)
> >
>
> Sorta :)
>
> > I think we should try not to hash the types for non-LTO builds at the
> front
> > end or at IR level, since it does not give us
> > any benefit given that we are hashing them at the back end.
> >
> > One advantage of hashing it at IR level is that we can just hash the
> MDNodes
> > that affect the
> > type MDNode, at front end, the AST contains more information and should
> be
> > harder to hash.
>
> It depends upon the goals. If the goal is to make debug information
> post-link smaller then just using the type hashing machinery for
> structs will be sufficient.


By "the type hashing machinery for structs", are you referring to the type
hashing at the back end?


> However, if it's to save space during an
> LTO link then we'll want to do it in the front end.
>

Yes, my purpose here is to save memory space in number of MDNodes (also #
of DIEs) generated in a LTO build.
Type hashing at the DIE level can reduce the dwarf size.

Manman


>
> Doug: Have a link for how you do the C type merging for modules?
>
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131011/7b704efe/attachment.html>