On Fri, 2009-03-13 at 12:34 +0100, Paolo Bonzini wrote: > These are all the !SHIFT_COUNT_TRUNCATED targets. > > For 4.5 I would like to improve our RTL canonicalization so that no > out-of-range shifts are ever in the RTL representation. > > This in turn means that the description given by SHIFT_COUNT_TRUNCATED > must be exact. Right now !SHIFT_COUNT_TRUNCATED means "I don't know", > I want it to mean "it is never truncated". > > I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000 > (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which > do not define it at all) it is right that shift counts are never > truncated. > > In addition, for arm and m68k I'd like to know whether bitfield > instructions truncate the bit position the same as shifts (8 bits for > arm, 6 bits for m68k). > > This information is particularly important for targets that do not > have a simulator in src.
A number of years ago (probably more than 10 now) I tried to rework the ARM backend code to use a QImode register to represent the shift. That then fully described the behaviour of the shift operation. While this made a small number of cases generate code the overall result was overwhelmingly worse. Maybe I didn't push the tweaks far enough to recover the lost cases, but I suspect that, at least at that time, GCC just couldn't do a decent job with having a subreg in the shift operand position. Will have to check up on the bitfields question. I do know that the rules for Neon instructions are not the same as those for ARM instructions. R.