[Webkit-unassigned] [Bug 160588] Refactor MathIC compilation process in Baseline and DFG to turn temporary registers usage more flexible

[bugzilla-daemon at webkit.org]

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

--- Comment #34 from Saam Barati <sbarati at apple.com> ---
(In reply to comment #33)
> Comment on attachment 294030 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=294030&action=review
> 
> >> Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:3563
> >> +    FPRReg scratchFPR[Generator::scratchFPRRegCount];
> > 
> > I'm more of a fan of using Vector<> with an inline capacity for this API. You'll still get the same property where you don't end up mallocing any memory.
> 
> Sorry for my ignorance here. I used Vector with inline capacity in another
> Patch this weekend, however I didn't totally understand it .Do you mind
> explain me what is the difference of use a Vector<int>, for example?
Using a Vector with an inline capacity as a stack allocated variable will prevent it from mallocing a backing store until you've exceeded InlineCapacity number of elements. You should read the entire vector class to get a better idea of what I'm saying, but at a high level, it has a field like this:

template <typename T, size_t InlineCapacity>
class Vector {
     T m_inlineVector[InlineCapacity];
}

> 
> >> Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:3600
> >> +    for (size_t i = 0; i < std::min<unsigned>(availableGPRs, scratchGPRRegCount); i++) {
> > 
> > It seems wrong if the min() expression ever returns availableGPRs instead of scratchGPRRegCount. I would just turn this into an assert that we have enough registers.
> 
> hum...We can reproduce it on x86_32, for sure, because old implementation
> uses result.tagGPR as scratchGPR because of limited registers. I am going to
> double check it.

-- 
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/20161106/9313f5ce/attachment.html>