[llvm-commits] RFC: initial union syntax support
Nick Lewycky
nicholas at mxc.ca
Wed May 20 23:42:25 PDT 2009
Duncan Sands wrote:
> Hi Nick,
>
>>>> 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.
>>>
>>> I sent an example earlier showing that you can do this already without
>>> union types.
>>
>> Close. Your trick does perform a ptrtoint which requires knowing what
>> int size is large enough. Fortunately in your case it's indexing off of
>> null so it's very unlikely that it won't fit in 16 bits or less, but
>> it's still not as good as a first-class union.
>
> if the union is bigger than accessible memory, then you are going to
> be able to allocate one anyway. Conclusion: doing GEP of null can be
> assumed to not result in pointer overflow. Thus the only problem is
> ptrtoint. You can do ptrtoint to i64 on all platforms, which solves
> the problem since you can't alloca an amount that doesn't fit in i64
> anyway. That said, this whole technique is pretty ugly.
Sure.
>> I've been thinking about the original suggestion and the reasons I
>> objected to it. It seems that the original suggest was to think about
>> a union as a structure where the offset into each element is zero
>> instead of being contiguous to each other. That makes the original
>> proposal make a whole lot more sense to me than it did originally.
>>
>> Despite Chris' message to the contrary, I still think u{i32, i32}
>> shouldn't be allowed (rather, it should be folded to u{i32} by the
>> getter). We could provide an accessor that returns the element number
>> for a given Type* and the only drawback is that it means doing an
>> extra lookup through a small list. Allowing GEP makes sense, and
>> unions should certainly be first class aggregates.
>
> another possibility is to not introduce new union types, but instead
> to enhance the alloca instruction to take a list of types : it would
> then allocate enough memory for all of the types in the list. The
> return type could be that of the first type in the list.
That's only good for stack variables. It doesn't work for globals.
Nick
More information about the llvm-commits
mailing list