[llvm-commits] RFC: initial union syntax support

[Nick Lewycky]

Andrew Lenharth wrote:
> On Thu, May 14, 2009 at 4:04 AM, Frits van Bommel <fvbommel at wxs.nl> wrote:
>> Nick Lewycky wrote:
>>> In the case that StructType::get is constructing a union, it should put
>>> the types into a set to sort and unique them. However, we're not really
>>> allowed to do pointer comparisons in LLVM (because it means that you'll
>>> encounter non-determininstic bugs) so it will also need to have some
>>> ordering function that doesn't rely on the pointers.
>> So how will you then extract a pointer to one of the members? What GEP indices
>> can you use if the order of members is not preserved? I really don't see how
>> this can be done if union {i8, i32} == union {i32, i8}.
>> Or do you want to disallow GEPping into unions, forcing the use of bitcasts?
> 
> I agree.  Reordering the elements on creation would make this a pain
> to deal with.  Since it is a struct, GEPs are sane (constant index) so
> it would be a simple matter for a pass to prune redundant fields and
> rewrite GEPs.  But that should happen after the front end is done.
> The alternative is the create a whole bunch of new machinery so you
> can ask for the index of the field holding type T.
> 
> 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.

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.

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.

Nick