<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 06:12 PM, Reid Kleckner
wrote:<br>
</div>
<blockquote
cite="mid:CACs=tyL9i_MR=OxfKvo35O9P45Qd6JrbmNCwTmJ=4kJq=Ff8EQ@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 1:28 PM, 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: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>
</div>
</div>
</blockquote>
<br>
Yea, that would be better. Concerns have been expressed to me about
the additional compile-time cost of the resulting extra basic blocks
this would imply. It would be nice to actually perform the
experiment at some point -- I think it would make a lot of our
algorithms simpler if we didn't have this special case. { Not to get
off topic ;) }<br>
<br>
<blockquote
cite="mid:CACs=tyL9i_MR=OxfKvo35O9P45Qd6JrbmNCwTmJ=4kJq=Ff8EQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<br>
Yes, at least when compiling C/C++ code directly. The exception
being functions that are explicitly tagged with relevant attributes
(e.g. const, pure). I was under the impression that this was
motivated by uses of LLVM in JITs or in other languages which might
want to tag functions in a way which makes this distinction
generally interesting. The other motivation was conceptual clarity
:-)<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CACs=tyL9i_MR=OxfKvo35O9P45Qd6JrbmNCwTmJ=4kJq=Ff8EQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>