Title: [231832] branches/safari-605-branch/Source/_javascript_Core
- Revision
- 231832
- Author
- [email protected]
- Date
- 2018-05-15 18:42:02 -0700 (Tue, 15 May 2018)
Log Message
Cherry-pick r230485. rdar://problem/39988105
REGRESSION(r227341 and r227742): AI and clobberize should be precise and consistent about the effectfulness of CompareEq
https://bugs.webkit.org/show_bug.cgi?id=184455
Reviewed by Michael Saboff.
LICM is sort of an assertion that AI is as precise as clobberize about effects. If clobberize
says that something is not effectful, then LICM will try to hoist it. But LICM's AI hack
(AtTailAbstractState) cannot handle hoisting of things that have effects. So, if AI thinks that
the thing being hoisted does have effects, then we get a crash.
In r227341, we incorrectly told AI that CompareEq(Untyped:, _) is effectful. In fact, only
ComapreEq(Untyped:, Untyped:) is effectful, and clobberize knew this already. As a result, LICM
would blow up if we hoisted CompareEq(Untyped:, Other:), which clobberize knew wasn't
effectful.
Instead of fixing this by making AI precise, in r227742 we made matters worse by then breaking
clobberize to also think that CompareEq(Untyped:, _) is effectful.
This fixes the whole situation by teaching both clobberize and AI that the only effectful form
of CompareEq is ComapreEq(Untyped:, Untyped:).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230485 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Modified Paths
Diff
Modified: branches/safari-605-branch/Source/_javascript_Core/ChangeLog (231831 => 231832)
--- branches/safari-605-branch/Source/_javascript_Core/ChangeLog 2018-05-16 01:42:00 UTC (rev 231831)
+++ branches/safari-605-branch/Source/_javascript_Core/ChangeLog 2018-05-16 01:42:02 UTC (rev 231832)
@@ -1,5 +1,65 @@
2018-05-15 Kocsen Chung <[email protected]>
+ Cherry-pick r230485. rdar://problem/39988105
+
+ REGRESSION(r227341 and r227742): AI and clobberize should be precise and consistent about the effectfulness of CompareEq
+ https://bugs.webkit.org/show_bug.cgi?id=184455
+
+ Reviewed by Michael Saboff.
+
+ LICM is sort of an assertion that AI is as precise as clobberize about effects. If clobberize
+ says that something is not effectful, then LICM will try to hoist it. But LICM's AI hack
+ (AtTailAbstractState) cannot handle hoisting of things that have effects. So, if AI thinks that
+ the thing being hoisted does have effects, then we get a crash.
+
+ In r227341, we incorrectly told AI that CompareEq(Untyped:, _) is effectful. In fact, only
+ ComapreEq(Untyped:, Untyped:) is effectful, and clobberize knew this already. As a result, LICM
+ would blow up if we hoisted CompareEq(Untyped:, Other:), which clobberize knew wasn't
+ effectful.
+
+ Instead of fixing this by making AI precise, in r227742 we made matters worse by then breaking
+ clobberize to also think that CompareEq(Untyped:, _) is effectful.
+
+ This fixes the whole situation by teaching both clobberize and AI that the only effectful form
+ of CompareEq is ComapreEq(Untyped:, Untyped:).
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230485 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2018-04-10 Filip Pizlo <[email protected]>
+
+ REGRESSION(r227341 and r227742): AI and clobberize should be precise and consistent about the effectfulness of CompareEq
+ https://bugs.webkit.org/show_bug.cgi?id=184455
+
+ Reviewed by Michael Saboff.
+
+ LICM is sort of an assertion that AI is as precise as clobberize about effects. If clobberize
+ says that something is not effectful, then LICM will try to hoist it. But LICM's AI hack
+ (AtTailAbstractState) cannot handle hoisting of things that have effects. So, if AI thinks that
+ the thing being hoisted does have effects, then we get a crash.
+
+ In r227341, we incorrectly told AI that CompareEq(Untyped:, _) is effectful. In fact, only
+ ComapreEq(Untyped:, Untyped:) is effectful, and clobberize knew this already. As a result, LICM
+ would blow up if we hoisted CompareEq(Untyped:, Other:), which clobberize knew wasn't
+ effectful.
+
+ Instead of fixing this by making AI precise, in r227742 we made matters worse by then breaking
+ clobberize to also think that CompareEq(Untyped:, _) is effectful.
+
+ This fixes the whole situation by teaching both clobberize and AI that the only effectful form
+ of CompareEq is ComapreEq(Untyped:, Untyped:).
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+
+2018-05-15 Kocsen Chung <[email protected]>
+
Cherry-pick r231317. rdar://problem/39988108
WebContent crash loading page on seas.upenn.edu @ _javascript_Core: vmEntryToJavaScript
Modified: branches/safari-605-branch/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h (231831 => 231832)
--- branches/safari-605-branch/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h 2018-05-16 01:42:00 UTC (rev 231831)
+++ branches/safari-605-branch/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h 2018-05-16 01:42:02 UTC (rev 231832)
@@ -1637,7 +1637,7 @@
}
}
- if (isClobbering)
+ if (node->isBinaryUseKind(UntypedUse))
clobberWorld(node->origin.semantic, clobberLimit);
forNode(node).setType(SpecBoolean);
break;
Modified: branches/safari-605-branch/Source/_javascript_Core/dfg/DFGClobberize.h (231831 => 231832)
--- branches/safari-605-branch/Source/_javascript_Core/dfg/DFGClobberize.h 2018-05-16 01:42:00 UTC (rev 231831)
+++ branches/safari-605-branch/Source/_javascript_Core/dfg/DFGClobberize.h 2018-05-16 01:42:02 UTC (rev 231832)
@@ -1560,7 +1560,6 @@
write(HeapObjectCount);
return;
}
-
if (node->isBinaryUseKind(UntypedUse)) {
read(World);
write(Heap);
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
