<div dir="ltr">On Mon, Apr 7, 2014 at 5:37 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
</div></div>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.<br>

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

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

<br>
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.<br>
</blockquote><div><br></div><div>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. <br>I'm also thinking particularly of how ecmascripten and pnacl are implemented.<br>
</div></div><br></div><div class="gmail_extra">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.<br></div></div>