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

[Krzysztof Parzyszek]

How do you plan to actually create the exception? You cannot simply 
throw an exception (via "throw" statement) from a signal handler because 
the unwinding won't happen properly.  To make it work you'll need a 
runtime support to indicate the origin of the exception (i.e. the 
address of the offending load/store). Alternatively, you could insert 
runtime checks at the loads/stores, but then it won't be "zero-cost".

-Krzysztof


On 3/31/2014 8:58 PM, Peter Collingbourne wrote:
> Hi,
>
> I wanted to propose an IR extension that would allow us to support zero-cost
> exception handling for non-call operations that may trap. I wanted to start
> with loads and stores through a null pointer, and later we might extend this to
> div/rem/mod zero. This feature is obviously useful for implementing languages
> such as Java and Go which deterministically translate such operations into
> exceptions which may be caught by the user.
>
> There are a couple of somewhat orthogonal features that this would entail:
>
>   1) Deterministic handling for loads and stores through a null pointer.
>   2) Ability to unwind a load/store to a specific basic block, like invoke.
>
> At the moment, we do not exactly have 1), as the optimizer considers
> non-volatile loads/stores through a null pointer to have undefined
> behavior. Volatile loads/stores are closer, but they come with their own
> set of baggage that can inhibit optimization. (For example, if we can prove
> that a load would always succeed, 'volatile' prevents us from reordering
> the load or deleting it if it is dead.) So I propose to add an attribute to
> 'load' and 'store', which we can call, say, 'nullcheck', with the following
> additional semantics:
>
>   - If the memory address is between zero and a target-defined value (i.e. the
>     size of the zero page) the instruction is guaranteed to trap in a
>     target-defined manner.
>
>   - The optimizer may only delete or reorder nullcheck instructions if the
>     program cannot observe such a transformation by installing a signal handler
>     for the trap.  Therefore, the optimizer would be able to drop the attribute
>     if it can prove that the address will always be non-null.
>
> To support 2), I propose a couple of new instructions. I haven't come up with
> great names for these instructions, but:
>
>   - 'iload' is to 'load' as 'invoke' is to 'call'. That is, the instruction is
>     a terminator and has normal and unwind destinations. e.g.
>
>     %v = iload i8* %ptr to label %try.cont unwind label %lpad
>
>   - Similarly, 'istore' is to 'store' as 'invoke' is to 'call'.
>
>     istore i8 %v, i8* %ptr to label %try.cont unwind label %lpad
>
> These instructions always have 'nullcheck' semantics, plus:
>
>   - If the instruction traps and the program has installed a signal handler
>     for the trap which unwinds, the unwind is guaranteed to land at the
>     landing pad.
>
> I've been working on an implementation of 'iload' and 'istore' which are
> in the attached patches, if you are interested. (They aren't ready to go
> in yet.) I have asm parsing/printing for both, and code generation for
> 'iload'. Would be interested in getting feedback on code generation as this
> is my first serious foray into the backend -- I haven't tried running the
> generated code yet and the DAG builder is a mashup of the DAG builders for
> 'invoke' and 'load', but I've eyeballed the asm it generates (e.g. llc produces
> iload-exception.s for the attached iload-exception.ll) and it looks reasonable.
>
> Thanks,
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation