[Webkit-unassigned] [Bug 157741] JSC: DFG::SpeculativeJIT::compile special case for MIPS for PutByValWithThis
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon May 16 15:40:31 PDT 2016
https://bugs.webkit.org/show_bug.cgi?id=157741
--- Comment #9 from Guillaume Emont <guijemont at igalia.com> ---
Comment on attachment 279023
--> https://bugs.webkit.org/attachment.cgi?id=279023
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=279023&action=review
>>>> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2947
>>>> + m_jit.move(baseTag, GPRInfo::argumentGPR3);
>>>
>>> This is wrong if basePayload/baseTag are aliased to argument registers w/ each other.
>>> i.e, if basePayload is argumentGPR3 and baseTag is argumentGPR2, this code will do the wrong thing.
>>
>> I thought this was not possible because the argumentGPR's are not in GPRInfo::toRegister() (and not counted in GPRInfo::numberOfRegisters). Including them might be an idea for the future though, as I suspect more registers available might improve performances (and ARM does that so it's probably possible), but I think that's a trickier change, and I'd like to get the build unbroken.
>
> I don't quite understand your response here. Tag/Payload regs will be allocated by the DFG's register allocator. It will happily use argument registers.
> I don't think this makes the code harder to read. All code we write that sets up a call frame must account for this.
Sorry if that wasn't clear, and there is a possibility that I misunderstand something. What I mean is that DFG::RegisterBank<GPRInfo>::allocate() (see ::allocateInternal()) uses GPRInfo::toRegister() (and GPRInfo::numberOfRegisters as RegisterBank::NUM_REGS) as its source of registers. In the case of MIPS, GPRInfo::toRegister() never returns an argumentGPRx. Therefore baseTag and basePayload cannot be an argumentGPRx register. That's my current understanding at least.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160516/14b4b988/attachment.html>
More information about the webkit-unassigned
mailing list