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

[David Majnemer via llvm-dev]

On Thu, Jan 5, 2017 at 1:10 PM, Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

So the WinEH C++ exception handler actually *does* write to LLVM values: it
calls copy constructors and destructors for catch objects. However, we do
not model it as such in LLVM. We _attribute_ the memory modification for
the copy-constructor to the CatchPad and the memory modification for the
destructor to the CatchRet.

I think it is reasonable that all memory operations performed by a
personality routine "loudly" describe their ability to load/store to memory
using some instruction instead of implicitly by virtue of the function body
having been marked with a personality.


>
> 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.
>
> _______________________________________________
> 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/20170105/88f6e253/attachment.html>