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
>>>> [email protected]
>>>> http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> squirrelfish-dev mailing list
>> [email protected]
>> http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
>>
>
>
> _______________________________________________
> squirrelfish-dev mailing list
> [email protected]
> http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
_______________________________________________
squirrelfish-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
