paul99
commented
9 years ago @ibogosavljevic: there is a bit more complexity here than I had remembered. This document describes all the rules: https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
If we are building a standalone Linux version of v8 (for node.js, as one example) for mips32r6, then we can use all the FP registers, and stay compatible with O32/FP64 ABI (Note section 9, the key item is: 6 double-precision callee-save registers ($f20 to $f30 evens). This used to be 12 double-precision registers.
I think the same rules would apply if we are building v8 into an Android system image for mips32r6 (e.g. for the internal webview).
But if we are building for an Android App then we have stricter rules. We cannot use odd registers for float32, for example. We will have to check the register allocator carefully to see if we can that singles and doubles differently. I need to re-read/study the above referenced document to appreciate all the subtlety here.
I suggest that we start with using more regs in mips64, which does not have all these difficult conditions.
I am trying to get more info on O32/FP64 ABI, which is referenced but not explicitly defined in the above. The normal O32 ABI is O32/FP32. This is not the same as n32 which is definitely not what we are using.
There is a mode of operation where v8 and possibly Chrome would be compiled for mips32r1 or mips32r2 but actually be running on a mips32r6 cpu. It is our intention to dynamically detect this at v8 startup, and emit JIT code for r6, so that it will run more efficiently. (Note that the mips32r6 cpu has only fp64 mode)
One aspect of this operation which has not yet been discussed or implemented is how this works with the register allocator. (we have not yet taken advantage of more FP regs in r6/fp64 https://github.com/paul99/v8m-rb/issues/79 - and see https://github.com/paul99/v8m-rb/issues/165, we could also get more allocatable GPRs then)
Our old register allocator maintained a compile-time kMaxNumAllocatableRegisters (separate for GPR and FPR). The allocator passed index from 0..kMaxNumAllocatableRegisters, and mapping from allocation index to register number was done in code.
With the new register definition code from (in-progress) CL https://codereview.chromium.org/1287383003 (mips CL https://codereview.chromium.org/1343533002) it looks like more of this is defined at compile-time, including the specific set of allocatable registers.
Can @palfia or @kilvadyb please comment on if/how this could work, or if maybe we should request changes to this register-definition method.
Note that it's possible that in this backwards-compatible mode, we could stay with current (mips32) allocatable registers, and only go to the full set when compiled for mips32r6 specifically. That does give one more variation to test, however.