Last Comment Bug 1324561 - Compile CacheIR to MIR
: Compile CacheIR to MIR
Status: NEW
: perf
Product: Core
Classification: Components
Component: JavaScript Engine: JIT (show other bugs)
: unspecified
: All All
P3 normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Hannes Verschore [:h4writer]
Mentors:
Depends on:
Blocks: CacheIR jsperf
  Show dependency treegraph
 
Reported: 2016-12-19 13:22 PST by Jan de Mooij [:jandem]
Modified: 2017-01-26 04:08 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Jan de Mooij [:jandem] 2016-12-19 13:22:49 PST
In IonBuilder, when we see a Baseline IC has a single stub (and no had-unoptimizable flag), we can take its ICStub + CacheIR code and inline it by compiling it to MIR instructions.

Many CacheIR ops correspond to a single MIR instruction. The nice thing is that we will be in IonBuilder, so we can use TI to improve things over what the ICs do, for instance it will be easy to eliminate GuardIsObject, GuardGroup, GuardProto etc in many cases (and then this would work for all ICs that use these ops).

This has some great benefits: when we want to optimize a particular case, we emit CacheIR for it, implement the ops in the IC + MIR backends (only if we need a new op), and then we have this optimization everywhere: Baseline ICs, Ion ICs, Ion inline paths with TI optimizations.

Once this works, we should be able to remove a bunch of code from IonBuilder/BaselineInspector. Maybe the code for getters/setters (we do some IR pattern matching for that atm) and maybe even some of the DOM optimizations.

I'm pretty excited about this, but converting the existing Baseline and Ion IC stubs is higher priority for me right now. Just filing this now in case someone else wants to work on it in the meantime.

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