Re: [PATCH][4.3] Deprecate -ftrapv

[Joern Rennecke <amylaar at spamcop dot net>]

On Fri, 29 Feb 2008, Robert Dewar wrote:
> > Well presumably one would want to use target dependent stuff for
> > detecting overflow where it exists (sticky overflow bits on
> > power, O flag on PC, trapping add on MIPS etc).

In fact, when I wrote the original -ftrapv code, it was for the sole purpose
of using the trapping add on mips.

On Sat, 1 Mar 2008, Joseph S. Myers wrote:
> The only targets defining the <operation>v<mode> insn patterns at present
> appear to be alpha and pa.

Considering the trouble that you get when you try to generate branches in
a non-branch expander, we should probably have alternate named patterns
to be used in ports to processors that have no conditional trap facility,
or where a conditional trap is more expensive than a well predictable
conditional branch.
We want arithmetic-and-branch-on-overflow patterns for these.
One peculiarity of these patterns would be that they would be required
to expand into more than one instruction, since the write of the result
must not be in the same instruction as the branch due to reload limitations.
Thus the overflow condition in CC0 / other flags register / predicate
register has to be actually exposed in rtl to show the dependency between
arithmetic and branch.
We should document this quirk in the description of these named patterns.

When the machine independent expander machinery wants to expand a
trapping arithmetic operation that has no matching named pattern defined
by the port, and there is no conditional trap defined, it can than use
the arithmetic-and-branch-on-overflow pattern to branch to an abort call
if an overflow occurs.

To allow branch inversion to work, we don't need to do anything special
if the condition is expressed as a comparison against 0 of a 'integer'
flag regsiter or a predicate bit.  However, if the condition is in CC0
or a CCmode flags register, we want a way to express the overflow
and non-overflow conditions so that reverse_condition or REVERSE_CONDITION
can do its work.

I see two possibilities here.  For simplicity I will describe them  
here in terms of CC0, although many target ports would actually use a
scheduler-exposed flags register with an appropriate CCmode mode.
- We could have (overflow CC0 0) and (nooverflow CC0 0), where
  overflow and nooverflow are two new comparison codes, and the trailing
  0 is a dummy argument for the sake of consistency with comparison
  operators.
- We could have (ge CC0 overflow) and (lt CC0 overflow), where overflow
  is a new one-of-a-kind RTX object.