llvm dev - Jan 2017 - RFC: Allow readnone and readonly functions to throw exceptions

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>

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>

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

On 01/05/2017 06:12 PM, Reid Kleckner wrote:
> On Thu, Jan 5, 2017 at 1:28 PM, Hal Finkel <hfinkel at anl.gov 
> <mailto: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.
Yea, that would be better. Concerns have been expressed to me about the 
additional compile-time cost of the resulting extra basic blocks this 
would imply. It would be nice to actually perform the experiment at some 
point -- I think it would make a lot of our algorithms simpler if we 
didn't have this special case. { Not to get off topic ;) }
>
> ---
>
> 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.
Yes, at least when compiling C/C++ code directly. The exception being 
functions that are explicitly tagged with relevant attributes (e.g. 
const, pure). I was under the impression that this was motivated by uses 
of LLVM in JITs or in other languages which might want to tag functions 
in a way which makes this distinction generally interesting. The other 
motivation was conceptual clarity :-)

  -Hal
>
> 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.
-- 
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/088b6b2e/attachment.html>