This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Fix some pessimizations due to fixes for PRs 27144 and 27639
- From: Roger Sayle <roger at eyesopen dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, Daniel Berlin <dberlin at dberlin dot org>, <sebastian dot pop at cri dot ensmp dot fr>
- Date: Sat, 17 Jun 2006 19:51:03 -0600 (MDT)
- Subject: Re: [patch] Fix some pessimizations due to fixes for PRs 27144 and 27639
On Wed, 14 Jun 2006, Daniel Berlin wrote:
> Zdenek Dvorak wrote:
> > * tree-ssa-loop-niter.c (implies_nonnegative_p): New function.
> > (derive_constant_upper_bound): Derive more precise upper bound in
> > common cases. Return type changed to double_int.
> > (record_estimate): Reflect the changed return type of
> > derive_constant_upper_bound.
> > * double-int.c (double_int_zext, double_int_sext): Fix.
> > * gcc.dg/tree-ssa/loop-18.c: New test.
Unfortunately, this patch causes a regression of builtins-14.c on (at
least) i686-pc-linux-gnu. The problem is that the compiler miscompiles
itself, incorrectly optimizing the loop in real.c:div_significands.
Because you claim to have bootstrapped and regression tested on
i686, I supect that it wasn't the bootstrapped compiler that you
used for regression testing [a stage1 compiler regtests fine].
A slightly more full explanation is that div_significands returned
inexact == 0 for 1.0/8.0 proir to your change, where as after
subversion revision 114674 (identified by hunting), we now return
inexact != 0. This is sufficient to cause the middle-end to think
that pow(2.0,-3.0) potentially requires FP rounding at run-time,
which causes the second of the two tests in builtins-14.c to fail
to be optimized. I suspect all compile-time floating point divisions
are currently being miscompiled, but builtins-14.c is one of the few
testcases checking this part of the compiler.
Looking at the problematic loop, it has all the "red flags" for
being mis-compiled by tree-ssa-loop-niter.c:
int i, bit = SIGNIFICAND_BITS - 1;
msb = 0;
msb = u.sig[SIGSZ-1] & SIG_MSB;
lshift_significand_1 (&u, &u);
if (msb || cmp_significands (&u, b) >= 0)
sub_significands (&u, &u, b, 0);
set_significand_bit (r, bit);
while (--bit >= 0);
So a jump into a loop, that can also be threaded, in a loop
with a predecrement in the loop condition, where the number
of iterations should be calculable at compile-time, and the
actual loop test being ">= 0", where your patch introduces a
new implies_nonnegative_p function. [People who work in
avionics wouldn't risk writing a loop like this! :>]
Whilst your patch may be innocently uncovering a latent bug
elsewhere in the compiler, there are so many corner-cases in
the problematic loop above, that I thought I'd let you investigate
Many thanks in advance.
p.s. the double-int bug fixes could have been committed independently
of the tree-ssa-loop-niter.c changes which would help rule out their
involvement, and/or simplify reverting your patch should that become