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 I'm very glad to see a non-bitcast method of using unions, BTW.
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>
2010/1/15 Talin <viridia at gmail.com>:> On Thu, Jan 14, 2010 at 9:25 PM, me22 <me22.ca at gmail.com> wrote: >> >> @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. >Does that mean that my example above is ill-formed, since the insertvalue gives a different type than the constant wants?
Talin schrieb:> 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.Hm... it's placing a burden on the frontend developer. More importantly, it's something that the fronend developer must not forget to do, so you better make sure this is documented in capital letters in a place where the frontend developer is likely to look when preparing code generation. Most importantly, however, this will create a lot of hassles when making code interoperable between compilers: Compiler writers need to agree on a language-independent canonical ordering. That said, if the ordering is canonical, it could be established at the IR level. E.g. by ordering alphabetically. When coding, please consider that many languages establish assignment compatibility between union types. E.g. a union {i32, float} value could be assigned to a name that's typed as a union {i32, i64, float}. This probably means the need for conversion operators, and it definitely means that indexes aren't meaningful by themselves, only in conjunction with their union 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.Yes, that's closer to the frontend semantics: the variants of a union type don't have any natural ordering, so list semantics could cause problems. Regards, Jo