[LLVMdev] Suggestion: Support union types in IR

[Chris Lattner]

On Dec 31, 2008, at 4:57 PM, Talin wrote:
> Nick Lewycky wrote:
>> It has to come down to a fixed size at some point, using target- 
>> specific
>> knowledge. Is there any reason you couldn't use 'opaque' here and
>> resolve it once you have the necessary information?
>>
> Perhaps I've never quite understood the role of bitcode files.  
> Assume I
> have a compiler that generates .bc files, and a linker which combines
> them into a runnable program. At which point is the target machine
> chosen, in the compiler or in the linker? The assumption that I have
> made up to this point is that the compiler produces .bc files which  
> are
> target-neutral, and the linker then generates a target-specific  
> program.
> (I realize that other design choices are possible.)

Well there are two answers to this.  Ideally, LLVM would work as you  
say.  Unfortunately some of the current implementation has been  
tainted by LLVM's primary development being guided by the needs of C  
compilers.  C compilers inherently need the front-end to encode target- 
specific information in the IR.

However, I really do want to serve portable languages better.   
Ideally, the first time that target-specificity comes into play is at  
the "llc" level.  I think we are very close to this, but I believe  
there are still a few problem areas.

That said, I don't think this is a reason *not to add* the 'portable  
union' feature, I just think it's a reason we *haven't already* added  
it.

> Exactly. I'm not especially interested in C-style unions, I'm  
> interested
> in discriminated unions. But the actual discriminator field is easily
> represented in LLVM IR already, so there's no need to extend the IR to
> support them. That's why I am only asking for C-style union support -
> it's a lower-level primitive that you can use to build discriminated
> unions on top of.

Yes, I completely agree with you.

-Chris