[JSC] Remove stale assertion about OpCall for PhantomNewArrayBuffer

https://bugs.webkit.org/show_bug.cgi?id=260302
rdar://113948896

Reviewed by Keith Miller and Justin Michaud.

This assertion is wrong since this bytecode can be op_tail_call etc.
And this assertion offers nothing: we are not doing anything relying on this
assertion's condition. So it is just stale. This patch removes it.

* JSTests/stress/ftl-materialize-new-array-buffer.js: Added.
* Source/JavaScriptCore/ftl/FTLOperations.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):

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

JSTests/stress/ftl-materialize-new-array-buffer.js

@@ -0,0 +1,12 @@
+'use strict';
+
+const object = {};
+
+function opt() {
+    return Object.keys(object);
+}
+
+for (let i = 0; i < 1000000; i++)
+    opt();
+
+const tmp = new Array();

Source/JavaScriptCore/ftl/FTLOperations.cpp

@@ -576,9 +576,8 @@ JSC_DEFINE_JIT_OPERATION(operationMaterializeObjectInOSR, JSCell*, (JSGlobalObje
         CodeBlock* codeBlock = baselineCodeBlockForOriginAndBaselineCodeBlock(materialization->origin(), callFrame->codeBlock()->baselineAlternative());
         const auto* currentInstruction = codeBlock->instructions().at(materialization->origin().bytecodeIndex()).ptr();
         if (!currentInstruction->is<OpNewArrayBuffer>()) {
-            // This case can happen if Object.keys, an OpCall is first converted into a NewArrayBuffer which is then converted into a PhantomNewArrayBuffer.
+            // This case can happen if Object.keys, an OpCall, and others is first converted into a NewArrayBuffer which is then converted into a PhantomNewArrayBuffer.
             // There is no need to update the array allocation profile in that case.
-            RELEASE_ASSERT(currentInstruction->is<OpCall>());
             Structure* structure = globalObject->arrayStructureForIndexingTypeDuringAllocation(immutableButterfly->indexingMode());
             return CommonSlowPaths::allocateNewArrayBuffer(vm, structure, immutableButterfly);
         }