[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."
>
OK
>
> 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