search for: trap_if

...the original conditions. Unlike deoptimizing > guards, it would need to be sequenced with memory barriers, but could By memory barrier, do you mean things like fences? > otherwise be hoisted as readnone. Can you clarify this a little bit? Are you talking about things like: *ptr = 42 @trap_if(%foo) => @trap_if(%foo) *ptr = 42 ? I.e. if a failing guard postdominates a point "P" in the program, then the guard can be failed early at P. (We'd want a stronger condition than postdomination, since we won't want to hoist while (!*cond) { } @trap_if(*cond)...

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