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

[Reid Kleckner via llvm-dev]

On Thu, Jan 5, 2017 at 10:39 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> I don't understand why that's desirable, and I think it would severely
> limit our ability to infer these attributes for functions that unwind.
> You'd need to prove things -- likely unknowable things -- about the
> exception handlers in place around every call site of a function in order
> to mark it readonly, readnone, etc. We'd have the same problem with the
> attribute parameters. I'm fairly certain we do need and want to separate
> these concerns. This way we can apply callsite specific reasoning to the
> potential effects of exception handlers separate from what the function
> itself might do.
>
I'm really just trying to push exception handlers outside the LLVM model.
They shouldn't be able to look at LLVM values, so that we *can* reason
locally to infer readnone/readonly.

In practice, when could we infer readnone without inferring nounwind? The
only thing in LLVM that can throw is a call or intrinsic call to EH
machinery, and that instruction will need to be attributed with knowledge
of the exception handler. If the exception handler really doesn't write
memory that LLVM can read, then we can mark it readonly, and our normal
local inference will work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170105/44c3baa5/attachment.html>