[cfe-dev] struct copy
Argiris Kirtzidis
akyrtzi at gmail.com
Sun Sep 28 14:31:50 PDT 2008
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
More information about the cfe-dev
mailing list