[llvm-commits] RFC: initial union syntax support

[Frits van Bommel]

Duncan Sands wrote:
>>> another possibility is to not introduce new union types, but instead
>>> to enhance the alloca instruction to take a list of types : it would
>>> then allocate enough memory for all of the types in the list.  The
>>> return type could be that of the first type in the list.
>> That's only good for stack variables. It doesn't work for globals.
> 
> good point.  How about allowing the "align" parameter for alloca's and
> globals to be a ConstantExpr of integer type, rather than a ConstantInt?
> (If it doesn't resolve to a ConstantInt at codegen time, when the target
> is known, then codegen can abort).  As I pointed out in a previous mail,
> you can get the size of a "union type" in a target independent way as a
> ConstantExpr, by taking the size of each type (using the GEP trick) and
> calculating the maximum using constant expressions.  You can also get
> the alignment as a constant expression using a variant of the trick (I
> explained how in yet another email).  So the only thing currently
> stopping you declaring locals or globals of a "union type" in a target
> independent is the fact that "align" is required to be a ConstantInt.
> I think this approach would be much easier to implement than a new
> "union type:.

So how would you propose to translate structs with union members in a 
target-independent way?