[LLVMdev] Union type, is it really used or necessary?

[Talin]

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/20100720/d8d6f754/attachment.html>