I'm wrestling with a problem with the PowerPC implementation of
IonMonkey that I can't solve because I'm not sure what the goal state
is. (For reference, the Baseline Compiler implementation does work, so
the basic machinery is present.) Consider this script, which runs fine
on PowerPC with --baseline-eager --no-ion:
var i,j=0; for(i=0;i<50000;i++) { j+=i } print(j);
If run with --ion-eager, on Mac x64 the debug jsshell fires off a few
snapshots, then immediately invalidates and bails out to Baseline, which
I assume is expected since it needs more type information than it has at
that point in execution.
The instruction sequence is
[Codegen] instruction Label
[Codegen] instruction Parameter
[Codegen] instruction Start
[Codegen] instruction CheckOverRecursed
[Codegen] instruction OsiPoint
then
[Codegen] instruction MoveGroup
[Codegen] instruction Unbox
[Codegen] instruction MoveGroup
[Codegen] instruction CallGetIntrinsicValue
then
[Codegen] instruction Nop
[Codegen] instruction OsiPoint
It looks like GetIntrinsicValue triggers the invalidation. In PowerPC,
the VM call looks like this; note there is no simple way to push the
instruction pointer other than making a tiny local branch to set the
link register:
[Codegen] instruction CallGetIntrinsicValue
[Codegen] == push(immgcptr) ==
[Codegen] #label ((1068))
[Codegen] == push(imm) ==
[Codegen] 0201522c --- lis r0,913 (0x3910000)
[Codegen] 02015230 --- ori r0,r0,18768 (0x4950)
[Codegen] 02015234 --- stwu r0,-4(sp)
[Codegen] == callWithExitFrame(ion *) ==
[Codegen] == push(imm) ==
[Codegen] 02015238 --- li r0,2112 (0x840)
[Codegen] 0201523c --- stwu r0,-4(sp)
[Codegen] == call(JitCode) ==
[Codegen] 02015240 --- mfspr r0,lr
[Codegen] 02015244 --- bl .+4 << "lr = pc"
[Codegen] 02015248 --- mfspr r12,lr << get pc into r12
[Codegen] 0201524c --- mtspr lr, r0
[Codegen] 02015250 --- addi r12,r12,32 (0x20) << push pc+32
[Codegen] 02015254 --- stwu r12,-4(sp)
[Codegen] 02015258 --- x_skip_this_jump
/* x_skip_this_jump is patched by the assembler to a lis/ori/mtctr
stanza to call the VM wrapper */
[Codegen] 0201525c --- nop
[Codegen] 02015260 --- nop
[Codegen] 02015264 --- bctrl << jump to CTR
/* VM gets called and returns here */
[Codegen] ##addPendingCall offs 00000458 to 00cf1fa0
[Codegen] #label ((1128))
[Codegen] == push(reg) ==
[Codegen] 02015268 --- stwu r3,-4(sp)
[Codegen] == push(reg) ==
[Codegen] 0201526c --- stwu r4,-4(sp)
....
The return address (using these offsets) is 0x02015268. That's where it
should return to, if I understand what it's doing. By the way, it
doesn't look like I need to preserve LR and it was never saved in
Baseline; it's just here for paranoia.
The return address doesn't correspond to where the OsiPoint got marked
-- it gets marked way down at 0x020153cc after the CallGetIntrinsic, or
way back at 0x020527c4 with the OsiPoint/MoveGroup. So it asserts in
IonScript::getOsiIndex() because the return address doesn't match any of
the recorded OsiPoints.
What should I be doing here? What should be the location I push? Or how
would you recommend I change the way the OsiPoints are indexed?
Cameron Kaiser
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
