<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 01/05/2017 03:10 PM, Reid Kleckner
      wrote:<br>
    </div>
    <blockquote
cite="mid:CACs=tyLM6C06r58W_z-7hnH+JVwMmcGV-Do2WCRN_yGAHP1YAg@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <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 moz-do-not-send="true"
                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>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote
cite="mid:CACs=tyLM6C06r58W_z-7hnH+JVwMmcGV-Do2WCRN_yGAHP1YAg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><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>
    </blockquote>
    <br>
    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.<br>
    <br>
     -Hal<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </body>
</html>