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

Reid Kleckner rnk at mit.edu
Thu Jan 14 21:01:45 PST 2010

On Tue, Jan 12, 2010 at 8: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?

I can think of another benefit of the insertvalue/extractvalue/etc
approach, which is that then LLVM checks your types for you.  In other
words, it makes sure you don't put an i64 into a union of i32 and
double, whereas you can always bitcast an i64 to that union.


More information about the llvm-dev mailing list