<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 5, 2017 at 1:28 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-">
    <p>Maybe we're not on the same page. When I say exception handler, I
    mean any code the unwinding in-turn calls - i.e. anything in a catch
    block.</p></span></div></blockquote><div>OK, I was thinking of the runtime machinery that actually initiates unwinding or the personality function. It's not reasonable for LLVM to worry that calling a readnone function could trigger a signal handler or something that inspects stack memory, modifies it, and then initiates stack unwinding.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-"><blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>
              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></blockquote></span>
    What do you mean? Any call, except for those tagged with nounwind,
    can throw. They don't need to be 'invoked'. I don't like this aspect
    of LLVM's IR, but that's another story.</div></blockquote><div><br></div><div>I think we're in agreement here, that's what I was trying to say earlier. DSE now needs to "know" about these extra unrepresented edges from calls, but it doesn't mean that readnone+mayunwind functions are considered to read or write memory. That's what I object to.</div><div><br></div><div>I'm told that both GCC and ICC are not like LLVM. They explicitly model calls as having an extra edge to some function point, unless they are proven to not unwind.</div><div><br></div><div>---</div><div><br></div><div>To further explain what I was trying to say in my last message, it seems to me like the discussion of readnone+mayunwind functions is completely academic unless you have a way to throw an exception that isn't a call to an external function. This is why I've never taken it very seriously, and have always felt that readnone/readonly should imply nounwind for simplicity. At some point, if the only way to throw an exception is to call a function, you gotta call __cxa_throw or it's moral equivalent from another runtime, and that means functionattrs will not be able to infer readonly/readnone for any potentially throwing function.</div><div><br></div><div>So, the logical next step from the proposal to separate readnone/readonly/nounwind is to add intrinsics like guards that may throw an exception but do not write memory. They would be marked as readnone/readonly+mayunwind.</div></div></div></div>