Changeset 202790 in webkit for trunk/Source/JavaScriptCore/dfg/DFGLICMPhase.cpp

Timestamp:

Jul 3, 2016, 10:46:39 AM (9 years ago)

Author:

[email protected]

Message:

DFG LICM needs to go all-in on the idea that some loops can't be LICMed
​https://bugs.webkit.org/show_bug.cgi?id=159388

Reviewed by Mark Lam.

Some time ago I acknowledged that LICM required loops to meet certain requirements that
may get broken by the time we do LICM, like that the terminal of the pre-header is ExitOK.
It used to be that we just ignored that requirement and would hoist anyway, but since
r189126 we've stopped hoisting out of loops that don't have ExitOK. We also added tests
for the case that the pre-header doesn't exist or is invalid.

It turns out that this patch didn't go far enough: even though it made LICM avoid loops
that had an invalid pre-header, the part that updated the AI state in nested loops still
assumed that these loops had valid pre-headers. We would crash in null dereference in
that loop if a nested loop had an invalid pre-header.

The fix is simple: don't update the AI state of nested loops that don't have pre-headers,
since we won't try to hoist out of those loops anyway.

• dfg/DFGLICMPhase.cpp:

(JSC::DFG::LICMPhase::attemptHoist):

• tests/stress/licm-no-pre-header-nested.js: Added. This would always crash before this fix.

(foo):

• tests/stress/licm-pre-header-cannot-exit-nested.js: Added. This was a failed attempt at a test, but I figure it's good to have weird code anyway.

(foo):
(valueOf):

File:

• trunk/Source/JavaScriptCore/dfg/DFGLICMPhase.cpp (modified) (1 diff)

trunk/Source/JavaScriptCore/dfg/DFGLICMPhase.cpp

@@ -325 +325 @@
                 continue;
             BasicBlock* subPreHeader = m_data[subLoop->index()].preHeader;
+            // We may not have given this loop a pre-header because either it didn't have exitOK
+            // or the header had multiple predecessors that it did not dominate. In that case the
+            // loop wouldn't be a hoisting candidate anyway, so we don't have to do anything.
+            if (!subPreHeader)
+                continue;
+            // The pre-header's tail may be unreachable, in which case we have nothing to do.
             if (!subPreHeader->cfaDidFinish)
                 continue;