search for: deopt

...reames.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 notion of of "deopt bundles are readonly" is broken to begin with, and that is what's manifesting as the complication we're seeing here. Consider something like ``` declare @foo() readonly def @bar() { call @foo() [ "deopt"(XXX) ] } def @baz() { ca...

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

...ompilation stack" which can be an actual interpreter, a "splat compiler" or even a regular JIT that doesn't make optimistic assumptions. By "bailing out to the interpreter" I mean "side exit" as defined by Philip in http://www.philipreames.com/Blog/2015/05/20/deoptimization-terminology/ # high level summary Guard intrinsics are intended to represent "if (!cond) leave();" like control flow in a structured manner. This kind of control flow is abundant in IR coming from safe languages due to things like range checks and null checks (and overflow ch...

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

[+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 waiting for an okay from you guys. LLILC...

On Wed, 9 Sep 2020 at 19:26, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > - Default (i.e. no -profile-deopt-cold): do nothing > - Option with no arg (i.e. -profile-deopt-cold): add attribute only to > functions that have an execution count of zero > - Option with an arg (i.e. -profile-deopt-cold=<N>): add attribute to > functions that account for <N>% of total execution counts &gt...

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

...or dynamic languages (e.g. Javascript and Python) that adopt a multi-tier compilation model: Only “hot” functions or execution traces will be brought to higher-tier compilers for aggressive optimizations. In addition to de-optimizing on functions whose profiling counts are exactly zero (`-fprofile-deopt-cold`), we also provide a knob (`-fprofile-deopt-cold-percent=<X percent>`) to adjust the “cold threshold”. That is, after sorting profiling counts of all functions, this knob provides an option to de-optimize functions whose count values are sitting in the lower X percent. We evaluated this...

This is a follow up on a conversation some of us had at the hacker lab -- I noticed that sometimes I will get notified that a deopt value lives in a register that is not callee-save (caller-save I guess, but is there another term for this that is less similar to callee-save?). This surprised me quite a bit since those registers immediately got clobbered by the call inside the patchpoint, so we were discussing whether this is t...

...duce an `interposable` function attribute We can bike shed on the name and the exact specification, but the general idea is that you cannot do IPA / IPO over callsites calling `interposable` functions without inlining them. This attribute will (usually) have to be used on function bodies that can deoptimize (e.g. has a side exit / guard it in); but also has more general use cases. # step B: Introduce a `side_exit` intrinsic Specify an `@llvm.experimental.side_exit` intrinsic, polymorphic on the return type: - Consumes a "deopt" continuation, and replaces the current physical sta...

...ive up using it. Here is an alternative approach to representation of guards that resolves some of fundamental flaws that the current guards have. Basically, this intrinsic was introduced to model the following situation: we want to check that some condition is true, and if it's not, we should deoptimize at this point and quit execution of the compiled code. According to http://llvm.org/docs/LangRef.html#llvm-experimental-guard-intrinsic, the guard looks like this: define void @llvm.experimental.guard(i1 %pred, <args...>) { %realPred = and i1 %pred, undef br i1 %realPred, label %con...

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 >>> throughout our code. (i.e. we're consistent, but swapped on the >>> documented meaning) I've asked Sanjoy to confirm that, and if he >>> believes that is act...

...at apple.com> wrote: > This clearly doesn't need operand bundles, but using an intrinsic > would permit special code motion semantics. It could be hoisted and > merged with other traps, but the condition could never be widened > beyond the union of the original conditions. Unlike deoptimizing > guards, it would need to be sequenced with memory barriers, but could By memory barrier, do you mean things like fences? > otherwise be hoisted as readnone. Can you clarify this a little bit? Are you talking about things like: *ptr = 42 @trap_if(%foo) => @trap_if(%foo)...

...d function, with the bundled operands escaped into those external functions which may capture, etc. This both gives you the escape semantics, and it gives you something else; the runtime function might not return! That should (I think) exactly capture the semantic issue you were worried about with deopt. Because control may never reach the called function, or may never return to the caller even if the callee returns, code motion of side-effects would be clearly prohibited. Does this make sense as an approach to specifying things? (Or worse, are you already there, and I'm just arriving late to...

...re is an alternative approach to representation of guards that resolves some of fundamental flaws that the current guards have. > > > > Basically, this intrinsic was introduced to model the following situation: we want to check that some condition is true, and if it's not, we should deoptimize at this point and quit execution of the compiled code. According to http://llvm.org/docs/LangRef.html#llvm-experimental-guard-intrinsic, the guard looks like this: > > > > define void @llvm.experimental.guard(i1 %pred, <args...>) { > > %realPred = and i1 %pred, undef...

...ce in that case it seems reasonable to receive a >> caller-save register if you are interested in using it inside the >> patchpoint. My thoughts are that in that case you might be better off >> including the value as part of the function arguments instead of the >> stackmap/deopt arguments. > > I don't see why anything needs to be different for patchpoints running > with anyregcc. The call arguments always get lowered based on the > calling convention, the "live on call" values get arbitrary stack > slots / registers and the "live on retu...

> 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 > believes that is actually the case, we will fix up...

...also worth noting that @llvm.guard_on(i1 true) is useful and well > defined as well. When lowering, such a guard simply disappears, but it can > be useful to keep around in the IR during optimization. It gives a well > defined point for widening transforms to apply with a well known > deoptimization state already available. Yes! Actually, I had exactly this in an earlier version of this writeup, which I removed to make the (already long) RFC shorter. > I'd suggest a small change to Sanjoy's declaration. I think we should allow > additional arguments to the guard, not...

Hello, list I am not quite sure if what I'm experiencing is a bug or intentional behavior. In the code below the result of a function call is a deopt arg to llvm.experimental.gc.statepoint (http://llvm.org/docs/Statepoints.html#llvm-experimental-gc-statepoint-intrinsic). Therefore a Stack Map containing location of this variable is created upon code generation. Here's the complete example: define i64 addrspace(1)* @func() {...

On Wed, 9 Sep 2020 at 14:27, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > A more aesthetic comment I have is that personally, I would prefer a > single option with a default percentage (say 0%) rather than having to > specify two options. > 0% doesn't mean "don't do it", just means "only do that to functions I didn't see running at