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 <ro...@nextmovesoftware.com>
Eric Botcazou <ebotca...@adacore.com>
Richard Biener <rguent...@suse.de>
gcc/ChangeLog
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.
gcc/testsuite/ChangeLog
PR tree-optimization/38943
* gcc.dg/pr38943.c: New test case.
Roger
--
Roger
-----Original Message-----
From: Richard Biener <richard.guent...@gmail.com>
Sent: 12 July 2021 12:26
To: Roger Sayle <ro...@nextmovesoftware.com>
Cc: Eric Botcazou <botca...@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.
Thanks,
Richard.
patche.log
Description: Binary data
