Re: [PATCH][RFC] Bit CCP and pointer alignment propagation

[Paolo Bonzini <bonzini@gnu.org>]

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
> or GIMPLE.

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.

Paolo