1941826 - Don't guard for number types in emitGuardIsNumber

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, enhancement)

Description

[André Bargull [:anba]]

NumberOperandId in CacheIR means either Int32 or Double, but in Warp we (generally) always transpile to Double. This affects Float32 optimisations, because additional MToDouble instructions added by WarpCacheIRTranspiler::emitGuardIsNumber can prohibit Float32 instructions. https://phabricator.services.mozilla.com/D215775 tried to fix this by adding MToDouble::canProduceFloat32, but that solution doesn't help in all cases.

For example:

function truncate(f32, i32) {
  i32[0] = f32[0];
}

Is compiled to:

14 loadunboxedscalar arraybufferviewelements13:Elements spectremaskindex12:IntPtr Float32
...
17 truncatetoint32 loadunboxedscalar14:Float32
...
22 storeunboxedscalar arraybufferviewelements21:Elements spectremaskindex20:IntPtr truncatetoint3217:Int32

Whereas:

function truncate(f32, i32) {
  i32[0] = f32[0]|0;
}

Is compiled to:

14 loadunboxedscalar arraybufferviewelements13:Elements spectremaskindex12:IntPtr Float32
15 todouble loadunboxedscalar14:Float32
16 truncatetoint32 todouble15:Double
...
23 storeunboxedscalar arraybufferviewelements22:Elements spectremaskindex21:IntPtr truncatetoint3216:Int32

Notice how the explicit ToInt32 conversion through bitwise-or led to using Double instead of Float32 truncation.

If WarpCacheIRTranspiler::emitGuardIsNumber is modified to return Number types unchanged, we get the expected Float32 instruction sequence:

14 loadunboxedscalar arraybufferviewelements13:Elements spectremaskindex12:IntPtr Float32
15 truncatetoint32 loadunboxedscalar14:Float32
...
22 storeunboxedscalar arraybufferviewelements21:Elements spectremaskindex20:IntPtr truncatetoint3215:Int32

Comment 1

[André Bargull [:anba]]

Attachment: Bug 1941826: Don't guard for number types in emitGuardIsNumber. r=jandem!

This aligns Warp transpilation with CacheIR, because in CacheIR NumberOperandId
can mean either Double or Int32. (There isn't yet an explicit
DoubleOperandId to denote a value is guaranteed to be a Double.)

Float32 optimisations can be more easily applied when MToDouble isn't emitted
and we also no longer need the MToDouble::canProduceFloat32 override added in
D215775.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/286b5cc6d90d
Don't guard for number types in emitGuardIsNumber. r=jandem

Comment 3

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/286b5cc6d90d