similar to: [LLVMdev] Union Type

On Fri, 19 Dec 2003, Reid Spencer wrote: > As a side effect of bug 178 (Stacker not handling 64-bit pointers on > Solaris), I got thinking about a union type for LLVM. Is there any > good reason that LLVM shouldn't support unions? This is essentially a > structure that has its members all at the same address rather than at > sequential addresses. I know there are various

On Fri, 2003-12-19 at 15:32, Chris Lattner wrote: > This is intentionally not part of the LLVM type-system, because it is > redundant. If you compile a C program that uses a union, for example, the > C front-end will turn it into a type (often a structure) that contains > only one of the element types (usually the largest one, perhaps modified > to have the correct alignment).

On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote: >> Exactly. I'm not especially interested in C-style unions, I'm >> interested >> in discriminated unions. But the actual discriminator field is easily >> represented in LLVM IR already, so there's no need to extend the IR >> to >> support them. That's why I am only asking for C-style union

On Fri, Jan 15, 2010 at 3:13 PM, Talin <viridia at gmail.com> wrote: > On Fri, Jan 15, 2010 at 11:02 AM, Dan Gohman <gohman at apple.com> wrote: > >> >> On Jan 13, 2010, at 12:11 PM, Talin wrote: >> > >> > It depends on whether or not unions can be passed around as SSA values >> or not. I can think of situations where you would want to.

On Jan 12, 2010, at 5:01 PM, Talin wrote: > Here is the LangRef part of the patch. > +<p>The union type is used to represent a set of possible data types which can > + exist at a given location in memory (also known as an "untagged" > + union). [...] This wording is somewhat misleading; memory in LLVM has no types. How about: "A union type describes an

On Tue, Jan 12, 2010 at 5:46 PM, Dan Gohman <gohman at apple.com> wrote: > > On Jan 12, 2010, at 5:01 PM, Talin wrote: > > > Here is the LangRef part of the patch. > > > +<p>The union type is used to represent a set of possible data types > which can > > + exist at a given location in memory (also known as an "untagged" > > +

On Fri, Jan 15, 2010 at 11:02 AM, Dan Gohman <gohman at apple.com> wrote: > > On Jan 13, 2010, at 12:11 PM, Talin wrote: > > > > It depends on whether or not unions can be passed around as SSA values or > not. I can think of situations where you would want to. > > I'm skeptical that you *really* want to (i.e. that you wouldn't > be better off just

On Thursday 01 January 2009 00:57:50 Talin wrote: > Jon Harrop wrote: > > I think very few people are still using C-style unions so there is > > probably little desire to put them into LLVM itself. Class hierarchies > > and algebraic datatypes are much more common and use a different > > representation (that LLVM can already handle with bitcasts). > > Specifically,

On Jan 6, 2010, at 12:45 PM, Talin wrote: > This patch adds a UnionType to DerivedTypes.h. Cool. When proposing an IR extension, it is usually best to start with a LangRef.html patch so that we can discuss the semantics of the extension. Please do write this before you get much farther. I assume that you want unions usable in the same situations as a struct. However, how do "constant

On Tue, Jul 20, 2010 at 8:34 AM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 20, 2010, at 1:36 AM, Anton Korobeynikov wrote: > > >> used to make the code manipulating the union type "well typed". This > >> approach seems work very well, is there really a need to keep union type > in > >> LLVM? > > I think in its current

On Wed, Feb 17, 2010 at 12:05 PM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 16, 2010, at 12:38 PM, Talin wrote: > > > Here's the implementation of > ConstantUnion::replaceUsesOfWithOnConstant(). No tests yet :( > > Seems basically ok, please commit. > > I suppose that means that I'll have to send in the info to get commit access then :(

I removed unions from mainline in r112356. -Chris On Jul 20, 2010, at 2:46 PM, Talin wrote: > On Tue, Jul 20, 2010 at 8:34 AM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 20, 2010, at 1:36 AM, Anton Korobeynikov wrote: > > >> used to make the code manipulating the union type "well typed". This > >> approach seems work very well, is

Responding to everyone in one post: Eli Friedman wrote: >> At the moment, the only way I know to achieve this right now is to >> create a struct that is as large as the largest type in the union and then >> bitcast it to access the fields contained within. However, that requires >> that the frontend know the sizes of all of the various low-level types (the >>

Here's a suggestion - can we make the "union patch" (the inverse of the patch that removed unions) as a downloadable file so that people who are interested in finishing the work can do so? On Tue, Sep 7, 2010 at 7:55 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 7 September 2010 15:36, Anton Korobeynikov <anton at korobeynikov.info> > wrote: > >

Chris Lattner wrote: > On Dec 30, 2008, at 12:41 PM, Talin wrote: > >> I've been thinking about how to represent unions or "disjoint types" >> in LLVM IR. At the moment, the only way I know to achieve this right >> now is to create a struct that is as large as the largest type in >> the union and then bitcast it to access the fields contained

On 01/15/2010 11:37 AM, Talin wrote: > 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. I agree. I probably shouldn't even comment, as I know so little about LLVM. But I've hand-written a couple kLOC of IR now and am starting to get a feel for the

On Dec 30, 2008, at 12:41 PM, Talin wrote: > I've been thinking about how to represent unions or "disjoint types" > in LLVM IR. At the moment, the only way I know to achieve this right > now is to create a struct that is as large as the largest type in > the union and then bitcast it to access the fields contained within. > However, that requires that the

Chris Lattner wrote: > > a) What is required for them to be accepted back in? > > It needs to work. When reverted, it was broken in almost all cases. 'It needs work' and 'it was broken' doesn't really give me an idea of what specifically is required. Specifically, what I am interested in is using unions within packed structs to force alignment. Using unions

I wanted to mention, by the way, that my need/desire for this hasn't gone away :) And my wish list still includes support for something like uintptr_t - a primitive integer type that is defined to always be the same size as a pointer, however large or small that may be on different platforms. (So that the frontend doesn't need to know how big a pointer is and can generate the same IR

On Fri, Jan 15, 2010 at 12:41 AM, Joachim Durchholz <jo at durchholz.org>wrote: > 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.