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

Chris Lattner clattner at apple.com
Fri Aug 27 21:10:43 PDT 2010

I removed unions from mainline in r112356.


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>

More information about the llvm-dev mailing list