[llvm-dev] RFC: Allow readnone and readonly functions to throw exceptions
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 5 13:28:49 PST 2017
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.
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev