On 2/12/2011, at 9:45 PM, Jakub Jelinek wrote: > On Fri, Dec 02, 2011 at 03:33:06PM +1300, Maxim Kuvyrkov wrote: >> I'm looking at a missed optimizations in combine and it is similar to the >> one you've fixed in PR18942 >> (http://thread.gmane.org/gmane.comp.gcc.patches/81504). >> >> I'm trying to make GCC optimize >> (leu:SI >> (plus:SI (reg:SI) (const_int -1)) >> (const_int 1)) >> >> into >> >> (leu:SI >> (reg:SI) >> (const_int 2)) >> . >> >> Your patch for PR18942 handles only EQ/NE comparisons, and I wonder if >> there is a reason not to handle LEU/GEU, LTU/GTU comparisons as well. I'm >> a bit fuzzy whether signed comparisons can be optimized here as well, but >> I can't see the problem with unsigned comparisons. > > Consider reg:SI being 0? Then (leu:SI (plus:SI (reg:SI) (const_int -1)) > (const_int 1)) > is 0, but (leu:SI (reg:SI) (const_int 2)) is 1. > You could transform this if you have a guarantee that reg:SI will not be 0 > (and, in your general > >> Regarding the testcase, the general pattern >> >> (set (tmp1) (plus:SI (reg:SI) (const_int A)) >> (set (tmp2) (leu:SI (tmp1) (const_int B)) > > case that reg:SI isn't 0 .. A-1).
Jacub, Zdenek, Thank you for explaining the overflow in comparisons. In fact, the unsigned overflow is intentionally used in expanding of switch statements to catch the 'default:' case in certain switch statements with just one conditional branch. -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
