[LLVMdev] [PATCH] - Union types, attempt 2

[Talin]

On Thu, Jan 14, 2010 at 9:25 PM, me22 <me22.ca at gmail.com> wrote:

> 2010/1/14 Talin <viridia at gmail.com>:
> > The reason for doing it this way is that to construct a union, you really
> > need 4 pieces of information: The type of the union, the type and value
> of
> > the member to be initialized, and the index of which member is being
> > initialized.
>
> Does requiring the index mean that uniquing the union type will have
> to re-write many of the corresponding insertvalue calls?
>
> For instance, how would this round-trip?
>
>    @foo = constant union { float, i32 } insertvalue union { i32,
> float } undef, i32 4, 0
>     @bar = constant union { i32, float } insertvalue union { float,
> i32 } undef, i32 4, 1
>

Well, the fact that union members have to be indexed by number means that
the ordering has to be part of the type - so even though type-theoretically
union { i32, float } is the same as union { float, i32 }, in my
implementation they are distinct types. However, from the standpoint of a
frontend, this is not a great concern, because the frontend will most likely
sort the list of types before constructing the IR type. By always putting
the types in a canonical order, regardless of the order that they appear in
the source code, you can ensure that unions of equal types are always
compatible. In other words, you can treat the members like an ordered set
rather than like a list.

>
> I'm very glad to see a non-bitcast method of using unions, BTW.
>

-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100114/4a60bcd3/attachment.html>