[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