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

[Daniel Berlin via llvm-dev]

On Wed, Jan 4, 2017 at 8:35 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> I just realized that there's an annoying corner case to this scheme --
> I can't DSE stores across readnone maythrow function calls because the
> exception handler could read memory. That is, in:
>
> try {
>   *a = 10;
>   call void @readnone_mayunwind_fn();
>   *a = 20;
> } catch (...) {
>   assert(*a == 10);
> }
>
> I can't DSE the `*a = 10` store.
>
> As far as I can tell, the most restrictive memory attribute for a
> potentially throwing function is readonly.  "readnone may-unwind" does
> not make sense.  "readonly may-unwind" is fine because even if the EH
> handler writes to memory, the code in the normal execution path does
> not have worry about the memory clobbers.
>
> I thought I had this figured out, but now it looks like I gotta think
> more. :)
>
> @Danny: I agree with your assessment of the example; unless the
> compiler knows that `cos` won't throw (which it may very well know
> since it is the standard library function, but I don't know GCC
> internals), the transform is wrong.
>
> It does not know that, actually.
I would say that GCC pretty much is a grab bag, since i wrote that for the
gcc regression testsuite, and it's still tested  :)

There are like 3 optimization testcases that use nothrow, and john's
example happens to just fall into this case:

   if (stmt_ends_bb_p (stmt)
       || gimple_has_volatile_ops (stmt)
       || gimple_has_side_effects (stmt)
       || stmt_could_throw_p (stmt))
     return MOVE_IMPOSSIBLE;


Some of the passes check throwing, some of them don't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170104/84c06c28/attachment.html>