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

[Douglas Gregor]

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>