This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC] Bit CCP and pointer alignment propagation
On 07/30/2010 06:41 PM, Joseph S. Myers wrote:
On Fri, 30 Jul 2010, Richard Henderson wrote:
On 07/30/2010 06:15 AM, Richard Guenther wrote:
I think we can have negative shift counts (at least the constant folding
code suggests so), this is why I have the code as-is.
VAX has them; I can't recall any other target that does.
Almost all truncate the shift count at some bit position
(sometimes at the largest supported shift count, e.g.
truncate to 6 bits even for a 32-bit shift because there
exists a 64-bit shift; TARGET_SHIFT_TRUNCATION_MASK will
tell you about this).
ARM NEON vector shifts can have negative shift counts (and also truncate).
The VSHL (register) instruction takes its shift counts from the least
significant byte of each element of the second vector, sign-extended (so
right shifts are represented by shift counts whose low byte is negative).
Obviously that is a description of the instruction semantics, not of RTL
Yes, that's the crux. If you wanted to access it you could with an
intrinsic, not with << and >>. If it is better for us (e.g. simpler or
less code), we should define our intermediate representation to disallow
negative shifts. It will make GIMPLE and RTL slightly worse for VAX,
and slightly better for everything else. Targets that care about
negative shifts can use a builtin or unspec respectively.
For the case at hand of course it's not too contorted to allow negative
shifts, so all this is theoretical.