similar to: [LLVMdev] Status of first-class aggregate types

On Dec 20, 2009, at 12:27 AM, Talin wrote: > What's the current status on support for first-class structs? The last I heard was: > Structs which are smaller or equal to two pointers can be passed / returned / loaded / stored by value. > There are plans to expand this in the future to support arbitrary-sized structs as first class values. (Probably via some transformation pass the

On Sun, Dec 20, 2009 at 9:50 AM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 20, 2009, at 12:27 AM, Talin wrote: > > What's the current status on support for first-class structs? The last I > heard was: > > - Structs which are smaller or equal to two pointers can be passed / > returned / loaded / stored by value. > - There are plans to

On Dec 20, 2009, at 10:27 AM, Talin wrote: > I'd pass them by value if they are small but by reference if they are large. Passing large tuples by value isn't going to provide a win. > > OK, thanks for that confirmation, now I can proceed ahead with less trepidation. :) > > For large aggregates (well, not huge, but the size of a typical structure or class), do you

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

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 {

On Apr 27, 2008, at 12:49 PM, Nick Lewycky wrote: > Chris Lattner wrote: >> On Apr 27, 2008, at 10:58 AM, Talin wrote: >> >>> I would certainly make use of this in my frontend. >>> >>> I suggest the names "getfield" and "setfield" for the two >>> operations, >>> >> >> I agree that

On Apr 27, 2008, at 10:58 AM, Talin wrote: > I would certainly make use of this in my frontend. > > I suggest the names "getfield" and "setfield" for the two operations, > I agree that 'get/insertvalue' are pretty generic, and am welcome to suggestions. Get/set *field* imply that this applies only to structs, but it also works with arrays. I would

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

On Mon, Feb 21, 2011 at 1:50 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > On Fri, Feb 18, 2011 at 5:50 PM, Talin <viridia at gmail.com> wrote: >> >> >> In the current scheme, the way you tell LLVM that a root is no longer >> needed is by assigning NULL to it. However, that assumes that all roots are >> pointers,

On 01/07/2010 01:38 PM, David Greene wrote: > The way this works on many targets is that the caller allocates stack > space in its frame for the returned struct and passes a pointer to it > as a first "hidden" argument to the callee. The callee then copies > that data into the space pointed to by the address. <nod> > Long-term, first-class status means that

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!

On Fri, Feb 18, 2011 at 1:05 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > On Fri, Feb 18, 2011 at 1:36 AM, Talin <viridia at gmail.com> wrote: >> >> Thinking about it even more, here's a short summary of what I would >> propose: >> >> - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage

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

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! > > To address this, we need a better way of telling LLVM that a given variable > is no longer a root. > Live variable

On Jan 16, 2010, at 11:15 AM, Talin wrote: > OK here's the patch for real this time :) > > On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test > "union.ll" does not work, so you probably don't want to check this > in as is. However, I'd be interested in any

On 2008-04-27, at 15:56, Chris Lattner wrote: > On Apr 27, 2008, at 12:49 PM, Nick Lewycky wrote: > >> Chris Lattner wrote: >> >>> On Apr 27, 2008, at 10:58 AM, Talin wrote: >>> >>>> I would certainly make use of this in my frontend. >>>> >>>> I suggest the names "getfield" and "setfield" for the two

Hi all, For anyone interested, I posted two new ideas for changes to the LLVM IR. The first is basically a cleanup, the second is a major new feature: Eliminating the 'Void' Type: http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt Aggregates as First Class Values: http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt Thanks to Dan Gohman for convincing me that aggregates

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