[LLVMdev] RFC: implicit null checks in llvm

[Andrew Trick]

> On Apr 23, 2015, at 10:18 AM, Reid Kleckner <rnk at google.com> wrote:
> 
> The intrinsics need to be lowered to a pseudo instruction just like patchpoint (so that a stackmap can be emitted). In my mind the real issue here is how to teaching this pseudo instruction to emit the proper load/store for the target.
> 
> Does it really have to be a per-target pseudo? The way I see it, we can handle this all in selection dag. All we need to do is emit the before label, the load/store operation, and the end label, and establish control dependence between them all to prevent folding. Does that seem reasonable, or is this an overly simplistic perspective? :-)

It would be really nice to just emit a label next to an instruction and assume the stackmap entry will end up at the right address. I don’t think the backend can make that guarantee. Any Machine pass can insert instructions wherever it wants without looking for labels.

I think labels are only employed just before code emission. Is there any existing example of labels being used earlier (I think GCRootLowering is the earliest)?

> > Note that the signal handler / runtime do not themselves raise
> > exceptions at the ABI level (though they do so conceptually), but the
> > landing pad block can raise one if it wants to.
> >
> > The table mapping load/store PCs to unwind PCs can be reported to the
> > language runtime via an __llvm_stackmaps like section.  I am strongly
> > in favor of making this section as easy to parse as possible.
> 
> Let’s just be clear that it is not recommended for the frontend to produce these intrinsics. They are a compiler backend convenience. (I don’t want InstCombine or any other standard pass to start trafficking in these.)
> 
> Would you be OK with simply documenting that these intrinsics are optimization-hostile, in the same way that early safepoint insertion is? There are some language constructs (__try / __except) that allow catching memory faults like this. Such constructs are rare and don't really need to be optimized. I just want to make sure that mid-level optimizations don't actively break these.

Documentation is fine. There’s no reason to prevent a frontend from generating these. I just want the intention to be clear.

Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150423/80354699/attachment.html>