similar to: [LLVMdev] Proposal: add intrinsics for safe division

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. I'm still not convinced, but am not going to actively oppose it either. I'm leery of designing a solution with major assumptions we don't have data to backup. I worry your assumptions about

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 the head. What I'm thinking of as being > patchpoints are not what you think

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.

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

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

As the discussion has progressed and I've spent more time thinking about the topic, I find myself less and less enthused about the current proposal. I'm in full support of having idiomatic ways to express safe division, but I'm starting to doubt that using an intrinsic is the right way at the moment. One case I find myself thinking about is how one would combine profiling

On 05/02/2014 11:57 AM, Filip Pizlo wrote: > > On May 2, 2014 at 11:53:25 AM, Eric Christopher (echristo at gmail.com > <mailto: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

On 10/23/13 5:38 PM, Andrew Trick wrote: > > On Oct 23, 2013, at 5:27 PM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >>> The implementation of the two intrinsics is actually very similar. >>> In this case, the difference would be that llvm.stackmap does not >>> reserve space for patching, while

On 10/23/13 10:03 PM, Andrew Trick wrote: > > On Oct 23, 2013, at 7:26 PM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >> On 10/23/13 5:38 PM, Andrew Trick wrote: >>> >>> On Oct 23, 2013, at 5:27 PM, Philip Reames >>> <listmail at philipreames.com <mailto:listmail at

On Oct 23, 2013, at 7:26 PM, Philip Reames <listmail at philipreames.com> wrote: > On 10/23/13 5:38 PM, Andrew Trick wrote: >> >> On Oct 23, 2013, at 5:27 PM, Philip Reames <listmail at philipreames.com> wrote: >> >>>> The implementation of the two intrinsics is actually very similar. In this case, the difference would be that llvm.stackmap does not

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

> On Oct 13, 2014, at 4:07 PM, Philip Reames <listmail at philipreames.com> wrote: > > >> On 10/13/2014 03:23 PM, Kevin Modzelewski wrote: >> With the patchpoint infrastructure, shouldn't it now be relatively straightforward to do an accurate-but-non-relocatable scan of the stack, by attaching all the GC roots as stackmap arguments to patchpoints? This is

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.

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

TLDR - I have a runtime which expects to be able to inspect certain arguments to a function even if that argument isn't used within the callee itself. DeadArgumentElimination doesn't respect this today. I want to add an argument that records an argument to a call as live even if the value is known to be not used in the callee. My use case ----------------- What my runtime is doing

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

Hello Everyone, I want to raise a discussion about @llvm.experimental.guard intrinsic and reasons why we should give 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

On April 25, 2014 at 10:48:18 AM, Reid Kleckner (rnk at google.com) wrote: On Fri, Apr 25, 2014 at 10:19 AM, Filip Pizlo <fpizlo at apple.com> wrote: The sdiv operation in LLVM IR only makes sense for C and its very direct relatives.  The amount of control flow necessary to represent a safe division for any other language is ghastly.  (a/b) becomes something like (b != 0 ? ((a != INT_MIN ||

Hi, I’d like to propose to extend LLVM IR intrinsics set, adding new ones for safe-division. There are intrinsics for detecting overflow errors, like sadd.with.overflow, and the intrinsics I’m proposing will augment this set. The new intrinsics will return a structure with two elements according to the following rules: safe.[us]div(x,0) = safe.[us]rem(x,0) = {0, 1} safe.sdiv(min<T>, -1) =