Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Recommended order between llvm.gcroot and llvm.dbg.declare?"
2011 Feb 17
0
[LLVMdev] llvm.gcroot suggestion
On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote:
> I think I'm one of the few people actually using LLVM's support for garbage
> collection, and so far I've found it very difficult to generate code that
> uses llvm.gcroot() correctly.
>
> In the current scheme, it is the frontend's responsibility to insure that
> any intermediate SSA
2010 Sep 26
0
[LLVMdev] Strange exception in SelectionDAGBuilder
Hi Talin,
I think that the framework for GC assumes llvm.gcroot to be in the first
block. If it is not the case in your example, it will break these
assumptions.
Nicolas
On Sun, Sep 26, 2010 at 1:38 AM, Talin <viridia at gmail.com> wrote:
> I'm working on the code to handle GC tracing of "intermediate values" (as
> described in the GC doc), and I've run into a
2011 Feb 17
4
[LLVMdev] llvm.gcroot suggestion
I think I'm one of the few people actually using LLVM's support for garbage
collection, and so far I've found it very difficult to generate code that
uses llvm.gcroot() correctly.
In the current scheme, it is the frontend's responsibility to insure that
any intermediate SSA values containing references to garbage collectible
objects are copied to stack variables so that the GC
2010 Sep 25
0
[LLVMdev] Patch to allow llvm.gcroot to work with non-pointer allocas.
On Sat, Sep 25, 2010 at 10:51 AM, nicolas geoffray <
nicolas.geoffray at gmail.com> wrote:
> I didn't have unions in mind - indeed you need some kind of static
> information in such a case. The GC infrastructure in LLVM having so little
> love, I think it is good if you can improve it in any ways, as well as
> defining new interfaces.
So the patch is OK then? All it does
2010 Sep 25
2
[LLVMdev] Patch to allow llvm.gcroot to work with non-pointer allocas.
I didn't have unions in mind - indeed you need some kind of static
information in such a case. The GC infrastructure in LLVM having so little
love, I think it is good if you can improve it in any ways, as well as
defining new interfaces.
Cheers,
Nicolas
On Sat, Sep 25, 2010 at 6:38 PM, Talin <viridia at gmail.com> wrote:
> On Sat, Sep 25, 2010 at 1:04 AM, nicolas geoffray <
>
2011 Feb 18
3
[LLVMdev] llvm.gcroot suggestion
On Thu, Feb 17, 2011 at 1:07 PM, Talin <viridia at gmail.com> wrote:
> On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote:
>
>> I think I'm one of the few people actually using LLVM's support for
>> garbage collection, and so far I've found it very difficult to generate code
>> that uses llvm.gcroot() correctly.
>>
>> In
2010 Sep 25
2
[LLVMdev] Strange exception in SelectionDAGBuilder
I'm working on the code to handle GC tracing of "intermediate values" (as
described in the GC doc), and I've run into a weird problem. (Note, this has
nothing to do with the patch I have proposed, this error occurs with regular
old pointer-allocas.)
The exception I am getting occurs in this code here in
SelectionDAGBuilder.cpp:
*case* *Intrinsic*::gcroot:
*if* (GFI) {
2010 Sep 22
3
[LLVMdev] Patch to allow llvm.gcroot to work with non-pointer allocas.
I'm moving this thread to llvm-dev in the hopes of reaching a wider
audience.
This patch relaxes the restriction on llvm.gcroot so that it can work with
non-pointer allocas. The only changes are to Verifier.cpp - it appears from
my testing that llvm.gcroot always worked fine with non-pointer allocas,
except that the verifier wouldn't allow it. I've used this patch to build an
2010 Sep 25
2
[LLVMdev] Patch to allow llvm.gcroot to work with non-pointer allocas.
Hi Talin,
On Sat, Sep 25, 2010 at 4:18 AM, Talin <viridia at gmail.com> wrote:
>
>
> Many languages support the notion of a "value type". Value types are always
> passed by value, unlike reference types which are always passed by
> pointer. An example is the "struct" type in C#. Another example is a "tuple"
> type. A value type which is a
2010 Sep 25
0
[LLVMdev] Patch to allow llvm.gcroot to work with non-pointer allocas.
On Sat, Sep 25, 2010 at 1:04 AM, nicolas geoffray <
nicolas.geoffray at gmail.com> wrote:
> Hi Talin,
>
> On Sat, Sep 25, 2010 at 4:18 AM, Talin <viridia at gmail.com> wrote:
>>
>>
>> Many languages support the notion of a "value type". Value types are
>> always passed by value, unlike reference types which are always passed by
>>
2010 May 01
1
[LLVMdev] Using gcroot with value types
On 04/29/10 21:27, Talin wrote:
> On Wed, Apr 28, 2010 at 12:16 PM, Paul Melis
> <llvm at assumetheposition.nl <mailto:llvm at assumetheposition.nl>> wrote:
>
> On 04/27/10 00:20, Talin wrote:
>> On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis
>> <llvm at assumetheposition.nl <mailto:llvm at assumetheposition.nl>> wrote:
>>
>>
2010 Sep 25
0
[LLVMdev] Patch to allow llvm.gcroot to work with non-pointer allocas.
On Fri, Sep 24, 2010 at 10:44 AM, nicolas geoffray <
nicolas.geoffray at gmail.com> wrote:
> Thanks for the heads up Chris.
>
> Talin, how is your GC dealing with non-pointers (be it allocas or not)?
> What is the use-case (either in C or LLVM)?
>
Many languages support the notion of a "value type". Value types are always
passed by value, unlike reference types
2010 Apr 28
2
[LLVMdev] Using gcroot with value types
On 04/27/10 00:20, Talin wrote:
> On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis
> <llvm at assumetheposition.nl <mailto:llvm at assumetheposition.nl>> wrote:
>
> Hi,
>
> Talin wrote:
> > I'm a little confused as to the rules for the arguments to
> llvm.gcroot,
> > which says it must be a pointer alloca. I'm not sure whether
2010 Apr 26
2
[LLVMdev] Using gcroot with value types
Hi,
Talin wrote:
> I'm a little confused as to the rules for the arguments to llvm.gcroot,
> which says it must be a pointer alloca. I'm not sure whether that means it
> must be an alloca (which is always a pointer by definition) or an alloca
> *of* a pointer.
I'm pretty sure it should be "alloca of a pointer", as the first argument
of llvm.gcroot has type i8**.
2010 Apr 29
0
[LLVMdev] Using gcroot with value types
On Wed, Apr 28, 2010 at 12:16 PM, Paul Melis <llvm at assumetheposition.nl>wrote:
> On 04/27/10 00:20, Talin wrote:
>
> On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis <llvm at assumetheposition.nl>wrote:
>
>> Hi,
>>
>> Talin wrote:
>> > I'm a little confused as to the rules for the arguments to llvm.gcroot,
>> > which says it must be
2010 Sep 24
2
[LLVMdev] Patch to allow llvm.gcroot to work with non-pointer allocas.
Thanks for the heads up Chris.
Talin, how is your GC dealing with non-pointers (be it allocas or not)? What
is the use-case (either in C or LLVM)?
Nicolas
On Fri, Sep 24, 2010 at 7:00 PM, Chris Lattner <clattner at apple.com> wrote:
> On Sep 22, 2010, at 8:52 AM, Talin wrote:
> > I'm moving this thread to llvm-dev in the hopes of reaching a wider
> audience.
> >
2010 Apr 26
0
[LLVMdev] Using gcroot with value types
On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis <llvm at assumetheposition.nl>wrote:
> Hi,
>
> Talin wrote:
> > I'm a little confused as to the rules for the arguments to llvm.gcroot,
> > which says it must be a pointer alloca. I'm not sure whether that means
> it
> > must be an alloca (which is always a pointer by definition) or an alloca
> > *of* a
2010 Sep 24
0
[LLVMdev] Patch to allow llvm.gcroot to work with non-pointer allocas.
On Sep 22, 2010, at 8:52 AM, Talin wrote:
> I'm moving this thread to llvm-dev in the hopes of reaching a wider audience.
>
> This patch relaxes the restriction on llvm.gcroot so that it can work with non-pointer allocas. The only changes are to Verifier.cpp - it appears from my testing that llvm.gcroot always worked fine with non-pointer allocas, except that the verifier
2010 Oct 23
2
[LLVMdev] Cast failure in SelectionDAGBuilder
I'm trying to track down the problem with the assertion failure in
SelectionDAGBuilder.cpp. This is the code:
*case* *Intrinsic*::gcroot:
*if* (GFI) {
*const* Value *Alloca = I.getArgOperand(0);
*const* Constant *TypeMap = cast<Constant>(I.getArgOperand(1));
* FrameIndexSDNode *FI =
cast<FrameIndexSDNode>(getValue(Alloca).getNode());*
2011 Feb 21
0
[LLVMdev] llvm.gcroot suggestion
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, which is not true in my world - a root can be a struct containing
> pointers inside of it. (In my current frontend, a non-pointer