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

[Hal Finkel via llvm-dev]

On 01/05/2017 03:10 PM, Reid Kleckner wrote:
> On Thu, Jan 5, 2017 at 10:39 AM, Hal Finkel <hfinkel at anl.gov 
> <mailto: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.

Maybe we're not on the same page. When I say exception handler, I mean 
any code the unwinding in-turn calls - i.e. anything in a catch block.

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

What do you mean? Any call, except for those tagged with nounwind, can 
throw. They don't need to be 'invoked'. I don't like this aspect of 
LLVM's IR, but that's another story.

  -Hal

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170105/6de1464a/attachment.html>