This is the mail archive of the gcc-patches@gcc.gnu.org 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] 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
--


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