keeleysam / tenfourfox

Automatically exported from code.google.com/p/tenfourfox
0 stars 0 forks source link

Implement BaselineCompiler #224

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Per jandem,

Subject: Re: off bug from 857845

Hi,

Baseline and IonMonkey share the same MacroAssembler and frame infrastructure. 
Baseline is an easier target mainly because it's a much simpler compiler. Many 
Ion instructions, Ion bailouts/invalidation, etc all require platform-dependent 
code. With Baseline we have *some* platform-dependent code (see 
ion/arm/Baseline*) and some files are shared with Ion, but most of it is shared 
(see BaselineCompiler.cpp, BaselineIC.cpp). Also unlike Ion and JM, Baseline 
code will never bailout or be invalidated.

So I think I'd concentrate on Baseline first (run the shell with --no-jm 
--no-ion). Ion will still be compiled since we don't have separate Ion/Baseline 
#ifdef's, so you will probably want to use JS_NOT_REACHED(...) for anything 
that's Ion-only so that you can implement it later.

What you need for Baseline is:

(*) MacroAssembler-*.{h, cpp}. The x86/x64 macro-assemblers are built on top of 
the JSC assemblers. We don't reuse JSC's macro-assemblers, but we do reuse the 
lower-level instruction-emitting code. The ARM assembler was written from 
scratch I think.

(*) Trampolines:

- EnterJIT is used to enter both Ion and Baseline code. Initially you're only 
interested in the case where type == EnterJitBaseline. For baseline code, the 
trampoline also handles OSR from the interpreter: it reserves size for the 
frame by updating the stack pointer, calls into the VM to initialize that frame 
based on the interpreter StackFrame, then jumps into the JIT code. If I were 
you I'd get the non-OSR case working first, because it's simpler. To do that 
you can run with --baseline-eager and add the following to CanEnterBaselineJIT:

        if (JSOp(*cx->regs().pc) == JSOP_LOOPENTRY)
            return Method_Skipped;

- Invalidator: Ion-only, just add JS_NOT_REACHED or something.

- Arguments rectifier: Used by both Ion and Baseline. If we have a function 
call where the callee has more formal arguments than the caller passes in, the 
JITs call the arguments-rectifier instead. It just pushes some |undefined| 
values and re-pushes the other arguments on top of it (arguments are pushed 
last-to-first).

- Bailout thunk: Ion-only.

- Bailout handler: Ion-only.

- generateVMWrapper: generates some wrapper code Baseline and Ion use when 
calling into C++.

- generatePreBarrier: used by both Baseline and Ion for incremental GC.

- generateDebugTrapHandler: used by Baseline only, in debug mode. It gets 
called when a bytecode op has a breakpoint, or step mode is enabled. Not too 
complicated, but initially I'd just add a check for 
cx->compartment->debugMode() to CanEnterBaselineJIT and implement it after 
everything else works.

(*) Bailouts-*.cpp, CodeGenerator-*.cpp, Lowering-*, MoveEmitter-*, LIR-*: all 
Ion-only.

(*) Architecture-*.h, BaselineRegisters-*.h: you will need to implement these.

(*) IonFrames-*.h you will need, I think you can just copy IonFrames-arm.h We 
should probably combine it with x86/x64 at some point since I don't think 
there's much/any difference.

That's the high-level view. Let me know if you want me to go into anything in 
particular. You can use IONFLAGS=help to see which spew channels are available 
for baseline code. You probably want bl-scripts at least to show which scripts 
are compiled.

Jan

The overwhelming good news is that most of this has already been written.

Original issue reported on code.google.com by classi...@floodgap.com on 17 May 2013 at 4:38

GoogleCodeExporter commented 9 years ago
Ah, screw it.

Followup bugs if needed.

Original comment by classi...@floodgap.com on 11 Oct 2013 at 4:25