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

[Peter Collingbourne]

On Tue, Apr 01, 2014 at 12:16:37PM -0400, Rafael Espíndola wrote:
> >  - 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.

That sounds about right. I would also add for the last point that it is target
dependent whether geps of a null pointer constant trap.

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

Exactly.

Thanks,
-- 
Peter