Bug 152447

Summary:

Snippefy op_negate for the baseline JIT.

Product:

WebKit

Reporter:

Mark Lam <mark.lam>

Component:

JavaScriptCore

Assignee:

Mark Lam <mark.lam>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

benjamin, fpizlo, ggaren, keith_miller, msaboff, saam, webkit-bug-importer

Priority:

Version:

WebKit Local Build

Hardware:

Unspecified

OS:

Unspecified

Bug Depends on:

152453

Bug Blocks:

Attachments:

Description	Flags
proposed patch.	benjamin: review+
x86_64 benchmark result.	none
x86 benchmark result.	none
x86_64 benchmark result without DFG.	none
x86 benchmark result without DFG.	none

Mark Lam

Reported 2015-12-18 15:50:10 PST

Patch coming.

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
View All Add attachment proposed patch, testcase, etc.

Mark Lam

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

Mark Lam

Comment 2 2015-12-21 10:58:54 PST

Created attachment 267757 [details] x86_64 benchmark result.

Mark Lam

Comment 3 2015-12-21 10:59:25 PST

Created attachment 267758 [details] x86 benchmark result.

Mark Lam

Comment 4 2015-12-21 17:33:09 PST

Created attachment 267769 [details] x86_64 benchmark result without DFG.

Mark Lam

Comment 5 2015-12-21 17:33:34 PST

Created attachment 267770 [details] x86 benchmark result without DFG.

Mark Lam

Comment 6 2015-12-21 17:34:06 PST

All perf results are neutral. This patch is ready for a review.

Benjamin Poulain

Comment 7 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?

Mark Lam

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

Mark Lam

Comment 9 2015-12-22 08:23:27 PST

Thanks for the review. Landed in r194363: <http://trac.webkit.org/r194363>.

Note You need to log in before you can comment on or make changes to this bug.