[llvm-dev] RFC: Allow readnone and readonly functions to throw exceptions

[Michael Kuperstein via llvm-dev]

On Tue, Jan 3, 2017 at 9:59 AM, Sanjoy Das via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Michael,
>
> On Mon, Jan 2, 2017 at 11:49 PM, Michael Kuperstein
> <michael.kuperstein at gmail.com> wrote:
> > This sounds right to me.
> >
> > IIUC, historically, readonly and readnone are meant to model the "pure"
> and
> > "const" GCC attributes. These attributes make pretty strong guarantees:
> >
> > "[a pure] function can be subject to common subexpression elimination and
> > loop optimization just as an arithmetic operator would be. These
> functions
> > should be declared with the attribute pure [...] Interesting non-pure
> > functions are functions with infinite loops or those depending on
> volatile
> > memory or other system resource, that may change between two consecutive
> > calls (such as feof in a multithreading environment)."
> >
> > In particular, pure/const imply termination - something that's not
> entirely
> > clear w.r.t readonly. However, apparently, they don't imply nothrow. I've
> > actually always thought they *do* imply it - and said so on-list :-) -
> but
> > it looks like GCC itself doesn't interpret them that way. E.g. see John
> > Regher's example here: https://t.co/REzy5m1tT3
> > So there's at least one use-case for possibly throwing readonly/readnone.
>
> One important thing to note then: clang marks const and pure functions
> as nounwind *explicitly*.  That needs to be fixed.
>
> https://godbolt.org/g/SMF4C9
>
>
Hah. So it does.
Eric, this was originally your change. Do I understand GCC's behavior
incorrectly?


> > As a side note, I'm slightly less optimistic about the amount of required
> > code fixes. One thing that comes to mind is that we need to make sure we
> > mark all(?) the intrinsics currently marked readonly/argmemonly/readnone
> as
> > nothrow. This should be mostly mechanical, I hope, but it's a decent
> amount
> > of churn.
>
> The behavior around intrinsics today is that they're implicitly marked
> NoUnwind unless they're specifically annotated as [Throws], of which
> there are very few instances (statepoints, stackmap, patchpoint,
> coro_*).  My intent was to (document and) keep this behavior.
>
>
Oh, ok, this makes a lot of sense.


> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170103/ff717a93/attachment.html>