similar to: llvm.experimental.gc.statepoint genarates wrong Stack Map (or does it?)

> Vlad, > > My initial impression is that you've stumbled across a bug. I suspect > that we - the only active users of the deopt info in the statepoint I > know of - have been inverting the meaning of Direct and Indirect > throughout our code. (i.e. we're consistent, but swapped on the > documented meaning) I've asked Sanjoy to confirm that, and if he >

Hi, Sanjoy, On 2015-11-16 23:27, Sanjoy Das wrote: > Hi Vlad, > > vlad via llvm-dev wrote: >>> Vlad, >>> >>> My initial impression is that you've stumbled across a bug. I suspect >>> that we - the only active users of the deopt info in the statepoint I >>> know of - have been inverting the meaning of Direct and Indirect >>>

Hi David, Sorry to bother you, but I would like to get some suggestions on your recent work of token type. I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid

> On Dec 1, 2015, at 11:14 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > While we support 'opaque' types nested within struct types, they are not exactly battle tested: > > $ cat t.ll > %opaque_ty = type opaque > > %struct_ty = type { i32, %opaque_ty } > > define %struct_ty @f(%struct_ty* %p) { > %load = load %struct_ty,

> I dont have a concrete design right now and I am happy to take any other ideas Three ideas come to mind, none of which are perfect: 1) I'm tempted to say that now that we have token type, landingpad should generally produce a token, the pointer should be extracted with the @llvm.eh.exceptionpointer intrinsic instead of an extractvalue, and the selector should likewise be extracted with

It seems a little backwards to me to check the landingpad's type as the first check, since the personality dictates the landingpad's type. That said, yes I see how #4 is expedient in allowing personalities using the two main types to lump themselves into EHPersonality::Unknown. As for supporting selector and exception pointer extraction for landingpad of token type, I think you'll

As part of adding `"deopt"` operand bundles, we're aiming to change RewriteStatepointsForGC (called RS4GC henceforth) from rewriting existing `gc.statepoint` calls to transforming normal LLVM calls and invokes into `gc.statepoint` calls and invokes (i.e. to do PlaceSafepoints + RS4GC in one step). This will make `gc.statepoint` an artifact of the gc lowering strategy that only

I actually need this feature quite badly in my untyped language compiler: since I support first-class functions, I've made the types of all functions a standard vararg (so I can box them). The implementation crashes when I try to read out the value of gc.result. Hints as to what might be wrong? Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> ---

Hi Martin, Philip covered all of it very well, I'll just add one minor comment: > More generally, can I back up and ask an important question? Do you have to > support deoptimization (i.e. osr side exits) in any form? If you do, you'll > probably want to avoid the PlaceSafepoints utility pass. If you need to PlaceSafepoints is inadequate only if you have asynchronous

Hello LLVM community, We have been experimenting with using LLVM IR as a target for a managed (dynamically typed) language via an AOT compiler (including a backend for ARM). One main challenge is getting the garbage collection right: We would like to be able to implement a moving collector. This requires us to a) find a precise set of root pointers and b) be able to rewrite those pointers after

The long term plan is a) evolving, and b) dependent on the specific use case. :) It would definitely be nice if we could support both early and late safepoint insertion. I see no reason that LLVM as a project should pick one or the other since the infrastructure required is largely overlapping. (Obviously, I'm going to be mostly working on the parts that I need, but others are always

Hi all, I am trying to implement statepoints for the AArch64 target and I’m running into the issue where the following bitcode: define i32 addrspace(1)* @test(i32 addrspace(1)* %ptr) gc "statepoint-example" { entry: call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @foo, i32 0, i32 0, i32 0, i32 0, i32 addrspace(1)* %ptr) ret

[+CC llvm-dev this time] Hi, As discussed in the review thread in http://reviews.llvm.org/D16439, the future plan around statepoints, deopt bundles, PlaceSafepoints etc. is to "constant fold" -spp-no-statepoints and -rs4gc-use-deopt-bundles to true. We (Azul) have moved to a representation of safepoint polls, deopt state etc. that enables us to do the above; and at this point I'm

I've been looking at inlining invokes / calls done through statepoints and I want to have a design discussion before I sink too much time into something I'll have to throw away. I'm not actively working on adding inlining support to patchpoints, but I suspect these issues are applicable towards teaching LLVM to inline through patchpoints as well. There are two distinct problems to

Sanjoy Das wrote: > In your > example, foo will have to treat its argument differently depending on > whether it is a GC pointer or not. In practice, this is not true of many functions that don't call other functions. Take the example of a simple "print" function that takes a void * to cast and print, type_int to determine what to cast to: why should it care about whether

Andy - If you're not already following this closely, please start. We've gotten into fairly fundamental questions of what a patchpoint does. Filip, I think you've hit the nail on the head. What I'm thinking of as being patchpoints are not what you think they are. Part of that is that I've got a local change which adds a very similar construction (called

On May 2, 2014 at 11:53:25 AM, Eric Christopher (echristo at gmail.com) wrote: On Wed, Apr 30, 2014 at 10:34 PM, Philip Reames  <listmail at philipreames.com> wrote:  > Andy - If you're not already following this closely, please start. We've  > gotten into fairly fundamental questions of what a patchpoint does.  >  > Filip,  >  > I think you've hit the nail on

Sanjoy gave the long answer, let me give the short one. :) "deopt" argument bundles are used in the middle end, they are lowered into a statepoint, and generate the existing stackmap format. i.e. one builds on the other. On 02/18/2016 11:43 AM, Eric Christopher wrote: > Hi Sanjoy, > > A quick question here. With the bailing to the interpreter support > that you're

Hi! We have started to use deopt operand bundle to make our native stacktrace deoptimizable and garbage collectable. We stumbled upon an issue and we don't know if it is really an issue on our side or really a problem within LLVM. For example, for this input: declare { i8*, i8* } @getCode() define void @testFunc() { entry: %0 = call { i8*, i8* } @getCode() %1 = extractvalue { i8*, i8* }

On Wed, Feb 17, 2016 at 8:53 PM, Philip Reames <listmail at philipreames.com> wrote: > I think you're jumping ahead a bit here. I'm not sure the semantics are > anywhere near as weird as you're framing them to be. :) I now think this weirdness actually does not have to do anything with guard_on or bail_to_interpeter, but it has to do with deopt bundles itself. Our