[llvm-commits] RFC: initial union syntax support

Duncan Sands baldrick at free.fr
Fri May 22 00:36:43 PDT 2009


Hi Frits,

>>>> 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?

I don't see a problem, but maybe I'm missing something.  Given a struct
with union members, you can calculate its size as some disgusting
ConstantExpr.  Thus you can allocate enough memory for it using alloca.
You can calculate the byte offset of any field from the start of the
memory as a further horrible ConstantExpr, so you can get a pointer to
the field using GEP, and you can then bitcast it to the desired pointer
type.  And Bob's your uncle!

Note that this whole strategy is based on *not* declaring union types,
but instead on implementing unions via *operations* (allocation,
changing how you view a bit of memory (= bitcast of pointer)).  It's
an unpleasant approach, but I think it works, at least for local
variables.  Not sure if you can create global variables with size
specified by a ConstantExpr though.

Ciao,

Duncan.



More information about the llvm-commits mailing list