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

[Rafael Espíndola]

>  - 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.

We should probably say this at an IR level. For example,

* A painter to the the stack is assumed non trapping.
* A pointer returned by malloc (calloc, strdup, etc) is assumed non trapping.
* All geps of such pointers are assumed non trapping.
* null is required to trap.
* it is target dependent if a ptrtoint of a non zero constant traps or not.

> 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.

It basically assumes that runtime environment of a language using
iload and istore has a signal handler that converts the segmentation
fault to a null pointer exception that is propagated using the c++
abi?

Sounds reasonable overall.

Cheers,
Rafael