[Webkit-unassigned] [Bug 164600] New: Graph::methodOfGettingAValueProfileFor() should be returning the profile for operand node.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Nov 10 10:30:29 PST 2016


https://bugs.webkit.org/show_bug.cgi?id=164600

            Bug ID: 164600
           Summary: Graph::methodOfGettingAValueProfileFor() should be
                    returning the profile for operand node.
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mark.lam at apple.com

Currently, Graph::methodOfGettingAValueProfileFor() assumes that the operand DFG node that it is provided with always has a different origin than the node that is using that operand.  For example, in a DFG graph that looks like this:
    a: ...
    b: ArithAdd(@a, ...)

... when emitting speculation checks on @a for the ArithAdd node at @b, Graph::methodOfGettingAValueProfileFor() is passed @a, and expects @a's to originate from a different bytecode than @b.

However, op_negate can be compiled into the following series of nodes:

    a: BooleanToNumber(...)
    b: DoubleRep(@a)
    c: ArithNegate(@b)

All 3 nodes maps to the same op_negate bytecode i.e. they have the same origin.  When the speculativeJIT does a speculationCheck in DoubleRep, it calls Graph::methodOfGettingAValueProfileFor() to get the ArithProfile for the BooleanToNumber node.  But because all 3 nodes have the same origin, Graph::methodOfGettingAValueProfileFor() erroneously returns the ArithProfile for the op_negate.  Subsequently, the OSR exit ramp will modify the ArithProfile of the op_negate and corrupt its profile.  Instead, what the OSR exit ramp should be doing is update the ArithProfile of op_negate's operand i.e. BooleanToNumber's operand in this case.

The fix is to always pass the current node we're generating code for (in addition to the operand node) to Graph::methodOfGettingAValueProfileFor().  This way, we can determine if the profile is valid if and only if the current node and its operand node does not have the same origin.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161110/88789fa4/attachment.html>


More information about the webkit-unassigned mailing list