[JSC] ASSERTION FAILED: child(0)->type() == phi->type()

rdar://147364146
https://bugs.webkit.org/show_bug.cgi?id=290009

Reviewed by Yusuke Suzuki.

Array allocation sinking introduced cases where Upsilon edges may come from nodes
with result types like double or int52, instead of the previously assumed JS result
type. This breaks assumptions made during Phi construction, which always expected
NodeResultJS.

This patch adds `fixUpsilonEdge()`, a pass that ensures Upsilon inputs match the
expected Phi result type by inserting appropriate ValueRep nodes when needed.

* JSTests/stress/array-allocation-sink-upsilon-with-double-value.js: Added.
(test):
* Source/JavaScriptCore/dfg/DFGFlushFormat.h:

Canonical link: https://commits.webkit.org/292572@main

Author: hyjorc1

JSTests/stress/array-allocation-sink-upsilon-with-double-value.js

@@ -0,0 +1,14 @@
+
+function test(x) {
+    const a = new Array(4);
+    let v = 50;
+    for (let i = 0; i < 100; v++) {
+        a[i] = Math.random();
+        if (v % 9 == 0)
+            return;
+    }
+}
+
+for (let i = 0; i < testLoopCount; ++i) {
+    test(i);
+}

Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp

@@ -862,6 +862,7 @@ class ObjectAllocationSinkingPhase : public Phase {
 
         promoteLocalHeap();
         removeICStatusFilters();
+        fixUpsilonEdge();
 
         if (UNLIKELY(Options::validateGraphAtEachPhase()))
             DFG::validate(m_graph, DumpGraph, graphBeforeSinking);
@@ -2819,6 +2820,41 @@ class ObjectAllocationSinkingPhase : public Phase {
         }
     }
 
+    // The added phis have NodeResultJS because their corresponding Upsilon edges, when coming from nodes in
+    // NamedPropertyPLoc, always have use kinds associated with NodeResultJS. However, this assumption breaks
+    // with the introduction of array allocation sinking, since nodes in ArrayIndexedPropertyPLoc may have
+    // use kinds that produce double results.
+    void fixUpsilonEdge()
+    {
+        for (BasicBlock* block : m_graph.blocksInNaturalOrder()) {
+            for (unsigned indexInBlock = 0; indexInBlock < block->size(); ++indexInBlock) {
+                Node* node = block->at(indexInBlock);
+                switch (node->op()) {
+                case Upsilon: {
+                    Edge& edge = node->child1();
+                    if (node->phi()->hasJSResult()) {
+                        Node* result = nullptr;
+                        if (edge->hasDoubleResult())
+                            result = m_insertionSet.insertNode(indexInBlock, SpecBytecodeDouble, ValueRep, node->origin, Edge(edge.node(), DoubleRepUse));
+                        else if (edge->hasInt52Result())
+                            result = m_insertionSet.insertNode(indexInBlock, SpecInt32Only | SpecAnyIntAsDouble, ValueRep, node->origin, Edge(edge.node(), Int52RepUse));
+
+                        if (result) {
+                            edge.setNode(result);
+                            edge.setUseKind(UntypedUse);
+                        }
+                    }
+                    break;
+                }
+                default:
+                    break;
+                }
+            }
+
+            m_insertionSet.execute(block);
+        }
+    }
+
     // This is a great way of asking value->isStillValid() without having to worry about getting
     // different answers. It turns out that this analysis works OK regardless of what this
     // returns but breaks badly if this changes its mind for any particular InferredValue. This