[LLVMdev] Proposal: Loads/stores with deterministic trap/unwind behavior

[Philip Reames]

On 04/02/2014 07:44 AM, Joe Ranieri wrote:
> On Wed, Apr 2, 2014 at 8:18 AM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
>> libc++abi's unwind doesn't really support unwinding through signal
>> handlers, at least it wouldn't do anything special for them. I don't
>> have the faintest idea what the correct semantic would even be. Does it
>> restore the saved signal mask? Can you even unwind past the frame? In
>> general you won't as unwind instructions are not precise/
>>
>> Joerg
> I've done a similar scheme in the past using Mach exception handlers.
> Basically there's a thread running that gets told when bad memory
> accesses happen and it has access to all of that thread's register
> state. Given the state, it determines whether or not an exception
> should be thrown (e.g. is the current instruction pointer is in user
> code). Then it changes the thread's register state in order to push a
> new stack frame and call the function that raises the exception. Once
> all of the setup is done, the thread is resumed and things go on their
> merry way without crashing.
>
> I'd love to see this become feasible with LLVM as we found this a
> significant win in terms of reducing binary size.
Unless I'm misunderstanding, this is possible today and wouldn't be too 
hard to implement.

The trick is to preserve the control flow possibilities at the IR level 
so that there's a known exceptional resume point after the potentially 
faulting instruction.  Any potentially faulting operation could be 
represented as an invoke to a properly modelled intrinsic.

In SelectionDAGBuilder, you could emit the actual instructions rather 
than lowering the call part of the invoke normally.  (I think.  Haven't 
implemented that and this area is filled with corner cases...)

Philip