<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:sbarati@apple.com" title="Saam Barati <sbarati@apple.com>"> <span class="fn">Saam Barati</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - Refactor MathIC compilation process in Baseline and DFG to turn temporary registers usage more flexible"
href="https://bugs.webkit.org/show_bug.cgi?id=160588">bug 160588</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Attachment #289565 Flags</td>
<td>review?
</td>
<td>review-
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Refactor MathIC compilation process in Baseline and DFG to turn temporary registers usage more flexible"
href="https://bugs.webkit.org/show_bug.cgi?id=160588#c17">Comment # 17</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Refactor MathIC compilation process in Baseline and DFG to turn temporary registers usage more flexible"
href="https://bugs.webkit.org/show_bug.cgi?id=160588">bug 160588</a>
from <span class="vcard"><a class="email" href="mailto:sbarati@apple.com" title="Saam Barati <sbarati@apple.com>"> <span class="fn">Saam Barati</span></a>
</span></b>
<pre>Comment on <span class=""><a href="attachment.cgi?id=289565&action=diff" name="attach_289565" title="Patch">attachment 289565</a> <a href="attachment.cgi?id=289565&action=edit" title="Patch">[details]</a></span>
Patch
View in context: <a href="https://bugs.webkit.org/attachment.cgi?id=289565&action=review">https://bugs.webkit.org/attachment.cgi?id=289565&action=review</a>
Mostly LGTM, but I think the patch can become better.
<span class="quote">> Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:3525
> + // If there is no more GPR available to allocate, we get tagGPR from
> + // result, right and left operands. It is possible because they are speculated
> + // and generators know how to restore the tags after operations using these GPRs.</span >
This seems sketchy and probably a bad API. If the 32-bit implementations already do this, why do they even need us to pass in a scratch? They should just do it and have it be opaque to the thing allocating the scratches.
<span class="quote">> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:1559
> + compileMathIC(addIC, 1, 2, repatchingFunction, nonRepatchingFunction);</span >
Style: Please give these names as local variables and pass in the variables to the function.
<span class="quote">> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:1598
> + for (int i = 0; i < MATH_IC_MAX_GPR; i++) {</span >
Don't use "int"
<span class="quote">> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:1600
> + scratchGPRReg[i] = params.gpScratch(0);</span >
This is wrong.
<span class="quote">> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:1606
> + for (int i = 0; i < MATH_IC_MAX_GPR; i++) {</span >
Don't use "int"
<span class="quote">> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:1748
> + compileMathIC(subIC, 1, 2, repatchingFunction, nonRepatchingFunction);</span >
Ditto w.r.t names as above.
Also, why does this need 2 scratch FPRs, but the DFG version needs 1. They should be consistent. However, reading this code, I think the numberOfGPRScratches/numberOfFPRScratches should just be static fields on the various Generator classes, and not on the creators of the ICs.
This seems like a cleaner approach because each place a MulIC (for example) is created, the creator doesn't have to always specify 1 and 1. The Generator will just know.
<span class="quote">> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:1842
> + compileMathIC(mulIC, 1, 2, repatchingFunction, nonRepatchingFunction);</span >
Ditto w.r.t names and using Generator to dictate how many scratches are needed.
<span class="quote">> Source/JavaScriptCore/jit/JITMathIC.h:55
> +#define MATH_IC_MAX_FPR 3</span >
Which IC uses 3?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>