Closed
Bug 650181
Opened 13 years ago
Closed 13 years ago
Design & implement IonMonkey IRs
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: dvander, Assigned: dvander)
References
(Blocks 1 open bug)
Details
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•13 years ago
|
||
(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.
Assignee | ||
Comment 2•13 years ago
|
||
(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
Assignee | ||
Comment 3•13 years ago
|
||
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.
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Updated•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•