similar to: RFC: Add "operand bundles" to calls and invokes

----- Original Message ----- > From: "David Majnemer" <david.majnemer at gmail.com> > To: "Sanjoy Das" <sanjoy at playingwithpointers.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Chandler Carruth" > <chandlerc at gmail.com>, "Nick

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

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

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

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

Just wanted to confirm that I too like where this is going. =] I think Philip and others have really handled the bulk of the review, and I'm very comfortable with them finishing the patch review. One issue where I wanted to chime in, hopefully just to add some clarity, is the "readonly" vs operand bundle set of (interrelated) issues. First, as I think Philip already said, I think

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.

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

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

Looks good to me too. Thanks. Swaroop. -----Original Message----- From: Philip Reames [mailto:listmail at philipreames.com] Sent: Wednesday, August 19, 2015 6:55 PM To: Sanjoy Das <sanjoy at playingwithpointers.com> Cc: Hal Finkel <hfinkel at anl.gov>; David Majnemer <david.majnemer at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; Chandler Carruth <chandlerc at

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

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

A high level summary of the proposal as it stands right now (from my perspective), after incorporating Philip's suggestions: 1. Operand bundles are a way to associate a set of SSA values with a call or invoke. 2. Operand bundles are lowered in some arbitrary bundle-tag specific manner. 3. The optimizer can optimize around operand bundles with (roughly) the assumption that

I missed the discussion on adding operand bundles to LLVM IR, can anyone send me a pointer to the proposal? -Chris

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

On 9/4/15 1:12 AM, Sanjoy Das via llvm-dev wrote: > Specifically on "Location records" -- > > Is it legal for the optimizer to drop the `!locrec` metadata that you > attach to instructions? The general convention in LLVM is that > dropping metadata should not affect correctness, and if the location > record information is not best-effort or optional then metadata is

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