[PATCH take 3] Experimental -fpreserve-traps option

Roger Sayle roger@nextmovesoftware.com
Sun Aug 29 09:27:58 GMT 2021

This is another attempt to add an -fpreserve-traps command line
option to GCC.  Many thanks to Richard Beiner for approving the
code clean-up pieces of my earlier submission: This revision
contains just the actual functional change(s).

My recent attempt at humour in comment #8 of PR 77980 has
reminded me that we still really need to tackle/improve the
semantics of trapping instructions.

Firstly, I completely agree with Richard (and Eric) that the
current situation with the semantics of -fexceptions and
-fnon-call-exceptions (especially the latter without the
former) is a mess.  Alas, the testsuite (and source) is full
of checks that the current status quo is preserved, so any
attempts to tweak exception handling leads to a world of pain.

The most relevant thing that I would like to point out is that
this proposed option, -fpreserve-traps, and the semantics of
trapping instructions are completely orthogonal to exception
handling.  As the term EH implies, exceptions are a form of flow
control (on those targets that support it).  Traps, signals(?),
segmentation faults, illegal accesses and invalid instructions
are things that can't (always?) be controlled.  Exceptional yes,
but not handleable.

I also agree with Richard's sentiment that GCC should aim to
store semantics in the representation, not in global variables.
Interestingly, whether a tree or rtx can trap has been explicitly
represented in every allocated node for decades; it's what the
compiler should do (or is allowed to do) with that information
that has been missing.

My proposal is to treat -fpreserve-traps as an experiment for
the time being.  Allowing all the places in the compiler that
make assumptions about traps to be found/documented (by searching
for flag_perserve_traps in the source code), and their influence
on performance benchmarked.  If things don't work out, there's
the option to revert these patches, or #define flag_perserve_traps 0
with no run-time overhead.  If this option proves useful, we can
figure out how to serialize it in LTO, whether it's controlled
by some language front-ends (e.g. Ada) or target backends, etc.

I think it was Wittgenstein that explained that you need to have
a name for a concept to reason or argue about it.  -fpreserve-traps
is a concept that GCC has never had, which is why it has been
conflated with exceptions and exception handling over the years.
In C++, division by zero is undefined behaviour; having a flag
brings us one step closer to implementation defined.

This patch has been tested on x86_64-pc-linux-gnu with a "make
bootstrap" and "make -k check" with no new failures.

Ok for mainline?

2021-08-29  Roger Sayle  <roger@nextmovesoftware.com>
            Eric Botcazou  <ebotcazou@adacore.com>
            Richard Biener  <rguenther@suse.de>

        PR tree-optimization/38943
        * common.opt (fpreserve-traps): New code generation option.
        * doc/invoke.texi (-fpreserve-traps): Document new option.
        * gimple.c (gimple_has_side_effects): Consider trapping to
        be a side-effect when -fpreserve-traps is specified.
        * ipa-pure-const.c (check_stmt): When preserving traps,
        a trapping statement should be considered a side-effect,
        so the function is neither const nor pure.

        PR tree-optimization/38943
        * gcc.dg/pr38943.c: New test case.


-----Original Message-----
From: Richard Biener <richard.guenther@gmail.com> 
Sent: 12 July 2021 12:26
To: Roger Sayle <roger@nextmovesoftware.com>
Cc: Eric Botcazou <botcazou@adacore.com>; GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH take 2] PR tree-optimization/38943: Preserve trapping instructions with -fpreserve-traps


I've reviewed the cited PRs and most of them would have individual fixes and are not fixed by your patch, though -fpreserve-traps would offer a workaround in some cases.

Now, -fpreserve-traps follows the unfortunate precedence of tieing IL semantics to a (global) flag rather than to individual stmts.  I'm not sure -fpreserve-traps is something good to offer since on its own it looks not too useful and for making use of it one still needs -fnon-call-exceptions [-fexceptions].

There's still the open question what -fnon-call-exceptions on its own should do - IMHO it doesn't make sense to allow unwiding from a trapping memory reference but not from the call it resides in which means -fnon-call-exceptions should better enable -fexceptions?

There's also valid points made in some of the PRs (some of which look like dups of each other) that an asm with memory operands should be trapping and thus throwing with -fnon-call-exceptions even when it is not volatile and that some builtin functions like memcpy should not be nothrow with -fnon-call-exceptions.

There's const-correctness pieces in your patch - those are OK under the obvious rule and you might want to push them separately.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patche.log
Type: application/octet-stream
Size: 3375 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210829/83b28262/attachment-0001.obj>

More information about the Gcc-patches mailing list