------- Additional Comments From schlie at comcast dot net 2004-11-11 15:51
-------
Subject: Re: 3.4.3 ~6x+ performance regression vs.
3.3.1, constant trees not being computed.
> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
> ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11
> 05:04 -------
> int_val & long_val == (long)(int_val) & long_val by what I had quoted in the
> other bug which you were
> talking about this.
>
> Also, that simplification comes from combine and knowning that ((int_val &
> long_val) >> (log2
> long_val)) & 1 (where long_val > MAX_INT) is false (nothing else). The
> problem on PPC and this one is
> the same. Anyways as I had said before this is not a regression.
For what it's worth, comparable code for ppc (as << 23 is within int range):
int foo ( int a ) {
if (a & (1L << 55))
return 1;
else
return 2;
}
Which I suspect will show a difference, although due to ppc's multi-bit
shift capabilities, it's literal representation may be detectable during
instruction-generation/peep-hole-optimization, but not on machines where
multi-bit shifts are not as compactly represented, therefore rely on earlier
recognition and optimization as appears to be present in 3.3.4.
Regardless of ppc relative code quality, 3.4.3 is generating substantially
slower & larger code than 3.3.4 for avr with no corresponding target machine
description changes, therefore would think that 3.4.3 is clearly suffering
from an avr target code performance/quality regression, yes?
As another less dramatic example:
int foo ( long a ) {
if (a & (1L << 23)) // where again (1L << 55) for ppc
return 1;
else
return 2;
}
Also demonstrates 3.4.3's generation of inferior avr code, relative to
3.4.3, with no corresponding changes to it's target description; which
seems to be due to the constant expression (1L << 23) not being computed if
nested within a more complex expression, which 3.3.4 was capable of
detecting, but 3.4.3 isn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
