<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 31, 2016 at 4:12 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>
<span class="gmail-"><br>
On Sat, Dec 31, 2016 at 3:47 PM, Daniel Berlin via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> What about readnone?<br>
> The last time i asked, i got the answer that readnone implied nounwind.<br>
><br>
> Also, the langref currently says<br>
><br>
> readnone:<br>
><br>
> ...<br>
> It does not write through any pointer arguments (including byval arguments)<br>
> and never changes any state visible to callers. This means that it cannot<br>
> unwind exceptions by calling the C++ exception throwing methods.<br>
><br>
> readonly:<br>
> ...<br>
> A readonly function always returns the same value (or unwinds an exception<br>
> identically) when called with the same set of arguments and global state. It<br>
> cannot unwind an exception by calling the C++ exception throwing methods...<br>
><br>
><br>
> I'm not an expert in this area by any means, but if i was to read this, i<br>
> would think it implied nounwind[1].<br>
<br>
</span>The hair I'd split here is that the langref specifically talks about<br>
"C++ exception throwing methods" (i.e. __cxa_throw etc.), but it does<br>
not disallow other non-memory-writing non-C++ unwind mechanisms.  For<br>
instance, @f is inferred to be readnone by LLVM currently, despite the<br>
fact that it throws.<br>
<br>
define void @f() personality i8 42 {<br>
entry:<br>
  resume i32 0<br>
<span class="gmail-">}<br>
<br></span></blockquote><div><br>1. Note that this seems to disagree with what phillip said on this thread:<br>"</div><span style="font-size:12.8px">We have a prevaling assumption that to throw an exception, you must write to some global (but unknown) location to do so.  We effectively assume that any readonly call is also nounwind."</span></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>2. I have no problem with us with deciding what we mean in either direction.</div><div>I just believe it's worth having a real mailing list discussion about it not buried in this particular thread, before making such a patch.</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"><span class="gmail-">
> So if that's not what we mean, we should change it :)<br>
><br>
> Thus, IMHO this patch deserves a bit of discussion, with the  answer to<br>
> whether they are nounwind being explicitly written down in the langref in a<br>
> way dumb people like me can understand it. :)<br>
<br>
</span>I think the patch (rL2907940) is a good idea even if we decide that<br>
readnone / readonly do imply nounwind -- that sort of policy should live<br>
either in Instruction::doesNotThrow or we should have function attrs<br>
or something like that mark readnone / readonly functions as nounwind,<br>
instead of having it scattered all over LLVM.<br></blockquote><div><br></div><div>Sure, but we shouldn't lose optimization to do it.</div><div>If the answer is "these things are nounwind", i would have expected such a refactoring to do what you suggest, not just "turn it off"  :)<br></div><div><br></div><div>If the answer is "these things are not nounwind", i would have expected such a change to update the langref so it doesn't split hairs and have, IMHO, inconsistent wording. :)</div><div><br></div><div><br></div></div></div></div>