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

[Sanjoy Das via llvm-dev]

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

> 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.

-- Sanjoy