similar to: Giving up using implicit control flow in guards

Hi Sanjoy, Thanks for feedback! As for memory effects, currently I use " inaccessiblememonly " for it. It allows to prove that it doesn't alias with any other load/store in the function, but doesn't allow CSE to eliminate it. It is not actually super-cool, because there is no way that we can safely hoist it out of loop (and sometimes we want to, for example to make unswitching).

This is a proposal to add guard intrinsics to LLVM. Couple of glossary items: when I say "interpreter" I mean "the most conservative tier in the compilation 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

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 Andy, Thanks for replying, responses inline below: On Fri, Feb 19, 2016 at 11:12 AM, Andrew Trick <atrick 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

Assuming everyone is on the same page, here's a rough high level agenda: # step A: Introduce 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

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

Replies inline. At a high level, it feels like we'll eventually need a new instruction to represent the kind of control flow a guard entails (to be clear: we should probably still start with an intrinsic) -- they are fairly well-behaved, i.e. readonly, nounwind etc. as far as the immediate "physical" caller is concerned, but not so as far as its callers's callers are concerned.

On Thu, Feb 18, 2016 at 12:48 PM, Eric Christopher <echristo at gmail.com> wrote: > Heh. I like his more, but I see where you're coming from as well - the easy > way (for me at least) to look at the guard is as an implicit branch to a > side exit that restores (or communicates) state back to the interpreter. The By "this" do you mean "explicit conditional branch

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 Mon, Feb 22, 2016 at 9:40 PM, Andrew Trick <atrick at apple.com> wrote: > I actually see fences as a proxy for potential inter-process > communication and I/O. It's important that any opaque library call > could contain a fence. This makes perfect sense to me now, especially if you want to use @trap_on for safety checks. Without re-ordering restrictions, a failed @trap_on

> On Oct 31, 2014, at 5:28 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Kevin, > > Thank you for starting this discussion! Yes, sorry for being unresponsive for a few days. Sanjoy summarized the issues perfectly. > I think the distinction is really between whether the live values are > "live on call" or "live on return".

On May 2, 2014, at 4:25 PM, Philip Reames <listmail at philipreames.com> wrote: > > I'm still not happy with hiding the explicit control flow, but I can achieve the same effect as: > if( div by zero ) throw > (r, o, d) = safe.div(a,b); > if( o ) { > r = a; > } > > i.e. emit a separate guard branch for the interesting condition and not utilize the value

On 04/29/2014 12:39 PM, Filip Pizlo wrote: > On April 29, 2014 at 11:27:06 AM, Philip Reames > (listmail at philipreames.com <mailto:listmail at philipreames.com>) wrote: >> On 04/29/2014 10:44 AM, Filip Pizlo wrote: >>> LD;DR: Your desire to use trapping on x86 only further convinces me >>> that Michael's proposed intrinsics are the best way to go.

We'd like to propose a scheme to attach "operand bundles" to call and invoke instructions. This is based on the offline discussion mentioned in http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-July/088748.html. # Motivation & Definition Our motivation behind this is to track the state required for deoptimization (described briefly later) through the LLVM pipeline as a

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

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

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

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

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

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