1710905 - Improve optimization of polymorphic TypeOf

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, task, P1)

Description

[Iain Ireland [:iain]]

Looking at ReactDOM CacheIR, I saw a number of cases where typeof and comparison ICs were polymorphic. We don't have a great story for optimizing those cases; we generally end up falling back to Ion ICs.

One approach is to store information about the input types in each IC stub. In WarpOracle, we can walk the IC chain, collect type information, and sort it by stub success rate.

Once we have that information, we can optimize polymorphic typeof by checking for the most common types first. On the following best-case microbenchmark, with a 100:1 string:object ratio, we speed up by ~50% (note that we check for strings relatively late in the default order in visitTypeOfV):

var input = [];
for (var i = 0; i < 100; i++) {
    input.push("");
}
input.push({});

with ({}) {}

function foo(n) {
    var x;
    for (var i = 0; i < n; i++) {
	for (var j = 0; j < input.length; j++) {
	    x = typeof input[j];
	}
    }
    return x;
}

// Compile.
foo(2000);

var t = dateNow();
foo(10000000);
print(dateNow() - t);

We can hopefully use a similar technique to optimize polymorphic compare ICs.

Comment 1

[Iain Ireland [:iain]]

Attachment: Bug 1710905: Part 1: Store type data in TypeOf IC stubs r=jandem!

TypeData currently stores a single JSValueType initialized to TYPE_UNKNOWN. I think we'll need a second JSValueType to support compare ICs. Fortunately, we have three bytes of empty padding to work with in the ICStub.

Comment 2

[Iain Ireland [:iain]]

Attachment: Bug 1710905: Part 2: Hoist ValTypeToString into JitSpewer.h r=jandem!

I wanted to be able to print out value types in the Warp snapshot. The only place where we were currently doing it was when dumping recovery snapshots. This patch hoists that code into JitSpewer so that it's more conveniently available when spewing.

Depends on D115102

Comment 3

[Iain Ireland [:iain]]

Attachment: Bug 1710905: Part 3: Create WarpPolymorphicTypes snapshots r=jandem!

For now I've made TypeDataList a statically sized array so that we can just pass it around by value. (It's only 7 bytes right now, although that may go up to 13 when I add support for compare ICs.)

I'm hoping that WarpOracle can just collect / sort the TypeData in an ICKind-agnostic way, and let WarpBuilder decide what to do with it. It works for typeof ICs, so we'll see if the same is true for compare.

The bailout loop detection code isn't affected yet because MTypeOf never bails out. I think everything should Just Work when we add support for compare, but we can revisit that question once it's implemented.

Depends on D115103

Comment 4

[Iain Ireland [:iain]]

Attachment: Bug 1710905: Part 4: Reorder type checks in visitTypeOfV based on observed types r=jandem!

I've preserved the existing default ordering.

I'm not totally happy with the initializer_list + vector approach to representing the default order / remaining types, but we don't seem to have any container types that can be initialized with a literal list and remove arbitrary elements. Maybe I missed something obvious.

Depends on D115104

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/88ffe095999a
Part 1: Store type data in TypeOf IC stubs r=jandem
https://hg.mozilla.org/integration/autoland/rev/80be9ecca2c5
Part 2: Hoist ValTypeToString into JitSpewer.h r=jandem
https://hg.mozilla.org/integration/autoland/rev/79e5a948dd79
Part 3: Create WarpPolymorphicTypes snapshots r=jandem
https://hg.mozilla.org/integration/autoland/rev/bcdc8859c3cc
Part 4: Reorder type checks in visitTypeOfV based on observed types r=jandem

Comment 6

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/88ffe095999a
https://hg.mozilla.org/mozilla-central/rev/80be9ecca2c5
https://hg.mozilla.org/mozilla-central/rev/79e5a948dd79
https://hg.mozilla.org/mozilla-central/rev/bcdc8859c3cc