search for: guard_on

...ow as simple and "straight line"-like as is reasonable - To allow certain kinds of "widening" transforms that cannot be soundly done in an explicit "check-and-branch" control flow representation ## straw man specification Signature: ``` declare void @llvm.guard_on(i1 %predicate) ;; requires [ "deopt"(...) ] ``` Semantics: `@llvm.guard_on` bails out to the interpreter (i.e. "deoptimizes" the currently execution function) if `%predicate` is `false`, meaning that after `@llvm.guard_on(i1 %t)` has executed `%t` can be assumed to be true. I...

...- To allow certain kinds of "widening" transforms that cannot be > soundly done in an explicit "check-and-branch" control flow > representation > > ## straw man specification > > Signature: > > ``` > declare void @llvm.guard_on(i1 %predicate) ;; requires [ > "deopt"(...) ] > ``` > > Semantics: > > `@llvm.guard_on` bails out to the interpreter (i.e. "deoptimizes" the > currently execution function) if `%predicate` is `false`, meaning that > after `@llvm.gu...

...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 Wed, Feb 17, 2016 at 3:40 PM, Philip Reames <listmail at philipreames.com> wrote: >> one very important difference -- `@llvm.guard_on(i1 <false>)` is well >> defined (and not UB). `@llvm.guard_on` on a false predicate bails to >> the interpreter and that is always safe (but slow), and so >> `@llvm.guard_on(i1 false)` is basically a `noreturn` call that >> unconditionally transitions the current comp...

...fine i64 @g() { if (Y) { if (X) return side_exit() [ "deopt"(Y, X) ]; print(20); } } and not define i64 @g() { if (Y) { r = X ? (side_exit() [ "deopt"(Y, X) ]) : 20; print(r); } # step C: Introduce a `guard_on` intrinsic Will be based around what was discussed / is going to be discussed on this thread. (I think Philip was right in suggesting to split out a "step B" that only introduces a `side_exit` intrinsic. We *will* have to specify them, since we'd like to optimize some after we'...

...ays okay to remove" may have leaked into other parts of LLVM. > BTW, if you do want readonly semantics, why would you want readonly > to be implicit instead of explicit? I don't understand the question. :) What's explicit vs. implicit here? > I think you would need to mark @guard_on as may-unwind AND fix any > lingering assumptions in LLVM that readonly calls are nounwind. (Loads > can be CSE's across unwind calls but can't be hoisted across them). Yes, but a failed guard doesn't exactly "unwind". I.e. if A invokes B and B fails a guard, then the...

...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 notion of of "deopt bundles are readonly" is broken to begin with, and that is what's manifesting as the complication we're seeing here. Consider something like ``` declare @foo() readonly def @bar() { call...

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

...gt; strategies. For example, not all 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