[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

--- Comment #10 from Saam Barati <sbarati at apple.com> ---
(In reply to comment #9)
> Comment on attachment 279023 [details]
> 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.
I see. Makes sense.

-- 
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/82c07450/attachment-0001.html>