search for: bail_to_interpreter

...as: >> >> ``` >> void @llvm.guard_on(i1 %pred) { >> entry: >> %unknown_cond = < unknown source > >> %cond = and i1 %unknown_cond, %pred >> br i1 %cond, label %left, label %right >> >> left: >> call void @bail_to_interpreter() [ "deopt"() ] noreturn >> unreachable >> >> right: >> ret void >> } >> ``` >> >> So, precisely speaking, `@llvm.guard_on` is guaranteed to bail to the >> interpreter if `%pred` is false, but it **may** bail to the &gt...

...e 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 to bail_to_interpreter"? That mostly works, except that it does not allow "widening" type optimizations, as discussed in the very first email. > lowering will likely need to surface some amount of that control flow. > Though I'm not quite sure how you want the intrinsic to perform in the face &...

...ils: semantics ## as-if control flow The observable behavior of `@llvm.guard_on` is specified as: ``` void @llvm.guard_on(i1 %pred) { entry: %unknown_cond = < unknown source > %cond = and i1 %unknown_cond, %pred br i1 %cond, label %left, label %right left: call void @bail_to_interpreter() [ "deopt"() ] noreturn unreachable right: ret void } ``` So, precisely speaking, `@llvm.guard_on` is guaranteed to bail to the interpreter if `%pred` is false, but it **may** bail to the interpreter if `%pred` is true. It is this bit that lets us soundly widen `%pred`, si...

...does not return)." Yes, implementing that will be a bit > complicated, but I don't see this as a fundamental issue. Yup, and this is a property of deopt operand bundles, not just guards. >> How is it more general? > > You can express 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...

...n` is specified as: > > ``` > void @llvm.guard_on(i1 %pred) { > entry: > %unknown_cond = < unknown source > > %cond = and i1 %unknown_cond, %pred > br i1 %cond, label %left, label %right > > left: > call void @bail_to_interpreter() [ "deopt"() ] noreturn > unreachable > > right: > ret void > } > ``` > > So, precisely speaking, `@llvm.guard_on` is guaranteed to bail to the > interpreter if `%pred` is false, but it **may** bail to the > interp...