search for: exception_on

...ng guards. ## environments without support for bailing to the interpreter Our VM has deeply integrated support for deoptimizations, but not all language runtimes do. If there is a need for non deoptimizing guards, we can consider introducing a variant of `@llvm.guard_on`: ``` declare void @llvm.exception_on(i1 %predicate, i32 %exceptionKind) ``` 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`. ## memory effects (unresolved) [I haven't come up with a good mode...

...interpreter > > Our VM has deeply integrated support for deoptimizations, but not all > language runtimes do. If there is a need for non deoptimizing > guards, we > can consider introducing a variant of `@llvm.guard_on`: > > ``` > declare void @llvm.exception_on(i1 %predicate, i32 %exceptionKind) > ``` > > 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`. > > ## memory effects...

...; 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. A valid implementation of the side exit > handler (which would do the OSR for us) is to call a runtime routine which > generates and throws the exception. The only bit we might need is a > distinction between widdenable and non-widenable guards...