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.
https://codereview.chromium.org/732103002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
