1944761 - Optimize comparisons with constants better

Status: NEW

(Core :: JavaScript Engine, task, P3)

Description

[Jan de Mooij [:jandem]]

Sp3 Angular-Complex-DOM has this function:

function At(e) {
  return Array.isArray(e) && !0 === e[1]
}

Ion is using an IC for the strict-equality op even though comparing against true is basically a single compare instruction. The JS shell test case below has the same issue.

We could fix this in the Ion backend but ideally we'd also emit more optimized bytecode for these trivial cases. Either "Value is constant" or "Eq but LHS is always <type>". See also TypeOfEq/TypeOfEqOperand.

function f() {
  var arr = [true, 1];
  var res = 0;
  for (var i = 0; i < 100_000; i++) {
    res = arr[i & 1] === !0;
  }
  return res;
}
f();

Comment 1

[Jan de Mooij [:jandem]]

Oh and the IC is fairly hot: I see one instance with 59024 hits in Ion and there might be other compilations of the same function.

It's also a basic operation that we can't afford getting wrong.

Comment 2

[Iain Ireland [:iain]]

When I added polymorphic type snapshots for TypeOf/ToBool (bug 1712030), I vaguely planned to extend it to compare ICs, but never got around to it. I think it would be relatively easy to track which combinations of input types we'd seen at a Compare IC, although turning that information into optimal MIR might be a bit of work.

It does seem like we could generate much better CacheIR to start with if we knew that one of the arguments to a CompareIC was constant, and it naively doesn't seem too hard for the frontend to track that.