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

I removed unions from mainline in r112356.

-Chris

On Jul 20, 2010, at 2:46 PM, Talin wrote:
> On Tue, Jul 20, 2010 at 8:34 AM, Chris Lattner <clattner at
apple.com> wrote:
> 
> On Jul 20, 2010, at 1:36 AM, Anton Korobeynikov wrote:
> 
> >> used to make the code manipulating the union type "well
typed". This
> >> approach seems work very well, is there really a need to keep
union type in
> >> LLVM?
> > I think in its current state the unions should be removed from LLVM IR
> > in next release. It's pretty much unfinished and noone is willing
to
> > work on them.
> 
> I agree.
> 
> Unfortunately I wasn't able to take the union stuff much farther than I
did. Partly that was because my LLVM-related work has been on hiatus for the
last 4 months or so due to various issues going on in my personal life. But it
was also partly because I had reached the limit of my knowledge in this area, I
wasn't able to delve deeply enough into the code generation side of LLVM to
really understand what needed to be done to support unions.
> 
> As far as converting a union into a C struct that is large enough to hold
all possible types of the union, there are two minor problems associated with
this approach:
> 
> 1) For frontends that generate target-agnostic code, it is difficult to
calculate how large this struct should be. (Which is larger, 3 int32s or two
pointers? You don't know unless your frontend knows the size of a pointer.)
In my case, I finally decided to abandon my goal of making my frontend
completely target-neutral. While it's relatively easy to write a frontend
that is 99% target-neutral with LLVM, that last 1% cannot be eliminated.
> 
> 2) Extracting the values from the union require pointer casting, which
means that the union cannot be an SSA value - it has to have an address. This
probably isn't a big issue in languages like C++ which use unions
infrequently, but other languages which use algebraic type systems might suffer
a loss of performance due to the need to store union types in memory.
>  
> -Chris
> 
> -- 
> -- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100827/9cebf26f/attachment.html>

Chris Lattner wrote:
> I removed unions from mainline in r112356.
Sorry for reviving this old thread, but I think the removal of
unions is a real pity.

I use Haskell to generate LLVM code using David Terei's LLVM
code from the GHC compiler (the compiler I'm working on is also
written in Haskell). Once I've generated LLVM IR code I use llc
to generate object code.

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.
Otherwise, I'd like to know what needs to be done to get unions
back in LLVM.

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

Hello, Erik
> Otherwise, I'd like to know what needs to be done to get unions
> back in LLVM.
Well, the answer is pretty easy: someone should "fix" them to be
supported throughout the whole set of libraries and became a
"maintainer".
Otherwise the feature being unused will quickly became broken.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

On 07/09/10 14:22, Erik de Castro Lopo wrote:
[...]
> When generating 32 bit code the struct looks like:
> 
>      <{ i32, pointer }>
> 
> and for 64 bit code:
> 
>      <{ union { i32, i64 }, pointer }>
Surely LLVM will cause the first structure to be correctly aligned on
64-bit platforms by automatically inserting padding? Is explicit
alignment by the user really necessary?

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100908/888f6977/attachment.sig>