On Tue, Feb 26, 2013 at 2:12 AM, Wei Mi wrote: > But it is not a good transformation unless we know insn split will > change a << (b & 63) to a << b; Here we want to see what the rtl looks > like after insn splitting in fwprop cost estimation (We call > split_insns in estimate_split_and_peephole(), but not to do insn > splitting actually in this phase).
So you're splitting to find out that the shift is truncated to 5 or 6 bits. That looks like what you really want is to have SHIFT_COUNT_TRUNCATED working for your target. It isn't defined for i386: /* Define if shifts truncate the shift count which implies one can omit a sign-extension or zero-extension of a shift count. On i386, shifts do truncate the count. But bit test instructions take the modulo of the bit offset operand. */ /* #define SHIFT_COUNT_TRUNCATED */ Perhaps SHIFT_COUNT_TRUNCATED should be turned into a target hook, and take an rtx_code (or a pattern) to let the target decide whether a truncation is applicable or not. This is a target thing, so perhaps Uros has some ideas about this. I'm guessing cse.c would then handle your code transformation already, or can be made to do so without a lot of extra work, e.g. teach fold_rtx about such (shift (...) (and (...))) transformations that are really truncations. Ciao! Steven