This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]