[LLVMdev] [PATCH] - Union types, attempt 2

Talin viridia at gmail.com
Wed Jan 13 12:11:59 PST 2010

On Tue, Jan 12, 2010 at 5:46 PM, Dan Gohman <gohman at apple.com> wrote:

> On Jan 12, 2010, at 5:01 PM, Talin wrote:
> > Here is the LangRef part of the patch.
> > +<p>The union type is used to represent a set of possible data types
> which can
> > +   exist at a given location in memory (also known as an "untagged"
> > +   union).
> [...]
> This wording is somewhat misleading; memory in LLVM has no types.
> How about:
> "A union type describes an object with size and alignment suitable for
> an object of any one of a given set of types."


> Also, is it really useful to support
> insertvalue/extractvalue/getelementptr on unions? The benefit of unions
> that I'm aware of is it allows target-independent IR to work with
> appropriately sized and aligned memory. This doesn't require any special
> support for accessing union members; for example:
>  %p = alloca union { i32, double }
>  %q = bitcast union { i32, double }* %p to double*
>  store i32 2.0, double* %q
> Would this be a reasonable approach?

It depends on whether or not unions can be passed around as SSA values or
not. I can think of situations where you would want to.

In particular, GEP is useful because you can avoid the bitcast above - GEP
to element 0 if you want an int (in the example above), or to element 1 if
you want a double.

Also, I'm thinking that insertvalue might be the best way to construct a
constant union. Right now there's a bit of a problem in that the data type
of a constant must match exactly the declared type; However in the case of a
union what we want is for the data type of the initializer to exactly match
the type of one of the union members. I thought this would be relatively
easy to do, but it's a little trickier than I realized.

-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100113/2be8f496/attachment.html>

More information about the llvm-dev mailing list