[llvm-commits] RFC: initial union syntax support

[Frits van Bommel]

Nick Lewycky wrote:
> Andrew Lenharth wrote:
>> The whole point of this exercise is to remove bitcasts.  In fact,
>> though I am not suggesting it, you could do away with bitcasts
>> completely given unions.

I disagree with this. Proper union support will allow more than just doing away 
with bitcasts in a few places. A union type would have both the maximum size and 
maximum alignment of any member, so that e.g. explicit padding to get a union in 
a struct at the right alignment won't be necessary.

> Then it would seem I misunderstood the purpose of unions. I thought the 
> problem was that it was impossible to declare a type which would be "as 
> large as the largest of any of these" without having accurate 
> TargetData. The union type was supposed to do that and nothing more. 
> Specifically, you'd still read and write by bitcasting to the target 
> type, not by using GEP which as you've pointed out would break things.
> 
> I don't like the concept of using GEPs to access unions one bit. Unions 
> only have one field and GEPs are used to access the n'th field as laid 
> out in memory.

So you're thinking of a type with no valid operations other than via pointers 
bitcast to one of the member types? As long as it supports literals I could live 
with that, actually. It'd still allow a cleaner implementation of quite some 
code in LDC that deals with constructing a proper type for a union, and the 
headache that goes with making sure it's properly aligned...
(We recently discovered LDC wasn't handling union alignment properly :( )

> Elsewhere on the thread, I saw a question of why "union {i32}" and 
> "union {i32, i32}" should be fold to the same type. Types in C serve two 
> purposes, they are there for to prove your program "correct" in the 
> sense of typesafety, and they are there to describe the layout and 
> interpretation of the data in memory. In LLVM they serve the latter 
> purpose only; if they (are guaranteed to) have the same representation 
> in memory then they should be the same type.

If GEP is unsupported I agree with this part; in that case there is indeed no 
reason for union {i32} to be a different type than union {i32,i32}.