<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 3, 2017 at 9:59 AM, Sanjoy Das via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Michael,<br>
<span class=""><br>
On Mon, Jan 2, 2017 at 11:49 PM, Michael Kuperstein<br>
<<a href="mailto:michael.kuperstein@gmail.com">michael.kuperstein@gmail.com</a>> wrote:<br>
> This sounds right to me.<br>
><br>
> IIUC, historically, readonly and readnone are meant to model the "pure" and<br>
> "const" GCC attributes. These attributes make pretty strong guarantees:<br>
><br>
> "[a pure] function can be subject to common subexpression elimination and<br>
> loop optimization just as an arithmetic operator would be. These functions<br>
> should be declared with the attribute pure [...] Interesting non-pure<br>
> functions are functions with infinite loops or those depending on volatile<br>
> memory or other system resource, that may change between two consecutive<br>
> calls (such as feof in a multithreading environment)."<br>
><br>
> In particular, pure/const imply termination - something that's not entirely<br>
> clear w.r.t readonly. However, apparently, they don't imply nothrow. I've<br>
> actually always thought they *do* imply it - and said so on-list :-) - but<br>
> it looks like GCC itself doesn't interpret them that way. E.g. see John<br>
> Regher's example here: <a href="https://t.co/REzy5m1tT3" rel="noreferrer" target="_blank">https://t.co/REzy5m1tT3</a><br>
> So there's at least one use-case for possibly throwing readonly/readnone.<br>
<br>
</span>One important thing to note then: clang marks const and pure functions<br>
as nounwind *explicitly*.  That needs to be fixed.<br>
<br>
<a href="https://godbolt.org/g/SMF4C9" rel="noreferrer" target="_blank">https://godbolt.org/g/SMF4C9</a><br>
<span class=""><br></span></blockquote><div><br></div><div>Hah. So it does.</div><div>Eric, this was originally your change. Do I understand GCC's behavior incorrectly?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> As a side note, I'm slightly less optimistic about the amount of required<br>
> code fixes. One thing that comes to mind is that we need to make sure we<br>
> mark all(?) the intrinsics currently marked readonly/argmemonly/readnone as<br>
> nothrow. This should be mostly mechanical, I hope, but it's a decent amount<br>
> of churn.<br>
<br>
</span>The behavior around intrinsics today is that they're implicitly marked<br>
NoUnwind unless they're specifically annotated as [Throws], of which<br>
there are very few instances (statepoints, stackmap, patchpoint,<br>
coro_*).  My intent was to (document and) keep this behavior.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Oh, ok, this makes a lot of sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
-- Sanjoy<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>