This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][4.3] Deprecate -ftrapv

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
- We could have (ge CC0 overflow) and (lt CC0 overflow), where overflow
is a new one-of-a-kind RTX object.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]