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 Sat, 8 Feb 2003, Richard Henderson wrote:
> > On Fri, Feb 07, 2003 at 07:07:07PM -0700, Roger Sayle wrote:
> > > Is your use of the word "legal" based upon C/C++ standards?
> >
> > Yes.  And GCC as a C compiler still pervades the optimizers.
> > Something that ought to be fixed, but isn't.
> 
> So you're happy with the patch in principle, and are just worried
> there could be a bad interaction with other "legacy" transformations,
> not discovered by bootstraping or the regression suite?
> 
> 
> You're the last person anyone would need to remind that "GCC" stands
> for the "GNU Compiler Collection" and shouldn't be confused with "gcc"
> which is the C compiler :>         (I hate myself for writing that!)
> 
> 
> I suspect that GCC's history of treating overflows as undefined, except
> at the RTL-level where the usual semantics apply, would mean that we're
> very unlikely to perform a transformation that assumed any other
> interpretation.  Its far more likely that we'd not apply a transformation
> than assume MAX_INT + 1 != MIN_INT.

At tree level we definitly need to preserve the fact that certain types
do not overflow and do not introduce overflows when they are not
supposed to happen.  This is important for loop optimization and other
friedns.  At the present rule say that signet types do not overflow and
we should obey that.  Later I guess we should move to flag in tree
construct explicitly stating so (it would be cool to have the same for
RTL, but it is dificult)

Honza
> 
> Certainly throughout the compiler (including fold), we know MAX_INT
> must be represented as two's complement, i.e. 0x7fffffff, that MIN_INT
> must be 0x80000000, and we know that addsi3 must turn the first bit
> pattern into the second on all supported targets.
> 
> 
> [I realize that I'm breaking the first unspoken rule of gcc-patches,
> "Never ever, ever argue with the reviewer, the chances of improving a
> patch's chance of approval are so low as to be a waste of bandwidth"]
> 
> Roger
> --


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