⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Changeset 181495 in webkit


Ignore:
Timestamp:
Mar 13, 2015, 7:50:36 PM (11 years ago)
Author:
fpizlo@apple.com
Message:

Object allocation sinking phase shouldn't re-decorate previously sunken allocations on each fixpoint operation
https://bugs.webkit.org/show_bug.cgi?id=142686

Reviewed by Oliver Hunt.

Just because promoteHeapAccess() notifies us of an effect to a heap location in a node doesn't
mean that we should handle it as if it was for one of our sinking candidates. Instead we should
prune based on m_sinkCandidates.

This fixes a benign bug where we would generate a lot of repeated IR for some pathological
tests.

  • dfg/DFGObjectAllocationSinkingPhase.cpp:

(JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):

Location:
trunk/Source/JavaScriptCore
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/JavaScriptCore/ChangeLog

    r181491 r181495  
     12015-03-13  Filip Pizlo  <fpizlo@apple.com>
     2
     3        Object allocation sinking phase shouldn't re-decorate previously sunken allocations on each fixpoint operation
     4        https://bugs.webkit.org/show_bug.cgi?id=142686
     5
     6        Reviewed by Oliver Hunt.
     7       
     8        Just because promoteHeapAccess() notifies us of an effect to a heap location in a node doesn't
     9        mean that we should handle it as if it was for one of our sinking candidates. Instead we should
     10        prune based on m_sinkCandidates.
     11       
     12        This fixes a benign bug where we would generate a lot of repeated IR for some pathological
     13        tests.
     14
     15        * dfg/DFGObjectAllocationSinkingPhase.cpp:
     16        (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
     17
    1182015-03-13  Eric Carlson  <eric.carlson@apple.com>
    219
  • trunk/Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp

    r174318 r181495  
    582582                    node,
    583583                    [&] (PromotedHeapLocation location, Edge) {
    584                         locations.add(location);
     584                        if (m_sinkCandidates.contains(location.base()))
     585                            locations.add(location);
    585586                    },
    586587                    [&] (PromotedHeapLocation location) {
    587                         locations.add(location);
     588                        if (m_sinkCandidates.contains(location.base()))
     589                            locations.add(location);
    588590                    });
    589591            }
     
    637639                    node,
    638640                    [&] (PromotedHeapLocation location, Edge value) {
     641                        if (!m_sinkCandidates.contains(location.base()))
     642                            return;
    639643                        SSACalculator::Variable* variable = m_locationToVariable.get(location);
    640644                        m_ssaCalculator.newDef(variable, block, value.node());
     
    688692                    node,
    689693                    [&] (PromotedHeapLocation location, Edge value) {
    690                         m_localMapping.set(location, value.node());
     694                        if (m_sinkCandidates.contains(location.base()))
     695                            m_localMapping.set(location, value.node());
    691696                    },
    692697                    [&] (PromotedHeapLocation location) {
    693                         node->replaceWith(resolve(block, location));
     698                        if (m_sinkCandidates.contains(location.base()))
     699                            node->replaceWith(resolve(block, location));
    694700                    });
    695701            }
Note: See TracChangeset for help on using the changeset viewer.