[cfe-dev] struct copy

[Argiris Kirtzidis]

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.

This makes sense, but having something like this:

    %struct.a = type { i8, double }
    %struct.c = type { %struct.a }

is certainly bad, right ? I mean, %struct.a is a type with holes, using 
it as a field for a union is fundamentally wrong.

-We could consider unions as arrays only in the case when the biggest 
field is a struct.

-Or take the scalar field of the union and add padding.
    %struct.c = type <{ int32, [8 x i8] }>

-Or represent the union as the struct itself, filling the holes:
    %struct.a = type { i8, double }
    %struct.c = type <{ i8, [7 x i8], double }>

-Or have something like this:
    %struct.a = type { i8, double }
    %struct.a.pad = type <{ i8, [7 x i8], double }>
    %struct.c = type { %struct.a.pad }


In general, the LLVM IR type for a union should not have fields with 
holes, is this correct ?
And to return to the original question, if we can assume that LLVM types 
for unions are "hole-less", what is wrong then in having load/store 
represent a copy of a large struct ?


-Argiris