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

[Hal Finkel via llvm-dev]

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>