[llvm-commits] RFC: initial union syntax support

Andrew Lenharth andrewl at lenharth.org
Thu May 14 05:27:25 PDT 2009


2009/5/14 Török Edwin <edwintorok at gmail.com>:
> 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?

I think the purposes are served either way, but I would prefer a
memory location semantics.  All fields are offset 0 from the start of
the union and a gep cast load before is equivalent to a gep load now.

I would at least want to specify that for any type pair which have the
same size and alignment restriction you can store one and load the
other and it would be equivalent to a bitcast of the result.  This
covers unions of pointers and unions of pointers and intptr_t and
unions of i32 and float and unions of i64 and double (on most
platforms).

Andrew




More information about the llvm-commits mailing list