[Webkit-unassigned] [Bug 157741] JSC: DFG::SpeculativeJIT::compile special case for MIPS for PutByValWithThis

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=157741

Guillaume Emont <guijemont at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #279023|commit-queue?               |
              Flags|                            |

--- Comment #7 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:2931
>> +        m_jit.move(TrustedImm32(0), GPRInfo::argumentGPR1);
> 
> Is this because 64-bit values need to be aligned on even registers?

That was my reasoning. Though looking at the code generated by gcc for operationPutByValWithThisStrict(), even in -O0 it never accesses $a1 or the corresponding address on the stack, so I will remove that one line in a subsequent version of the patch. The next value (which is 64 bits) definitely needs to be on $a2 and $a3 though (and accordingly, 4 stack entries need to be reserved for the values we put in $a0-$a3, though they don't need to be set by the caller.

>>> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2933
>>> +        {
>> 
>> If we won't find a way to avoid excessive moves, I propose to merge this code with X86 code path. Only top 4 lines are different for MIPS, everything else looks like an exact copy of X86
> 
> IMO, this will make the code harder to read.

Guilty as charged: I copy-pasted the x86 code and worked from there, I think I was expecting more difference in the end. But yeah, I guess it's a matter of avoiding code duplication vs readability.

>> 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.

-- 
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/cd5687d5/attachment.html>