[cfe-dev] struct copy

[Chris Lattner]

On Sep 28, 2008, at 1:45 PM, Richard Pennington wrote:

> Chris Lattner wrote:
>> On Sep 28, 2008, at 11:59 AM, Argiris Kirtzidis wrote:
>>> Ah ok, "unions as the biggest field" is bad. How about if we   
>>> consider unions as arrays (as clang does):
>>>
>>>  %struct.a = type { i8, double }
>>>  %struct.c = type [12 x i8]
>> That would solve this problem, but also isn't a universally good  
>> thing  to do.  Doing things like this can break the (critical for  
>> some codes)  Scalar Replacement of Aggregates optimization.  In  
>> general, it is good  for the front-end to preserve as much accurate  
>> type info in the LLVM  IR as possible.
>> -Chris
>
> Out of curiosity, why aren't unions represented in the IR as  
> something similar to a struct in which all offsets are zero? It  
> seems that that would preserve the required type info. Is there some  
> intrinsic flaw in that idea?

There is no specific reason to avoid them, other than additional  
complexity in the IR.  However, representing unions directly doesn't  
provide any value to the optimizers over a type cast.  They both  
directly say that the memory is being reinterpreted in a different way  
(when dereferenced).  Since we have to have casts, there has (so far)  
been no reason to add unions.

-Chris