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.
Created attachment 139375 [details] the patch
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.
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
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
Landed in http://trac.webkit.org/changeset/115587
I believe that ForInNode would also benefit from this optimization.
Merged in http://trac.webkit.org/changeset/117706