llvm dev - Jun 2009 - [LLVMdev] simulating c style unions in LLVM

I am trying to create a boxed tagged datatype for a language where it is
necessary to resolve the type at runtime. If I were writing an interpreter in C-
it would most likely look something like this-

struct
{
    unsigned tag;
    union { long Int; double Float; .... }
}

Is there a standard way for constructing a type like this in LLVM?

Thanks again.

On Mon, Jun 29, 2009 at 11:09 PM, Carter Cheng<carter_cheng at yahoo.com>
wrote:
>
> I am trying to create a boxed tagged datatype for a language where it is
necessary to resolve the type at runtime. If I were writing an interpreter in C-
it would most likely look something like this-
>
> struct
> {
>    unsigned tag;
>    union { long Int; double Float; .... }
> }
>
> Is there a standard way for constructing a type like this in LLVM?
You have to write it using bitcasts.  Try looking at llvm-gcc or clang
output for a rough outline.

-Eli

2009/6/29 Carter Cheng <carter_cheng at
yahoo.com>:
>
> I am trying to create a boxed tagged datatype for a language where it is
necessary to resolve the type at runtime. If I were writing an interpreter in C-
it would most likely look something like this-
>
> Is there a standard way for constructing a type like this in LLVM?
>
Well, you can always ask bitter melon, who translates this:

struct foo
{
   unsigned tag;
   union { long Int; double Float; } data;
};

void bar(struct foo *x) {
    x->data.Int = x->tag;
}

into this:

	%struct.anon = type { double }
	%struct.foo = type { i32, %struct.anon }

define void @bar(%struct.foo* nocapture %x) nounwind {
entry:
	%0 = getelementptr %struct.foo* %x, i32 0, i32 0		; <i32*> [#uses=1]
	%1 = load i32* %0, align 4		; <i32> [#uses=1]
	%2 = getelementptr %struct.foo* %x, i32 0, i32 1		; <%struct.anon*>
[#uses=1]
	%3 = bitcast %struct.anon* %2 to i32*		; <i32*> [#uses=1]
	store i32 %1, i32* %3, align 4
	ret void
}

So essentially the union just turns into bitcasts.

I know there was some discussion about adding a first-order union to
LLVM a bit back, but IIRC disagreement over semantics prevented it
from going anywhere.

Thanks both. I looked over the getelementptr and bitcast documentation but I am
still a bit confused by one point. lets say i have something like this.

union
{
    long Int; double float; long* IntRef;
}

Since pointer sizes are platform dependent if I am trying to use the union in
question with an extern C function is it possible to make write the single
definition in a platform independent way?

Thanks in advance.


--- On Mon, 6/29/09, me22 <me22.ca at gmail.com> wrote:
> From: me22 <me22.ca at gmail.com>
> Subject: Re: [LLVMdev] simulating c style unions in LLVM
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Date: Monday, June 29, 2009, 11:32 PM
> 2009/6/29 Carter Cheng <carter_cheng at yahoo.com>:
> >
> > I am trying to create a boxed tagged datatype for a
> language where it is necessary to resolve the type at
> runtime. If I were writing an interpreter in C- it would
> most likely look something like this-
> >
> > Is there a standard way for constructing a type like
> this in LLVM?
> >
> 
> Well, you can always ask bitter melon, who translates
> this:
> 
> struct foo
> {
>    unsigned tag;
>    union { long Int; double Float; } data;
> };
> 
> void bar(struct foo *x) {
>     x->data.Int = x->tag;
> }
> 
> into this:
> 
>     %struct.anon = type { double }
>     %struct.foo = type { i32, %struct.anon
> }
> 
> define void @bar(%struct.foo* nocapture %x) nounwind {
> entry:
>     %0 = getelementptr %struct.foo* %x, i32
> 0, i32 0        ; <i32*>
> [#uses=1]
>     %1 = load i32* %0, align
> 4        ; <i32>
> [#uses=1]
>     %2 = getelementptr %struct.foo* %x, i32
> 0, i32 1        ;
> <%struct.anon*> [#uses=1]
>     %3 = bitcast %struct.anon* %2 to
> i32*        ; <i32*>
> [#uses=1]
>     store i32 %1, i32* %3, align 4
>     ret void
> }
> 
> So essentially the union just turns into bitcasts.
> 
> I know there was some discussion about adding a first-order
> union to
> LLVM a bit back, but IIRC disagreement over semantics
> prevented it
> from going anywhere.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu 
>        http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>