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

[Jeremy Lakeman]

On Mon, Apr 7, 2014 at 5:37 PM, Andrew Trick <atrick at apple.com> wrote:

>
> I agree with Filip that implementing null checks as trapping loads is
> essentially a minor code-size optimization that is typically not
> worthwhile. However, my point is that this decision should not be made at
> IR level.
>
> It could make sense to have a null check intrinsic that encapsulates
> and+cmp+br+invoke. I just don't like the idea of it subsuming the
> load/store. I think that will complicate both null check optimization and
> load/store optimization.
>
> Whether the null check can be profitably implemented as a trapping
> load/store is specific to the target platform. This decision should be
> independent of optimization in the presence of null checks and independent
> of optimization of the null checks themselves. It is purely a codegen issue.
>
> Imagine someone else porting your frontend to a new platform. They should
> not be required to implement trapping loads/stores to achieve a working
> system. And either way, they should benefit from the same platform
> independent optimization.
>

Integer type legalisation, vector math... There's plenty of existing
language features you don't have to implement, just run passes to simplify
the IR first.
I'm also thinking particularly of how ecmascripten and pnacl are
implemented.

If the IR changes (and I'm not taking a position on that issue), we just
need a pass to transform the IR for back ends that don't wish to implement
it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140409/3b7c30b7/attachment.html>