Bug 85144 – Bytecompiler should emit trivially fewer jumps in loops

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Filip Pizlo]

Currently for a loop like:

while (foo) bar;

We emit code like:

     jmp continueTarget
topOfLoop:
     <code for bar>
continueTarget:
     <code for foo>
breakTarget:

But it would be more efficient in almost all cases to instead emit:

     <code for foo>
     <code for bar>
continueTarget:
     <code for foo>
breakTarget:

This will lead to more bytecode, and will otherwise be natural for LLInt and Baseline.  But for DFG, it's a hearty win since it reduces the number of basic blocks and makes the data flow relationships between foo and bar more obvious.

[Filip Pizlo]

Created attachment 139375 [details]
the patch

[Maciej Stachowiak]

As a comment unrelated to this patch, it would be nice to have a fallback for emitNodeInConditionContext that knows how to generate regular code plus the branch for nodes without a specialized emitNodeInConditionContext - it's lame to have to do the fallback at every call site.

[WebKit Review Bot]

Comment on attachment 139375 [details]
the patch

Attachment 139375 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12556753

New failing tests:
fast/filesystem/workers/file-writer-sync-truncate-extend.html

[WebKit Review Bot]

Created attachment 139377 [details]
Archive of layout-test-results from ec2-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Filip Pizlo]

Landed in http://trac.webkit.org/changeset/115587

[Geoffrey Garen]

I believe that ForInNode would also benefit from this optimization.

[Filip Pizlo]

Merged in http://trac.webkit.org/changeset/117706