<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 31, 2016 at 5:54 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</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">Hi Daniel,<br>
<br>
On Sat, Dec 31, 2016 at 4:44 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:<br>
[snip]<br>
<span class="gmail-">> 2. I have no problem with us with deciding what we mean in either direction.<br>
> I just believe it's worth having a real mailing list discussion about it not<br>
> buried in this particular thread, before making such a patch.<br>
<br>
</span>(For brevity, when I say readnone, I mean readnone / readonly)<br>
<br>
I think LLVM today already has a strong bent towards "readnone<br>
functions *can* unwind".<br></blockquote><div><br></div><div>How does one unwind without writing memory?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
a. We don't CSE the call to @f() in<br>
<br>
  declare void @f() readnone<br>
<br>
  define void @g() {<br>
    call void @f()<br>
    ret void<br>
  }<br>
<br>
unless @f is also marked nounwind.<br></blockquote><div>One can argue these are missed opts :) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
b. We infer readnone for a function that has resume in it (example<br>
   earlier in the thread).<br>
<br>
<br>
And, finally, we don't actually get any new expressive power out of<br>
the assumption.  If the frontend knows that readnone functions are<br>
nounwind by the language spec then it can mark declarations that it<br>
was going to mark as readnone as "readnone nounwind" (for instance,<br>
clang marks pure and const functions as nounwind also).  And I can't<br>
think of a case where function attrs would be able to deduce readnone<br>
and not nounwind for a legitimately nounwind function.<br>
<br>
I'll start a thread on llvm-dev (not today, but tomorrow or Monday) to<br>
set the wheels in motion.</blockquote><div><br></div><div>Sounds good to me. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  I can revert the patch in the meantime if<br>
that'll make you more comfortable.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Nope. I just want us to end up in a consistent end state.</div><div>I don't see how you have a readnone function unwind, but i also have no real dog in this fight.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-HOEnZb"><font color="#888888">
-- Sanjoy<br>
</font></span></blockquote></div><br></div></div>