Last Comment Bug 650181 - Design & implement IonMonkey IRs
: Design & implement IonMonkey IRs
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal with 3 votes (vote)
: ---
Assigned To: David Anderson [:dvander]
:
:
Mentors:
Depends on: 661736 664094 664591
Blocks: IonMonkey
  Show dependency treegraph
 
Reported: 2011-04-14 17:54 PDT by David Anderson [:dvander]
Modified: 2011-08-05 14:05 PDT (History)
27 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description David Anderson [:dvander] 2011-04-14 17:54:22 PDT
Roughly in 6-8 weeks we would like to have a prototype of IonMonkey that is able to compile a simple JavaScript loop with a curveball (GETPROP or GETELEM). I don't know how far we should go in optimizing this initial prototype, but I think a few things are needed to prove that the design works:
 * Some kind of specialization and de-specialization
 * Handling both x86 and x64 boxing formats
 * Recompilation or resumption from any safe point
 * Some sort of cross-bb regalloc, maybe just simple linear scan at first

See also bug 646923.
Comment 1 Jacob Bramley [:jbramley] 2011-05-06 02:54:32 PDT
(In reply to comment #0)
>  * Handling both x86 and x64 boxing formats

Will boxing formats differ from what we already have? Will ARM continue to use the same (64-bit) format as x86?

Is there a work-in-progress IR design somewhere that I could look at? It'd be interesting to see if there's anything that might restrict or benefit performance on ARM, before it all gets integrated and hard to change.
Comment 2 David Anderson [:dvander] 2011-05-10 15:32:01 PDT
(In reply to comment #1)
> Will boxing formats differ from what we already have? Will ARM continue to
> use the same (64-bit) format as x86?

The boxing format may change for x64 but I don't think there are any plans for ARM/x86. It seems hard to change on 32-bit CPUs without re-introducing heap doubles. That actually might not be too bad, but it's a huge change (Luke says) because a bunch of infallible functions would need to become fallible.

> Is there a work-in-progress IR design somewhere that I could look at? It'd
> be interesting to see if there's anything that might restrict or benefit
> performance on ARM, before it all gets integrated and hard to change.

I'll get a user repo link up shortly. I've been offline for about a week and am picking up where I left off now. It's at the point where it can recover SSA from the bytecode, with basic control-flow (if branches, do/while loops). Now the next step is figuring out how to generate code off the new IR which entails a few major design pieces:
 * How local type inference and representation decisions work
 * How registers should be assigned to inputs and outputs
 * How values are held in the IR, unboxed and boxed as necessary
 * Whether we should lower the new MIR to a second, lower-level IR
Comment 3 David Anderson [:dvander] 2011-05-12 19:09:02 PDT
repo up: http://hg.mozilla.org/users/danderson_mozilla.com/ionmonkey

Immediate tasks are some more refactorings and getting it to generate some JIT code.

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