search for: trap_on

...6 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 will end up looking a lot like UB (since, say, you could reorder a failing range check across a call to fflush); and so that would be bad. You'd still have to be careful around inaccessiblememonly and friends, though. --...

Hi Andy, Responses inline: On Mon, Feb 22, 2016 at 10:08 AM, Andrew Trick <atrick at apple.com> wrote: >> By memory barrier, do you mean things like fences? > That’s right. Conservatively, I would not hoist at the LLVM level past > opaque non-readonly calls or fences. Just for curiosity: why do you care about memory fences specifically? > I've begun to think that

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