814179 - BaselineCompiler: Fix bitwise ops on arm

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Tom S [:evilpie]]

+++ This bug was initially created as a clone of Bug #811314 +++

Something is going wrong on arm. And we are missing an optimization for JSOP_URSH.

Comment 1

[Douglas Crosher [:dougc]]

Attachment: Optimize BC ARM JSOP_URSH for a double type result.

Comment 2

[Jan de Mooij [:jandem]]

Comment on attachment 739558 [details] [diff] [review]
Optimize BC ARM JSOP_URSH for a double type result.

Review of attachment 739558 [details] [diff] [review]:
-----------------------------------------------------------------

Excellent, thanks! I will fix the nits, push this to Try and then land this today or tomorrow (or let me know if you have commit access and I will let you do it).

::: js/src/ion/arm/BaselineIC-arm.cpp
@@ +182,5 @@
> +            Label toUint;
> +            masm.j(Assembler::LessThan, &toUint);
> +
> +            // Move result and box for return.
> +            masm.tagValue(JSVAL_TYPE_INT32, scratchReg, R0);

Nit: this can be

masm.mov(scratchReg, R0.payloadReg());

because R0.typeReg() should still hold the int32 type tag from the LHS. On x86 we need the tagValue because the rhs operand *must* be in ecx (= R0.typeReg()) there, so we clobber it and use tagValue to restore it afterwards.

@@ +189,5 @@
> +            masm.bind(&toUint);
> +            masm.convertUInt32ToDouble(scratchReg, ScratchFloatReg);
> +            masm.boxDouble(ScratchFloatReg, R0);
> +        }
> +        else {

Nit: } else {

Comment 3

[Jan de Mooij [:jandem]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/068fa0fc9064

Comment 4

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/068fa0fc9064