[llvm-commits] RFC: initial union syntax support

[Frits van Bommel]

Nick Lewycky wrote:
> Frits van Bommel wrote:
>> Nick Lewycky wrote:
>>> I really don't like allowing a union to contain the same type twice. 
>>> That should be illegal no matter what the object hierarchy is.
>> That would require the frontend to make sure different types being inserted into 
>> the union don't happen to have the same LLVM type.
> 
> No it doesn't.
> 
>> For instance, 'int' and 'unsigned' are different in the frontend, but the same 
>> in LLVM. This is a simple case, but the same goes for more complicated struct 
>> types and such so in practice this would require some kind of hashset in the 
>> frontend, just to construct a union of arbitrary types.
>>
>> Is there any actual harm in allowing it?
> 
> If you want the frontend to send i32 and i32 into StructType::get, then 
> it's StructType::get's job to unique them.
> 
> By the same token, we only permit one Int32Ty, but it's not up to the 
> frontend to maintain that guarantee. For example, if you call 
> IntegerType::get(32 bits) the implementation of IntegerType::get is 
> responsible for guaranteeing that only one 32-bit IntegerType exists.
> 
> 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?