similar to: [LLVMdev] Suggestion: Support union types in IR

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: > 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

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 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

Talin 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

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 >>

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 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 writing helper functions in your front-end which do the addressing and load/store and then moving on). But, I'm not

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 May 5, 2009, at 8:09 PM, Talin wrote: > 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

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 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,

Here is the LangRef part of the patch. On Tue, Jan 12, 2010 at 2:11 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 11, 2010, at 4:30 PM, Talin wrote: > > I'm working on a new version of the patch. >> >> Another thing I wanted to ask about - do you prefer to have one giant >> patch that has everything, or a series of incremental patches? I can

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 Mon, Mar 7, 2011 at 4:08 AM, nicolas geoffray <nicolas.geoffray at gmail.com > wrote: > Hi Talin, > > On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: >> >> >> So I've been thinking about your proposal, that of using a special address >> space to indicate garbage collection roots instead of intrinsics. > > > Great!

Hi, I'm working on developing a programming language using LLVM as a backend, and it'd be very handy for me if LLVM had union support. I've been looking into getting the previous union implementation working properly for the last week or so, but I'm entirely new to the LLVM codebase so I thought I'd ask whether I'm barking up the wrong tree before doing a full-blown

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 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 :(

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

I'm still working on the next patch, it's going somewhat slowly. I wanted to create a unit test that actually created a union, and in order to do that I had to implement constant unions. And rather than creating a special syntax for constructing a union, I decided that it was simplest to implement the insertvalue instruction for a constant union expression: @foo = constant union {