[LLVMdev] simulating c style unions in LLVM

Carter Cheng carter_cheng at yahoo.com
Tue Jun 30 00:16:01 PDT 2009


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
> 


      




More information about the llvm-dev mailing list