<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 5, 2017, at 10:39 AM, Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" 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="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" 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><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></body></html>