Open Bug 1939427 Opened 2 months ago Updated 27 days ago

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 1 open bug, )

Details

This has a ton of time under IonSetPropertyIC::update, doing something with typed arrays. Maybe double or negative int32 keys again? NI myself to take a quick look at that.

Flags: needinfo?(jdemooij)

ICs for TypedArrays handle both double and negative int32 keys. The benchmark has a TypedArray out-of-bounds read for fire[a], which returns undefined. Then there's an addition with generates a BinaryCache, because the right-hand side is either a Number or undefined. When the rhs is undefined, the addition returns NaN. The NaN is propagated through the division and the Math.floor call. (Source: https://github.com/nischayv/as-benchmarks/blob/master/graphics/fire/assembly/index.ts)

Generated MIR:

...
174 loadtypedarrayelementhole arraybufferviewelements161:Elements int32tointptr173:IntPtr arraybufferviewlength158:IntPtr Value
545 keepaliveobject guardshape156:Object
175 box add172:Int32 Value
176 binarycache box175:Value loadtypedarrayelementhole174:Value Value
177 unbox binarycache176 to Double (fallible) Double
178 div unbox177:Double constant114:Double [double] Double
180 guardspecificfunction loaddynamicslotandunbox538:Object constant124:Object Object
181 nearbyint div178:Double (down) Double
182 setpropertycache loadfixedslotandunbox536:Object lsh128:Int32 nearbyint181:Double
...

The final SetPropertyCache is generated because the CacheIR implementation for GuardToInt32ModUint32 doesn't perform recovery when branchTruncateDoubleMaybeModUint32 fails.

Simple test case which also generates SetPropertyCache:

function test() {
  var ta = new Uint8Array(2);
  for (var i = 0; i < 1000000; ++i) {
    ta[i & 1] = NaN;
  }
  return ta[0] + ta[1];
}

Thanks for the analysis! Could we use the same callWithABI as in CacheIRCompiler::emitTruncateDoubleToUInt32?

Flags: needinfo?(jdemooij)
Severity: -- → S3
Priority: -- → P3
Depends on: 1942255

Bug 1942255 should make this ~2.3x times faster. It's still slower than JSC/V8 because the BinaryCache will prevent moving guards before the loops.

With the latest Nightly: https://share.firefox.dev/4hgbHh8 (120fps without the profiler)

You need to log in before you can comment on or make changes to this bug.