Open Bug 1259927 (CacheIR) Opened 9 years ago Updated 3 days ago

[meta] CacheIR tracking bug

Categories

(Core :: JavaScript Engine: JIT, defect, P3)

Product:
Core
Component:
JavaScript Engine: JIT
Type:
defect

Tracking

()

People

(Reporter: jandem, Unassigned)

References

(Depends on 29 open bugs, Blocks 2 open bugs)

Details

(Keywords: meta, perf)

User Story

From bug 1255352 comment 0:

Our current IC design has a number of problems, most importantly:

* Baseline and Ion ICs don't share much code. The same or similar logic and code is duplicated (often slightly differently and more than once per JIT).
* Ion ICs can handle cases that Baseline doesn't support, and vice versa.
* Baseline ICs are sometimes not 'flexible' enough: an example of this is the does-not-exist stub: Baseline does not attach a stub if an object on the proto chain has obj->hasUncacheableProto(), because it's really hard to support this case with the current ICs.
* It's hard to do something like: unwrap a (Window)Proxy, CCW, etc. and then optimize as a normal getprop, without duplicating/complicating a lot of code.
* ICs and Baseline stub classes are boilerplate-heavy (there are > 7000 lines of code in BaselineIC.h and SharedIC.h).
* Register allocation in ICs, especially Ion ICs, can be hard to get right.
* Adding ICs is a lot of work. I want to add an Ion IC for JSOP_IN. We also need ICs for the new |super| property accesses for ES6 classes (these are like normal GetProp/SetProp, but have an additional receiver argument).
* For Ion there's no good mechanism to discard or update stubs that are no longer valid, so we sometimes attach similar stubs multiple times.

I've been working on a design that addresses all of those issues. The idea is that we emit a very simple, linear (there are guards but no loops or branches) CacheIR bytecode, and generate Baseline and Ion IC code from it. The IR for a simple read-slot getprop looks like this:

  GuardIsObject 0
  GuardShape 0
  LoadFixedSlotResult 0

The generated CacheIR will be exactly the same for Baseline and Ion, but they will compile each op to different machine code and Ion can skip certain guards (if it knows they will never fail).

This ensures we optimize exactly the same cases in Baseline and Ion. We still need different CacheIR -> IC code generators, but at that point all the high-level decisions and VM bits are taken care of.

The actual shapes and slot offsets will be stored separately from the CacheIR. Ion can bake those directly into the JitCode, but (just like we do now) Baseline code will store them in the ICStub, allowing us to share IC stub code. Sharing Baseline stub code happens transparently with this design: stubs that have the same CacheIR can share JIT code.

We'll no longer need Baseline ICStub classes for each case, as the stubs are allocated dynamically. Stubs have a pointer to their (shared) CacheIR code, that allows Ion to optimize based on Baseline ICs. (Later on we could compile CacheIR we get from Baseline stubs to Ion MIR instructions, allowing us to inline and optimize more cases in IonBuilder without ICs).

Attachments

(1 obsolete file)

See bug 1255352 comment 0. Filing a new meta bug to track the remaining work.
Depends on: 1258105, 1259925, 1255352
Depends on: 1266180
Depends on: 1266695
Depends on: 1267163
Blocks: 816159
Blocks: sm-js-perf
Priority: -- → P3
Keywords: perf
Depends on: 1310125
Depends on: 1313036
Depends on: 1317292
Depends on: 1317703
Depends on: 1318285
Depends on: 1319087
Depends on: 1319437
Depends on: 1320118
Depends on: 1320145
Depends on: 1320461
Depends on: 1320670
Depends on: 1322091
Depends on: 1322093
Depends on: 1322320
User Story: (updated)
Depends on: 1322783
Depends on: 1323037
Depends on: 1323094
Depends on: 1323096
Depends on: 1323099
Depends on: 1323190
Depends on: 1324561
Depends on: 1324566
Depends on: 1325358
Blocks: 917030
Depends on: 1326067
Blocks: 1139750
Depends on: 1326437
Depends on: 1326438
Depends on: 1328076
Depends on: 1328077
Depends on: 965992
Depends on: 1328140
Depends on: 1328227
Depends on: 1329016
Depends on: 1329195
Depends on: 1133423
Depends on: 1331034
Depends on: 1331136
Depends on: 1332333
Depends on: 1332593
Depends on: 1332946
Depends on: 1333067
Depends on: 1333690
Depends on: 1334187
Depends on: 1334727
Depends on: 1335405
Depends on: 1091978
Depends on: 1336579
Depends on: 1336580
Depends on: 1337024
Depends on: 1337763
Depends on: 1337764
Depends on: 1337773
Depends on: 1337812
Depends on: 1338825
Depends on: 1338828
Depends on: 1339207
Depends on: 1340150
Depends on: 1340153
Depends on: 1340496
Depends on: 1341067
Depends on: 1341071
Depends on: 1341261
Depends on: 1341782
Depends on: 1341789
Blocks: 1241091
Depends on: 1342856
Depends on: 1344691
Depends on: 1346178
Depends on: 1346189
Depends on: 1348790
Depends on: 1348792
Depends on: 1348821
Depends on: 1348850
Depends on: 1348905
Depends on: 1349035
Depends on: 1349148
Depends on: 1349179
Depends on: 1350263
Depends on: 1350896
Depends on: 1351388
Depends on: 1351471
Depends on: 1353353
Depends on: 1353359
Depends on: 1344469
Depends on: 1353384
Depends on: 1353928
Depends on: 1355109
Depends on: 1357759
Depends on: 1358047
Depends on: 1375504
Depends on: 1385278
Depends on: 1419372
Depends on: 1420910
Depends on: 1398099
Depends on: 1432168
Keywords: meta
Depends on: 1440554
Depends on: 1401927
Depends on: 1490348
Depends on: 1490365
Depends on: 1448039
Depends on: 1490441
Depends on: 1486857
Depends on: 1494537
Depends on: 1483345
Depends on: 1501865
Depends on: 1526425
Depends on: 1621201
Depends on: 1643943
Depends on: 1643944
Depends on: 1643948
Depends on: 1653916
Depends on: 1695736
Depends on: 1703469
Depends on: 1743612
Performance Impact: --- → ?
Whiteboard: [qf:meta]
Performance Impact: ? → ---
Depends on: 1771709
Severity: normal → S3
Attachment #9384039 - Attachment is obsolete: true
Blocks: sm-jits
No longer blocks: sm-js-perf
Depends on: 1115544
Depends on: 1388538
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: