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

[Sanjoy Das via llvm-dev]

Hi Reid,

On Thu, Jan 5, 2017 at 4:12 PM, Reid Kleckner <rnk at google.com> wrote:
> 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.

Agreed.

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

Yes, once we have a proper implementation of
(readnone|readonly)+may-unwind, guards may be tagged as
readonly+may-unwind.

NB: Guard do not necessarily throw exceptions; but the effect of what
they do (bail out to the interpreter) "looks like" an exception throw
to the optimizer.

-- Sanjoy