RFA: Fix for compile/20010903-1.c regressions

Joern Rennecke joern.rennecke@superh.com
Tue Aug 20 08:55:00 GMT 2002


Richard Henderson wrote:
> 
> On Tue, Jul 23, 2002 at 05:03:15PM +0100, Joern Rennecke wrote:
> > After updating my sources today, I've seen compile/20010903-1.c
> > regressions for all four SH64 -m5-compat subtargets at optimization levels
> > -O3 -fomit-frame-pointer -funroll-loops and -O3 -fomit-frame-pointer
> > -funroll-all-loops -finline-functions.
> 
> Yes, this happens on x86 as well.
> 
> > It seems the recent unroll changes have exposed a bug in the unsharing
> > code.  We are not supposed to unshare memory operands in an asm from each
> > other.
> 
> I don't think it's the unsharing code.  I assume you're getting the
> same "inconsistent operand constraints in an `asm'" message?  Looking
> at the .loop rtl dump, the problem is that the memory matching contraint
> operand is really different.  This is not an unsharing problem but
> rather an unrolling problem.
> 
> I get correct results if I go ahead and kill the rest of the DEST_ADDR
> code adjacent to the bits I deleted last week.  With this, the code
> coming out of .loop looks pretty nasty, but .life and .combine clean
> things up significantly.

However, they can't remove excess strength-reduced givs.

I think we should use flow information to determine if a biv
is dead outside of a loop; it is all too common that the same
variable is used over and over again as a loop counter, and
then a lot of loop optimizations are hamstringed.

-----
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330



More information about the Gcc-patches mailing list