[Bug middle-end/18424] [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed.

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2004-12-09 15:23 -------
Subject: Re:  [3.4/4.0 Regression] ~6x+ performance
 regression, constant trees not being computed.

Few thoughts:

- I believe avr's back end does know how to convert:

 ((char)x & <pow2-const>) => bit-test x <log2-const>

 which I believe it had relied upon previously.

- might it be possible to recognize, possibly through some sub-reg
  mechanism as avr's word-size is 1(byte), that any right-shift which is
  an word-size multiple may be subtracted off both the logical shited value
  via higher-order subword selection (effectively demoting the operand), and
  correspondingly reducing the const-shift value by the N*word-bit-size?

   i.e. 

  (((long)x & (1 << 28)) == 0) => (((sub-word (long)x 3) >> 4) == 0)
   => (((byte)x >> 4) == 0)

  (then possibly => (((byte)x & 0x10) == 0) which I believe avr's
   back-end knows how to transform into a [bit-test x 5] )

Might this be possible, as it would seem generally useful as well?

Thanks again, -paul-

> From: roger at eyesopen dot com <gcc-bugzilla@gcc.gnu.org>
> ------- Additional Comments From roger at eyesopen dot com  2004-12-09 14:59
> -------
> The patch is a "partial" fix as there will still be a performance regression
> for
> the code generated vs. gcc 3.3.1.  The reason being that 3.3.1 generated
> incorrect code for test program in this PR.
> 
> int foo(int a) { return (a & (1L<<23)) ? 1 : 2; }
> 
> is supposed to sign-extend "a" from a 16-bit integer to a 32-bit long, to
> match
> the (long) constant operand.  This sign-extension may end setting bit 23, so
> the
> result of the function is dependent upon "a".  i.e. the best we can do is:
> 
> int foo(int a) { return (a < 0) ? 1 : 2; }
> 
> Unfortunately, we don't quite get that efficient for avr-elf, instead still
> producing the sign-extension and an AND by constant.  This fixes the
> regression
> aspects of this patch, but we still have a missed optimization.  The code we
> generate is:




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424