Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] Status of first-class aggregate types"
2009 Dec 20
0
[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
2009 Dec 20
2
[LLVMdev] Status of first-class aggregate types
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
2009 Dec 21
0
[LLVMdev] Status of first-class aggregate types
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
2010 Jan 13
7
[LLVMdev] [PATCH] - Union types, attempt 2
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
2010 Jan 13
3
[LLVMdev] [PATCH] - Union types, attempt 2
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"
> > +
2010 Jan 13
0
[LLVMdev] [PATCH] - Union types, attempt 2
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
2010 Jan 15
0
[LLVMdev] [PATCH] - Union types, attempt 2
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 {
2008 Apr 27
3
[LLVMdev] Two new 'llvmnotes'
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
2008 Apr 27
2
[LLVMdev] Two new 'llvmnotes'
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 Jan 15
3
[LLVMdev] [PATCH] - Union types, attempt 2
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
2011 Mar 05
2
[LLVMdev] llvm.gcroot suggestion
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,
2010 Jan 07
6
[LLVMdev] First-class aggregate semantics
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
2011 Mar 07
2
[LLVMdev] llvm.gcroot suggestion
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!
2011 Feb 18
2
[LLVMdev] llvm.gcroot suggestion
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 Jan 15
1
[LLVMdev] [PATCH] - Union types, attempt 2
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
2011 Mar 07
0
[LLVMdev] llvm.gcroot suggestion
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
2010 Jan 18
5
[LLVMdev] [patch] Union Types - work in progress
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
2008 Apr 27
0
[LLVMdev] Two new 'llvmnotes'
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
2008 Apr 27
8
[LLVMdev] Two new 'llvmnotes'
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
2010 Jan 15
0
[LLVMdev] [PATCH] - Union types, attempt 2
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
> >