Would it not require an unspec to prevent 'clever things' happening to
the negative shift, if we were to encode these in the machine
description? I'm not too clear on what these 'clever things' might be in
the case of shift-by-register (presumably value-range propagation is
one), but I know the NEON shifts are encoded this way for safety.
Given the way the shift patterns in the compiler are written today, quite possibly. Though in the
general case of a non-constant shift the optimizer probably wouldn't be able to safely make any
assumptions that would break things.
I suspect that the shift patterns should really be changed to make the shift be by a QImode value;
this would then correctly describe the number of bits in the register that are really involved in
the shift. Further, we could then say that, for core registers, the full value in that QI register
was used to determine the shift. It would be quite a lot of churn to fix this though.
None of this directly helps with your neon usage, but it does show that we
really don't need to clobber the condition code register to get an
efficient sequence.
Except that it doesn't in the case of a shift by one where there is a
two-instruction sequence that clobbers CC. Presumably this special case
can be treated differently though, right from expand.
All of the sequences above can be simplified significantly if the shift amount is constant and I
think then, that with the exception of the special case you mention (which is only for shift right
by 1) you never need the condition codes and you never need more than 3 ARM instructions:
shifts< 32
LSL AH, AH, #n
ORR AH, AH, AL, LSR #(32 - n)
LSL AL, AL, #n
shifts>= 32
LSL AH, AL, #(n - 32)
MOV AL, #0
In fact both of the above sequences are equally good for Thumb2. If we lost the RRX tweak it
wouldn't be a major loss (we could even put it back as a peephole2 to handle the common case where
the condition code registers were known to be dead).