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

Douglas Gregor
Mon, 14 Oct 2013 22:49:31 -0000

On 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. However, if it's to save space during an
> LTO link then we'll want to do it in the front end.
>
> Doug: Have a link for how you do the C type merging for modules?


Modules foists the C++ one definition rule on C/Objective-C so that it can avoid
performing type merging, so we can’t look there.

C doesn’t have a one definition rule per se. The cross-translation-unit
compatibility rules are in 6.2.7 of the C standard, which boils down to
structural equality:

Moreover, two structure, union, or enumerated types declared in separate
translation units are compatible if their tags and members satisfy the following
requirements: If one is declared with a tag, the other shall be declared with
the same tag. If both are complete types, then the following additional
requirements apply: there shall be a one-to-one correspondence between their
members such that each pair of corresponding members are declared with
compatible types, and such that if one member of a corresponding pair is
declared with a name, the other member is declared with the same name. For two
structures, corresponding members shall be declared in the same order. For two
structures or unions, corresponding bit-fields shall have the same widths. For
two enumerations, corresponding members shall have the same values.


	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131014/34b8ea92/attachment.html>