search for: side_exit

...neral 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 stack frame with one or more interpreter frames (implementation provided by the runtime). - Calls to this intrinsi...

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

...et right in an explicit "check-and-branch" > representation. For instance, the above example in a > "check-and-branch" representation would be (in pseudo C, and excluding > the printf): > > ``` > ... > if (!(6 < %len)) { call @side_exit() [ "deopt"(P) ]; unreachable; } > if (!(7 < %len)) { call @side_exit() [ "deopt"(Q) ]; unreachable; } > ... > ``` > > The following transform is invalid: > > ``` > ... > if (!(7 < %len)) { call @side_exit() [...

...ning and explicit control flow Widening is difficult to get right in an explicit "check-and-branch" representation. For instance, the above example in a "check-and-branch" representation would be (in pseudo C, and excluding the printf): ``` ... if (!(6 < %len)) { call @side_exit() [ "deopt"(P) ]; unreachable; } if (!(7 < %len)) { call @side_exit() [ "deopt"(Q) ]; unreachable; } ... ``` The following transform is invalid: ``` ... if (!(7 < %len)) { call @side_exit() [ "deopt"(P) ]; unreachable; } if (!(true)) { call @side_exit...

Hi everyone, we started a new open source project Sulong: https://github.com/graalvm/sulong. Sulong is a LLVM IR interpreter with JIT compilation running on top of the JVM. By using the Truffle framework, it implements speculative optimizations such as inlining of function pointer calls through AST rewriting. One area of our research is to provide alternative ways of executing LLVM bitcode that

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 Tue, Feb 23, 2016 at 3:34 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > I'm not suggesting that either. I think there is a happy middle ground, but > I'm probably not explaining it very effectively, sorry. Lemme just try > again. > > There are two conceptually separable aspects of IPO as it is commonly > performed within LLVM. One is to use attributes on

...ll IR interacts with an interpreter, and so I > don't think we should use the term "interpreter" to specify the semantic > model exposed by the IR. That's what I was getting at by: >> Chandler raised some points on IRC around making `guard_on` (and >> possibly `side_exit`?) more generally applicable to unmanaged >> languages; so we'd want to be careful to specify these in a way that >> allows for implementations in an unmanaged environments (by function >> cloning, for instance). -- Sanjoy

...a guard as a conditional branch to a @bail_to_interpreter > construct. Without the @bail_to_interpreter (which is the thing which has > those weird aliasing properties we're talking about), you're stuck. I thought earlier you were suggesting bail_to_interpreter is more general than side_exit (when I thought they were one and the same thing), not that bail_to_interpreter is more general than guard. Aside: theoretically, if you have @guard() as a primitive then bail_to_interpreter is just @guard(false). -- Sanjoy

...e it as expansion to a well > known body (pretty much the one Sanjoy gives above). The > @bail_to_interpreter construct could be lowered directly to a function call > to some well known symbol name (which JIT users can intercept and bind to > whatever they want.) Something like __llvm_side_exit seems like a > reasonable choice. SGTM. >> with this one having the semantics that it always throws an exception >> if `%predicate` fails. Only the non-widening optimizations for >> `@llvm.guard_on` will apply to `@llvm.exception_on`. > > Not sure we actually need this...