This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Constant fold -A - B as -B - A (take 2)
- From: Roger Sayle <roger at www dot eyesopen dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 7 Feb 2003 16:15:29 -0700 (MST)
- Subject: Re: [PATCH] Constant fold -A - B as -B - A (take 2)
On Fri, 7 Feb 2003, Richard Henderson wrote:
> On Sat, Feb 01, 2003 at 01:19:54PM -0700, Roger Sayle wrote:
> > The only change to the original is the addition of the constraint
> > "FLOAT_TYPE_P (type) || ! TYPE_TRAP_SIGNED (type)" ...
>
> It's not a matter of whether or not the type traps, it's
> what we intuit about the definedness of overflow. I.e.
> that it can't happen.
>
> I'll allow this with FLOAT_TYPE_P, but not integral modes.
But the transformation is safe under the "usual" twos-complement
semantics of overflow. GCC's RTL optimization passes turn
"-A - CST" into "-CST - A" for integer types and constants, and
Microsoft's compilers (for one), turn "-A - (C - D)" into
"(D - C) - A".
Perhaps I'm missing something. Why exactly don't we like this
transformation for integral types? I'd understood that the
earlier concerns were that -ftrapv would report a different
number of overflow traps (much like SNaNs issues with other
transformations).
Can't we assume that MAX_INT+1 == MIN_INT on some targets?
Roger
--