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

[Reid Kleckner via llvm-dev]

On Thu, Jan 5, 2017 at 1:28 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> 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.
>
OK, I was thinking of the runtime machinery that actually initiates
unwinding or the personality function. It's not reasonable for LLVM to
worry that calling a readnone function could trigger a signal handler or
something that inspects stack memory, modifies it, and then initiates stack
unwinding.

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

I think we're in agreement here, that's what I was trying to say earlier.
DSE now needs to "know" about these extra unrepresented edges from calls,
but it doesn't mean that readnone+mayunwind functions are considered to
read or write memory. That's what I object to.

I'm told that both GCC and ICC are not like LLVM. They explicitly model
calls as having an extra edge to some function point, unless they are
proven to not unwind.

---

To further explain what I was trying to say in my last message, it seems to
me like the discussion of readnone+mayunwind functions is completely
academic unless you have a way to throw an exception that isn't a call to
an external function. This is why I've never taken it very seriously, and
have always felt that readnone/readonly should imply nounwind for
simplicity. At some point, if the only way to throw an exception is to call
a function, you gotta call __cxa_throw or it's moral equivalent from
another runtime, and that means functionattrs will not be able to infer
readonly/readnone for any potentially throwing function.

So, the logical next step from the proposal to separate
readnone/readonly/nounwind is to add intrinsics like guards that may throw
an exception but do not write memory. They would be marked as
readnone/readonly+mayunwind.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170105/6801713e/attachment.html>