
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 24, 2015, at 8:26 AM, Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 23, 2015 at 5:17 PM, Andrew Trick <span dir="ltr" class=""><<a href="mailto:atrick@apple.com" target="_blank" class="">atrick@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="h5"><span style="color:rgb(34,34,34)" class="">The scheduler itself doesn’t move anything around labels. But any pass can perform code motion or load/store optimization. Also, any pass can insert an instruction, like a copy, between the label and the load.</span><br class=""></div></div><div class=""><br class=""></div><div class="">I’m not really sure how EH_LABEL ends up translating into exception tables, but my guess is that it’s encoding a range that may include any arbitrary instructions as long as the call is within the range. So as long as calls aren’t reordered with labels and appears to have side effects it would work.</div><div class=""><br class=""></div><div class="">So, you could add a different kind of stack map entry that encodes ranges instead of exact addresses, then survey all passes to ensure they don’t optimize loads across labels. I would have more confidence doing this with a pseudo instruction though.</div></div></blockquote><div class=""><br class=""></div><div class="">I guess your concern is that you need an exact address to do patching.</div><div class=""><br class=""></div><div class="">If this feature is limited to simply allow handling exceptions raised from loads and stores, then I'm not worried about copies, adds, or other code being moved into the label range. We don't support catching traps from those kinds of instructions. I'm only worried about memory accesses being moved into the range. If we can address that, I think the EH_LABEL approach works, and it generalizes to other trapping instructions like division or FP exceptions.</div></div></div></div>

</div></blockquote></div><br class=""><div class="">I think this is riskier than EH_LABELing calls because targets do aggressive load/store optimization. It does sound plausible though. I imagine teaching those passes to treat labels equivalent to unknown stores.</div><div class=""><br class=""></div><div class="">We don’t need to support patching at the load. Patch points will be needed to “heal” bad implicit null checks, but that is probably better done by patching call sites into the optimized code. Eventually, someone may want to be able to patch their implicit null checks, and they’ll just need to use a patchpoint to do that instead.</div><div class=""><br class=""></div><div class="">Obviously, if this approach works, it’s better to define a separate llvm.load_with_trap intrinsic.</div><div class=""><br class=""></div><div class="">FWIW: Now that I think about it, the EH_LABEL approach makes sense and is more elegant (although it’s risky), but implementing the pseudo instruction would also be fairly straightforward. You would just mimic the patchpoint logic for lowering and MC streaming.</div><div class=""><br class=""></div><div class="">Andy</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>