[turbofan] remove redundant '& 0x1F' for shifts.

[turbofan] remove redundant '& 0x1F' for shifts.

JavaScript shifts perform an implicit '& 0x1F' on their right operand, this
patch removes it when the underlying architecture already does it.

BUG=
R=bmeurer@chromium.org

Committed: https://chromium.googlesource.com/v8/v8/+/481772acdd6cded6b3320cdf7cde1084a01a1b22

[Rodolph Perfetta (ARM), 2014-11-17 15:30:22]

rodolph.perfetta@arm.com changed reviewers:
+ bmeurer@chromium.org

[Rodolph Perfetta (ARM), 2014-11-17 15:30:23]

Instead of removing '& 0x1f' in most backend (ia32, x64, arm64 and mips I
believe) I added a machine property which will allow the
machine-operator-reducer to take care of it.

PTAL.

[Benedikt Meurer, 2014-11-17 17:42:13]

Nice catch. Just three nits/comments:

1. I would prefer another name, i.e. how about WordShiftIsSafe or something
along the lines?
2. Shouldn't that also apply to Word32Ror?
3. What about Word64Shr/Shl/Sar/Ror?

[Rodolph Perfetta (ARM), 2014-11-20 12:25:24]

> 1. I would prefer another name, i.e. how about WordShiftIsSafe or something
> along the lines?

Done

> 2. Shouldn't that also apply to Word32Ror?

Unlike shifts ror is not the result of a JavaScript operator but generated
through pattern matching and currently the pattern will not match if there is an
'& 0x1F' in the original sequence (more on this later) so currently adding ror
support would be adding dead code. This patch is particularly useful for shifts
because js-type-lowering will transform x >> y into x >> (y & 0x1F) as per the
ecma specs.

> 3. What about Word64Shr/Shl/Sar/Ror?

They can't be generated by JavaScript and currently 64-bits shifts are only used
for Smi handling where the shift constant is known. I believe the bit of code
which remove '& 0x3F' in the x64 instruction selector is never run when
executing JavaScript.

About Word32Ror, it was never emitted before that patch as the js-type-lowering
will add '& 0x1F' which will prevent the machine operator reducer to recognise
the pattern. Now the pattern matches but there is a bug here: the pattern
recognise rotate left and generate a rotate right. I have fixed the bug in this
patch (I would normally write a separate patch but without the original patch I
can't write a JavaScript test case). Finally ror will not be used in arm32 since
the '& 0x31' is still present.

I intend to follow up with a patch to add rotate right detection but the arm32
issue will remain.

[Benedikt Meurer, 2014-11-20 12:28:49]

LGTM, thanks for fixing.

It should still be possible to detect ROR on ARM, we just need to also take into
account the & 0x1f's

[Rodolph Perfetta (ARM), 2014-11-20 13:09:35]

Committed patchset #2 (id:20001) manually as
481772acdd6cded6b3320cdf7cde1084a01a1b22 (presubmit successful).