------- 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 <[EMAIL PROTECTED]> > ------- 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