If you look at the code generation for, for example, op_jtrue or op_jfalse, you'll see that we can currently commonly branch on boolean values only inspecting the tag value. If we were to move to a having single tag for booleans then these operations would probably have to change to perform two memory accesses, to load the payload too. My guess is that overall this change would be a regression (testing booleans in this fashion is likely much hotter than arithmetic involving booleans). This hunch could be wrong though. Another possibility would be to redundantly encode the boolean value in both the tag and payload. intTag : -1 : 0xffffffff trueTag : - 2 : 0xfffffffe falseTag : - 2 : 0xfffffffd isInt : tag >= 0xfffffffc isStrictInt : tag == 0xffffffff isBothInt : (tag1 & tag2) == 0xfffffffc isBothStrictInt : (tag1 & tag2) == 0xffffffff Something like this might make the checking cheap for both boolean inspection and arith ops – but it would still require an extra write on storing a boolean property (I believe that currently we only write the tab, leaving the payload undefined). I think we'd definitely want to see a win to land a patch like this – adding things like dependencies between enum values like the tag values reduces the comprehensibility and agility of the code, so I think we'd need a win to justify it. cheers, G. On Mar 4, 2011, at 12:25 PM, Zoltan Herczeg wrote:
We could implement that in the following way:
intTag : -1 : 0xffffffff boolTag : - 2 : 0xfffffffe
isInt : tag >= -2 isStrictInt : tag >= -1 isBothInt : (tag1 & tag2) >= -2 isBothStrictInt : (tag1 & tag2) >= -1
(can be signed or unsigned comparison)
Regards, Zoltan
Probably no, but we could simplify such opcodes:
void JIT::emit_op_jtrue(Instruction* currentInstruction) { unsigned target = currentInstruction[2].u.operand; emitGetVirtualRegister(currentInstruction[1].u.operand, regT0);
Jump isZero = branchPtr(Equal, regT0, ImmPtr(JSValue::encode(jsNumber(0)))); addJump(emitJumpIfImmediateInteger(regT0), target);
addJump(branchPtr(Equal, regT0, ImmPtr(JSValue::encode(jsBoolean(true)))), target); addSlowCase(branchPtr(NotEqual, regT0, ImmPtr(JSValue::encode(jsBoolean(false)))));
isZero.link(this); RECORD_JUMP_TARGET(target); }
The second two checks would be unnecessary, and probably we could squeeze out a little performance gain here.
Zoltan
PS: I didn't say this is much better, instead, I would be interested in your opinion whether you think this would be a good idea or not.
Is there a place where testing for booleans is currently expensive?
Geoff
On Mar 4, 2011, at 5:37 AM, Zoltan Herczeg wrote:
Hi,
I found something interesting in the v8 source code. They store the true and false as integers: 1 and 0. Actually it was a surprise to me, but "true + 1" is "2" in JavaScript, so this kind of object handling seems ok.
Advantage of their approach: they don't need to care about boolean values for all arithmetic and conditional operations in JIT. This could reduce the source code (maintainability), and probably faster, since you don't need to check boolean values.
Disadvantage: type resolving is a bit more difficult, but since that is a rare operation, I think the gain could be bigger.
What is your opinion about it? Would it be possible to implement something like this for JSValue32_64? Would it worth it?
Regards, Zoltan
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev