[llvm-commits] RFC: initial union syntax support

[Török Edwin]

On 2009-05-14 14:58, 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.
>   

What is the semantics for these unions?
Are you allowed to store to one field, and read from another field
without fearing that an optimizer will break your code?
Or is it the same as in C, that is undefined behaviour if you read from
another field?

Best regards,
--Edwin