Bug 152447 - Snippefy op_negate for the baseline JIT.
Summary: Snippefy op_negate for the baseline JIT.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mark Lam
URL:
Keywords:
Depends on: 152453
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-18 15:50 PST by Mark Lam
Modified: 2015-12-22 08:23 PST (History)
7 users (show)

See Also:


Attachments
proposed patch. (18.36 KB, patch)
2015-12-21 10:58 PST, Mark Lam
benjamin: review+
Details | Formatted Diff | Diff
x86_64 benchmark result. (66.57 KB, text/plain)
2015-12-21 10:58 PST, Mark Lam
no flags Details
x86 benchmark result. (65.68 KB, text/plain)
2015-12-21 10:59 PST, Mark Lam
no flags Details
x86_64 benchmark result without DFG. (65.87 KB, text/plain)
2015-12-21 17:33 PST, Mark Lam
no flags Details
x86 benchmark result without DFG. (64.80 KB, text/plain)
2015-12-21 17:33 PST, Mark Lam
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Lam 2015-12-18 15:50:10 PST
Patch coming.
Comment 1 Mark Lam 2015-12-21 10:58:12 PST
Created attachment 267756 [details]
proposed patch.

Benchmarking shows that perf is neutral when the DFG is enabled.  I still need to run perf numbers for when the DFG is disabled.
Comment 2 Mark Lam 2015-12-21 10:58:54 PST
Created attachment 267757 [details]
x86_64 benchmark result.
Comment 3 Mark Lam 2015-12-21 10:59:25 PST
Created attachment 267758 [details]
x86 benchmark result.
Comment 4 Mark Lam 2015-12-21 17:33:09 PST
Created attachment 267769 [details]
x86_64 benchmark result without DFG.
Comment 5 Mark Lam 2015-12-21 17:33:34 PST
Created attachment 267770 [details]
x86 benchmark result without DFG.
Comment 6 Mark Lam 2015-12-21 17:34:06 PST
All perf results are neutral.  This patch is ready for a review.
Comment 7 Benjamin Poulain 2015-12-22 05:13:17 PST
Comment on attachment 267756 [details]
proposed patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=267756&action=review

> Source/JavaScriptCore/jit/JITNegGenerator.cpp:56
> +    m_endJumpList.append(jit.jump());

Why do you have a "m_endJumpList" used by the user of this object?...

> Source/JavaScriptCore/jit/JITNegGenerator.cpp:67
> +#endif

...Instead of linking the jump here after the Double case?
Comment 8 Mark Lam 2015-12-22 07:08:24 PST
Comment on attachment 267756 [details]
proposed patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=267756&action=review

>> Source/JavaScriptCore/jit/JITNegGenerator.cpp:67
>> +#endif
> 
> ...Instead of linking the jump here after the Double case?

This is to enable an optimization.  If you search in DFGSpeculativeJIT.cpp for "gen.endJumpList().append(m_jit.jump());", you will see cases where the DFG wants to place some slow path code immediately after snippets emit their code.  By having an endJumpList(), we can avoid the cases where the internal of snippets jump to the snippet end, only to jump over some slow path code in the client to the real end point.  The endJumpList allows that the snippet code to jump to the real end point as determined by the client.
Comment 9 Mark Lam 2015-12-22 08:23:27 PST
Thanks for the review.  Landed in r194363: <http://trac.webkit.org/r194363>.