llvm dev - Sep 2010 - [LLVMdev] Union type, is it really used or necessary?

On Sep 7, 2010, at 6:22 AM, Erik de Castro Lopo wrote:
> 
> I'm currently use llvm-2.7 and have been using unions, not being
> aware that they are going to be removed. The use case is for 
> forcing field alignments in a packed struct to be correct for
> 32 and 64 bits. In particular I have a struct with an i32 tag
> field followed by a pointer.
> 
> When generating 32 bit code the struct looks like:
> 
>     <{ i32, pointer }>
> 
> and for 64 bit code:
> 
>     <{ union { i32, i64 }, pointer }>
> 
> The nice thing about this is that in my LLVM code generator,
> I have a function offsetOf which can get me the byte offset of
> and element in a struct. In the case above,
> 
>    offsetOf (1)
> 
> returns 4 when generating 32 bit code and 8 when generating 64
> bit code.
> 
> If there's another of guaranteeing struct alignment as well as
> and easy way to get struct field offsets I'd like hear of it.
If you want to make sure the pointer field is properly aligned, why not
just use a non-packed struct: { i32, pointer } ?  Or if you really want
a packed struct, can you use <{ i32, i32, pointer }>, since you're
already emitting target-dependent IR anyway?

If you're computing the offset in order to use as a value
within the program, you can use ConstantExpr::getOffsetOf.
(If this isn't exposed in whatever bindings you're using,
that can be fixed.)

Dan

Dan Gohman wrote:
> If you want to make sure the pointer field is properly aligned, why not
> just use a non-packed struct: { i32, pointer } ?  Or if you really want
> a packed struct, can you use <{ i32, i32, pointer }>, since
you're
> already emitting target-dependent IR anyway?
>
> If you're computing the offset in order to use as a value
> within the program, you can use ConstantExpr::getOffsetOf.
> (If this isn't exposed in whatever bindings you're using,
> that can be fixed.)
The thing is, I am not using the LLVM library, I generate IR
code directly from Haskell (not using the library because it
makes bootstrapping the compiler I'm working on more difficult).

Secondly, my code, which currently works with llvm-2.7, assumes
packed structs and unions. Using

     <{ i32, i32, pointer }>

won't work for me because the 32 bit version looks like:

     <{ i32, pointer }>

and that means the the pointer element will have different struct
indices depending on whether I'm compiling for 32 vs 64 bit
targets.

Another possible solution is using:

     <{ i64, pointer }>      ; 64 bit version
     <{ i32, pointer }>      ; 32 bit version

but then the first elements are of different types.

Generating IR code without the benefit of unions, makes both
me generating and generated code far less readable. I'm going
to have to stick with version 2.7 and work on getting unions
back in 2.9.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

On Sep 7, 2010, at 5:35 PM, Erik de Castro Lopo wrote:
> Generating IR code without the benefit of unions, makes both
> me generating and generated code far less readable. I'm going
> to have to stick with version 2.7 and work on getting unions
> back in 2.9.
Great!  I'm sure many people would really appreciate working union support
in 2.9, thanks!

-Chris