similar to: Operand bundles

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

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

On 9/3/15, 3:34 PM, "Mehdi Amini" <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: Hi, On Sep 3, 2015, at 1:38 PM, Maksim Panchenko via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi All, Our team at Hip-Hop Virtual Machine (http://hhvm.com<http://hhvm.com/>) have been experimenting with using LLVM

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

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

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

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

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

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

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

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

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

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

Hello everyone, I've just uploaded a patch (https://reviews.llvm.org/D70261) to introduce a could of new token types to be used with constrained floating point intrinsics and, optionally, vector predicated intrinsics. These intrinsics may not be of interest to many of you, but I have a more general question. I would like some general feedback on the way I am proposing to use token arguments

dear Hackers, i have a voicetronix Openswitch card, and i have been finding it very dificult to get it to work with asterisk. i intend to connect 8 ports to the PSTN and 4 as station ports. problem 1: On running asterisk all i get at first i get : event[9=>[11] station OFF hook] on vpb/1-12 even [12=>[11] loop drop on vpb/1-12 event [12=>[11] Tone detect:GRUNT event [2=>[11] Dial