<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 5, 2017 at 10:39 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
    <p><span style="color:rgb(34,34,34)">I don't understand why that's desirable, and I think it would
    severely limit our ability to infer these attributes for functions
    that unwind. You'd need to prove things -- likely unknowable things
    -- about the exception handlers in place around every call site of a
    function in order to mark it readonly, readnone, etc. We'd have the
    same problem with the attribute parameters. I'm fairly certain we do
    need and want to separate these concerns. This way we can apply
    callsite specific reasoning to the potential effects of exception
    handlers separate from what the function itself might do.</span></p></div></div></div></blockquote><div>I'm really just trying to push exception handlers outside the LLVM model. They shouldn't be able to look at LLVM values, so that we *can* reason locally to infer readnone/readonly.<br><br>In practice, when could we infer readnone without inferring nounwind? The only thing in LLVM that can throw is a call or intrinsic call to EH machinery, and that instruction will need to be attributed with knowledge of the exception handler. If the exception handler really doesn't write memory that LLVM can read, then we can mark it readonly, and our normal local inference will work.</div></div></div></div>