<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 12:45 PM, Mehdi Amini
wrote:<br>
</div>
<blockquote
cite="mid:38F5C8CB-039E-4872-A154-3C4C2A677E98@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jan 5, 2017, at 10:39 AM, Hal Finkel via
llvm-dev <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<p class=""><br class="">
</p>
<div class="moz-cite-prefix">On 01/05/2017 12:17 PM, Reid
Kleckner wrote:<br class="">
</div>
<blockquote
cite="mid:CACs=tyJuVTY1fA07x_bXN0Ku09YBPmsnRjv06cY=W3ffmsHKVg@mail.gmail.com"
type="cite" class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Jan 5, 2017 at 9:19
AM, Hal Finkel via llvm-dev <span dir="ltr"
class=""><<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" class="">llvm-dev@lists.llvm.org</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5"><br class="">
On 01/05/2017 10:55 AM, Sanjoy Das wrote:<br
class="">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> Hi Hal,<br
class="">
<br class="">
On Thu, Jan 5, 2017 at 6:12 AM, Hal Finkel
<<a moz-do-not-send="true"
href="mailto:hfinkel@anl.gov"
target="_blank" class="">hfinkel@anl.gov</a>>
wrote:<br class="">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> On
01/04/2017 10:35 PM, Sanjoy Das via
llvm-dev wrote:<br class="">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> I just
realized that there's an annoying
corner case to this scheme --<br
class="">
I can't DSE stores across readnone
maythrow function calls because the<br
class="">
exception handler could read memory.
That is, in:<br class="">
<br class="">
try {<br class="">
*a = 10;<br class="">
call void
@readnone_mayunwind_fn();<br class="">
*a = 20;<br class="">
} catch (...) {<br class="">
assert(*a == 10);<br class="">
}<br class="">
<br class="">
I can't DSE the `*a = 10` store.<br
class="">
<br class="">
As far as I can tell, the most
restrictive memory attribute for a<br
class="">
potentially throwing function is
readonly. "readnone may-unwind" does<br
class="">
not make sense.<br class="">
</blockquote>
<br class="">
Why not? I've not followed this thread
in detail, but it seems like you're<br
class="">
discussing allowing the modeling of EH
schemes that don't access accessible<br
class="">
memory. In that case, a may-unwind
readnone function is just one that makes<br
class="">
its decision about if/what to throw
based only on its arguments.<br class="">
</blockquote>
If the call to @readnone_mayunwind_fn
throws and I've DSE'ed the "*a =<br
class="">
10" store, the exception handler will fail
the *a == 10 assert (assume<br class="">
*a is not 10 to begin with). The function
call itself is readnone,<br class="">
but its exceptional continuation may read
any part of the heap.<br class="">
<br class="">
This isn't a big deal, but it means that
"readnone may-unwind" will<br class="">
effectively have to be treated as
"readonly may-unwind" -- I don't see<br
class="">
any optimization that would be applicable
to one and not the other.<br class="">
Maybe we should just move ahead with that
(that readnone may-unwind is<br class="">
allowed, but if you want readnone-like
optimizations then you need to<br class="">
also mark it as nounwind)?<br class="">
</blockquote>
<br class="">
</div>
</div>
Yes, I think that makes sense. The attribute
only applies to the function anyway, so what
exception handlers might do (which is assumed to
be reading/writing any memory that might be
available to them) must be reasoned about
separately.<br class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">I don't think we need or want to do
that. The way I see it, readonly implies that
the exception handler cannot write memory
readable by LLVM. Similarly, readnone should
imply that the exception handler does not read
memory written by LLVM. Basically, any function
that may unwind but also has these attributes
asserts that the exception handler is operating
outside of memory modeled by LLVM.</div>
</div>
</div>
</div>
</blockquote>
<br class="">
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.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>What useful things would you be able to deduce from an
“unwind readnone” function under these conditions?</div>
</div>
</blockquote>
<br>
It is still only a function of its arguments, so it can be CSE'd.<br>
<br>
Also, if I have this:<br>
<br>
*a = 10;<br>
b = a_readnone_unwind_func();<br>
*a = 10;<br>
<br>
I can still conclude that this last store is redundant and can be
removed. I know that the readnone function does not touch it, and if
it unwinds, than the later store is dead. If I know that &*a has
not escaped to where an exception handler might access it, then I
know that the first store than be removed.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:38F5C8CB-039E-4872-A154-3C4C2A677E98@apple.com"
type="cite">
<div>
<div><br class="">
</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<blockquote
cite="mid:CACs=tyJuVTY1fA07x_bXN0Ku09YBPmsnRjv06cY=W3ffmsHKVg@mail.gmail.com"
type="cite" class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">I don't think we'll do DSE in your
example because the store isn't dead, it's
visible along the invoke's unwind edge, and we
don't need to change the semantics of readnone
to see that.</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
<div class="">I’ve been wondering the same thing on Sanjoy’s
example.</div>
<div class=""><br class="">
</div>
<div class="">— </div>
<div class="">Mehdi</div>
<div class=""><br class="">
</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>