AI does not correctly model the clobber case of ArithClz32
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-11-02  Filip Pizlo  <fpizlo@apple.com>
2
3         AI does not correctly model the clobber case of ArithClz32
4         https://bugs.webkit.org/show_bug.cgi?id=179188
5
6         Reviewed by Michael Saboff.
7
8         The non-Int32 case clobbers the world because it may call valueOf.
9
10         * dfg/DFGAbstractInterpreterInlines.h:
11         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
12
13 2017-11-02  Yusuke Suzuki  <utatane.tea@gmail.com>
14
15         Unreviewed, release throw scope
16         https://bugs.webkit.org/show_bug.cgi?id=178726
17
18         * dfg/DFGOperations.cpp:
19
20 2017-11-02  Frederic Wang  <fwang@igalia.com>
21
22         Add references to bug 179167 in FIXME comments
23         https://bugs.webkit.org/show_bug.cgi?id=179168
24
25         Reviewed by Daniel Bates.
26
27         * Configurations/FeatureDefines.xcconfig:
28
29 2017-11-01  Jeremy Jones  <jeremyj@apple.com>
30
31         Implement WKFullscreenWindowController for iOS.
32         https://bugs.webkit.org/show_bug.cgi?id=178924
33         rdar://problem/34697120
34
35         Reviewed by Simon Fraser.
36
37         Enable ENABLE_FULLSCREEN_API for iOS.
38
39         * Configurations/FeatureDefines.xcconfig:
40
41 2017-11-01  Mark Lam  <mark.lam@apple.com>
42
43         Add support to throw OOM if MarkedArgumentBuffer may overflow.
44         https://bugs.webkit.org/show_bug.cgi?id=179092
45         <rdar://problem/35116160>
46
47         Reviewed by Saam Barati.
48
49         The test for overflowing a MarkedArgumentBuffer will run for a ridiculously long
50         time, which renders it unsuitable for automated tests.  Instead, I've run a
51         test manually to verify that an OutOfMemoryError will be thrown when an overflow
52         occurs.
53
54         The MarkedArgumentBuffer's destructor will now assert that the client has indeed
55         checked for an overflow after invoking methods that may result in an overflow i.e.
56         the destructor checks that MarkedArgumentBuffer::hasOverflowed() has been called.
57         This is only done on debug builds.
58
59         * API/JSObjectRef.cpp:
60         (JSObjectMakeFunction):
61         (JSObjectMakeArray):
62         (JSObjectMakeDate):
63         (JSObjectMakeRegExp):
64         (JSObjectCallAsFunction):
65         (JSObjectCallAsConstructor):
66         * dfg/DFGOperations.cpp:
67         * inspector/InjectedScriptManager.cpp:
68         (Inspector::InjectedScriptManager::createInjectedScript):
69         * inspector/JSJavaScriptCallFrame.cpp:
70         (Inspector::JSJavaScriptCallFrame::scopeChain const):
71         * interpreter/Interpreter.cpp:
72         (JSC::Interpreter::executeProgram):
73         * jsc.cpp:
74         (functionDollarAgentReceiveBroadcast):
75         * runtime/ArgList.cpp:
76         (JSC::MarkedArgumentBuffer::slowEnsureCapacity):
77         (JSC::MarkedArgumentBuffer::expandCapacity):
78         (JSC::MarkedArgumentBuffer::slowAppend):
79         * runtime/ArgList.h:
80         (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer):
81         (JSC::MarkedArgumentBuffer::appendWithAction):
82         (JSC::MarkedArgumentBuffer::append):
83         (JSC::MarkedArgumentBuffer::appendWithCrashOnOverflow):
84         (JSC::MarkedArgumentBuffer::hasOverflowed):
85         (JSC::MarkedArgumentBuffer::setNeedsOverflowCheck):
86         (JSC::MarkedArgumentBuffer::clearNeedsOverflowCheck):
87         * runtime/ArrayPrototype.cpp:
88         * runtime/CommonSlowPaths.cpp:
89         (JSC::SLOW_PATH_DECL):
90         * runtime/GetterSetter.cpp:
91         (JSC::callSetter):
92         * runtime/IteratorOperations.cpp:
93         (JSC::iteratorNext):
94         (JSC::iteratorClose):
95         * runtime/JSBoundFunction.cpp:
96         (JSC::boundThisNoArgsFunctionCall):
97         (JSC::boundFunctionCall):
98         (JSC::boundThisNoArgsFunctionConstruct):
99         (JSC::boundFunctionConstruct):
100         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
101         (JSC::constructGenericTypedArrayViewFromIterator):
102         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
103         (JSC::genericTypedArrayViewProtoFuncSlice):
104         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
105         * runtime/JSGlobalObject.cpp:
106         (JSC::JSGlobalObject::haveABadTime):
107         * runtime/JSInternalPromise.cpp:
108         (JSC::JSInternalPromise::then):
109         * runtime/JSJob.cpp:
110         (JSC::JSJobMicrotask::run):
111         * runtime/JSMapIterator.cpp:
112         (JSC::JSMapIterator::createPair):
113         * runtime/JSModuleLoader.cpp:
114         (JSC::JSModuleLoader::provideFetch):
115         (JSC::JSModuleLoader::loadAndEvaluateModule):
116         (JSC::JSModuleLoader::loadModule):
117         (JSC::JSModuleLoader::linkAndEvaluateModule):
118         (JSC::JSModuleLoader::requestImportModule):
119         * runtime/JSONObject.cpp:
120         (JSC::Stringifier::toJSONImpl):
121         (JSC::Stringifier::appendStringifiedValue):
122         (JSC::Walker::callReviver):
123         * runtime/JSObject.cpp:
124         (JSC::ordinarySetSlow):
125         (JSC::callToPrimitiveFunction):
126         (JSC::JSObject::hasInstance):
127         * runtime/JSPromise.cpp:
128         (JSC::JSPromise::initialize):
129         (JSC::JSPromise::resolve):
130         * runtime/JSPromiseDeferred.cpp:
131         (JSC::newPromiseCapability):
132         (JSC::callFunction):
133         * runtime/JSSetIterator.cpp:
134         (JSC::JSSetIterator::createPair):
135         * runtime/LiteralParser.cpp:
136         (JSC::LiteralParser<CharType>::parse):
137         * runtime/MapConstructor.cpp:
138         (JSC::constructMap):
139         * runtime/ObjectConstructor.cpp:
140         (JSC::defineProperties):
141         * runtime/ProxyObject.cpp:
142         (JSC::performProxyGet):
143         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
144         (JSC::ProxyObject::performHasProperty):
145         (JSC::ProxyObject::performPut):
146         (JSC::performProxyCall):
147         (JSC::performProxyConstruct):
148         (JSC::ProxyObject::performDelete):
149         (JSC::ProxyObject::performPreventExtensions):
150         (JSC::ProxyObject::performIsExtensible):
151         (JSC::ProxyObject::performDefineOwnProperty):
152         (JSC::ProxyObject::performGetOwnPropertyNames):
153         (JSC::ProxyObject::performSetPrototype):
154         (JSC::ProxyObject::performGetPrototype):
155         * runtime/ReflectObject.cpp:
156         (JSC::reflectObjectConstruct):
157         * runtime/SetConstructor.cpp:
158         (JSC::constructSet):
159         * runtime/StringPrototype.cpp:
160         (JSC::replaceUsingRegExpSearch):
161         (JSC::replaceUsingStringSearch):
162         * runtime/WeakMapConstructor.cpp:
163         (JSC::constructWeakMap):
164         * runtime/WeakSetConstructor.cpp:
165         (JSC::constructWeakSet):
166         * wasm/js/WasmToJS.cpp:
167         (JSC::Wasm::wasmToJS):
168
169 2017-11-01  Michael Saboff  <msaboff@apple.com>
170
171         Integer overflow in code generated by LoadVarargs processing in DFG and FTL.
172         https://bugs.webkit.org/show_bug.cgi?id=179140
173
174         Reviewed by Saam Barati.
175
176         Added overflow checks to computation of arg count plus this.
177
178         * dfg/DFGSpeculativeJIT32_64.cpp:
179         (JSC::DFG::SpeculativeJIT::compile):
180         * dfg/DFGSpeculativeJIT64.cpp:
181         (JSC::DFG::SpeculativeJIT::compile):
182         * ftl/FTLLowerDFGToB3.cpp:
183         (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
184
185 2017-11-01  Yusuke Suzuki  <utatane.tea@gmail.com>
186
187         Unreviewed, use weakPointer instead of FTLOutput::weakPointer
188         https://bugs.webkit.org/show_bug.cgi?id=178934
189
190         * ftl/FTLLowerDFGToB3.cpp:
191         (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
192
193 2017-11-01  Yusuke Suzuki  <utatane.tea@gmail.com>
194
195         [JSC] Introduce @toObject
196         https://bugs.webkit.org/show_bug.cgi?id=178726
197
198         Reviewed by Saam Barati.
199
200         This patch introduces @toObject intrinsic. And we introduce op_to_object bytecode and DFG ToObject node.
201         Previously we emulated @toObject behavior in builtin JS. But it consumes much bytecode size while @toObject
202         is frequently seen and defined clearly in the spec. Furthermore, the emulated @toObject always calls
203         ObjectConstructor in LLInt and Baseline.
204
205         We add a new intrinsic `@toObject(target, "error message")`. It takes an error message string constant to
206         offer understandable messages in builtin JS. We can change the frequently seen "emulated ToObject" operation
207
208             if (this === @undefined || this === null)
209                 @throwTypeError("error message");
210             var object = @Object(this);
211
212         with
213
214             var object = @toObject(this, "error message");
215
216         And we handle op_to_object in DFG as ToObject node. While CallObjectConstructor does not throw an error for null/undefined,
217         ToObject needs to throw an error for null/undefined. So it is marked as MustGenerate and it clobbers the world.
218         In fixup phase, we attempt to convert ToObject to CallObjectConstructor with edge filters to relax its side effect.
219
220         It also fixes a bug that CallObjectConstructor DFG node uses Node's semantic GlobalObject instead of function's one.
221
222         * builtins/ArrayConstructor.js:
223         (from):
224         * builtins/ArrayPrototype.js:
225         (values):
226         (keys):
227         (entries):
228         (reduce):
229         (reduceRight):
230         (every):
231         (forEach):
232         (filter):
233         (map):
234         (some):
235         (fill):
236         (find):
237         (findIndex):
238         (includes):
239         (sort):
240         (globalPrivate.concatSlowPath):
241         (copyWithin):
242         * builtins/DatePrototype.js:
243         (toLocaleString.toDateTimeOptionsAnyAll):
244         (toLocaleString):
245         (toLocaleDateString.toDateTimeOptionsDateDate):
246         (toLocaleDateString):
247         (toLocaleTimeString.toDateTimeOptionsTimeTime):
248         (toLocaleTimeString):
249         * builtins/GlobalOperations.js:
250         (globalPrivate.copyDataProperties):
251         (globalPrivate.copyDataPropertiesNoExclusions):
252         * builtins/ObjectConstructor.js:
253         (entries):
254         * builtins/StringConstructor.js:
255         (raw):
256         * builtins/TypedArrayConstructor.js:
257         (from):
258         * builtins/TypedArrayPrototype.js:
259         (map):
260         (filter):
261         * bytecode/BytecodeDumper.cpp:
262         (JSC::BytecodeDumper<Block>::dumpBytecode):
263         * bytecode/BytecodeIntrinsicRegistry.h:
264         * bytecode/BytecodeList.json:
265         * bytecode/BytecodeUseDef.h:
266         (JSC::computeUsesForBytecodeOffset):
267         (JSC::computeDefsForBytecodeOffset):
268         * bytecode/CodeBlock.cpp:
269         (JSC::CodeBlock::finishCreation):
270         * bytecompiler/BytecodeGenerator.cpp:
271         (JSC::BytecodeGenerator::emitToObject):
272         * bytecompiler/BytecodeGenerator.h:
273         * bytecompiler/NodesCodegen.cpp:
274         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toObject):
275         * dfg/DFGAbstractInterpreterInlines.h:
276         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
277         * dfg/DFGByteCodeParser.cpp:
278         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
279         (JSC::DFG::ByteCodeParser::parseBlock):
280         * dfg/DFGCapabilities.cpp:
281         (JSC::DFG::capabilityLevel):
282         * dfg/DFGClobberize.h:
283         (JSC::DFG::clobberize):
284         * dfg/DFGDoesGC.cpp:
285         (JSC::DFG::doesGC):
286         * dfg/DFGFixupPhase.cpp:
287         (JSC::DFG::FixupPhase::fixupNode):
288         (JSC::DFG::FixupPhase::fixupToObject):
289         (JSC::DFG::FixupPhase::fixupCallObjectConstructor):
290         * dfg/DFGNode.h:
291         (JSC::DFG::Node::convertToCallObjectConstructor):
292         (JSC::DFG::Node::convertToNewStringObject):
293         (JSC::DFG::Node::convertToNewObject):
294         (JSC::DFG::Node::hasIdentifier):
295         (JSC::DFG::Node::hasHeapPrediction):
296         (JSC::DFG::Node::hasCellOperand):
297         * dfg/DFGNodeType.h:
298         * dfg/DFGOperations.cpp:
299         * dfg/DFGOperations.h:
300         * dfg/DFGPredictionPropagationPhase.cpp:
301         * dfg/DFGSafeToExecute.h:
302         (JSC::DFG::safeToExecute):
303         * dfg/DFGSpeculativeJIT.cpp:
304         (JSC::DFG::SpeculativeJIT::compileToObjectOrCallObjectConstructor):
305         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): Deleted.
306         * dfg/DFGSpeculativeJIT.h:
307         (JSC::DFG::SpeculativeJIT::callOperation):
308         * dfg/DFGSpeculativeJIT32_64.cpp:
309         (JSC::DFG::SpeculativeJIT::compile):
310         * dfg/DFGSpeculativeJIT64.cpp:
311         (JSC::DFG::SpeculativeJIT::compile):
312         * ftl/FTLCapabilities.cpp:
313         (JSC::FTL::canCompile):
314         * ftl/FTLLowerDFGToB3.cpp:
315         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
316         (JSC::FTL::DFG::LowerDFGToB3::compileToObjectOrCallObjectConstructor):
317         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): Deleted.
318         * jit/JIT.cpp:
319         (JSC::JIT::privateCompileMainPass):
320         (JSC::JIT::privateCompileSlowCases):
321         * jit/JIT.h:
322         * jit/JITOpcodes.cpp:
323         (JSC::JIT::emit_op_to_object):
324         (JSC::JIT::emitSlow_op_to_object):
325         * jit/JITOpcodes32_64.cpp:
326         (JSC::JIT::emit_op_to_object):
327         (JSC::JIT::emitSlow_op_to_object):
328         * jit/JITOperations.cpp:
329         * jit/JITOperations.h:
330         * llint/LowLevelInterpreter32_64.asm:
331         * llint/LowLevelInterpreter64.asm:
332         * runtime/CommonSlowPaths.cpp:
333         (JSC::SLOW_PATH_DECL):
334         * runtime/CommonSlowPaths.h:
335
336 2017-11-01  Fujii Hironori  <Hironori.Fujii@sony.com>
337
338         Use LazyNeverDestroyed instead of DEFINE_GLOBAL
339         https://bugs.webkit.org/show_bug.cgi?id=174979
340
341         Reviewed by Yusuke Suzuki.
342
343         * config.h: Removed definitions of SKIP_STATIC_CONSTRUCTORS_ON_MSVC and SKIP_STATIC_CONSTRUCTORS_ON_GCC.
344
345 2017-10-27  Yusuke Suzuki  <utatane.tea@gmail.com>
346
347         [DFG][FTL] Introduce StringSlice
348         https://bugs.webkit.org/show_bug.cgi?id=178934
349
350         Reviewed by Saam Barati.
351
352         String.prototype.slice is one of the most frequently called function in ARES-6/Babylon.
353         This patch introduces StringSlice DFG node to optimize it in DFG and FTL.
354
355         This patch's StringSlice node optimizes the following things.
356
357         1. Empty string generation is accelerated. It is fully executed inline.
358         2. One char string generation is accelerated. `< 0x100` character is supported right now.
359         It is the same to charAt acceleration.
360         3. We calculate start and end index in DFG/FTL with Int32Use information and call optimized
361         operation.
362
363         We do not inline (3)'s operation right now since we do not have a way to call bmalloc allocation from DFG / FTL.
364         And we do not optimize String.prototype.{substring,substr} right now. But they can be optimized based on this change
365         in subsequent changes.
366
367         This patch improves ARES-6/Babylon performance by 3% in steady state.
368
369         Baseline:
370             Running... Babylon ( 1  to go)
371             firstIteration:     50.05 +- 13.68 ms
372             averageWorstCase:   16.80 +- 1.27 ms
373             steadyState:        7.53 +- 0.22 ms
374
375         Patched:
376             Running... Babylon ( 1  to go)
377             firstIteration:     50.91 +- 13.41 ms
378             averageWorstCase:   16.12 +- 0.99 ms
379             steadyState:        7.30 +- 0.29 ms
380
381         * dfg/DFGAbstractInterpreterInlines.h:
382         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
383         * dfg/DFGBackwardsPropagationPhase.cpp:
384         (JSC::DFG::BackwardsPropagationPhase::propagate):
385         * dfg/DFGByteCodeParser.cpp:
386         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
387         * dfg/DFGClobberize.h:
388         (JSC::DFG::clobberize):
389         * dfg/DFGDoesGC.cpp:
390         (JSC::DFG::doesGC):
391         * dfg/DFGFixupPhase.cpp:
392         (JSC::DFG::FixupPhase::fixupNode):
393         * dfg/DFGNodeType.h:
394         * dfg/DFGOperations.cpp:
395         * dfg/DFGOperations.h:
396         * dfg/DFGPredictionPropagationPhase.cpp:
397         * dfg/DFGSafeToExecute.h:
398         (JSC::DFG::safeToExecute):
399         * dfg/DFGSpeculativeJIT.cpp:
400         (JSC::DFG::SpeculativeJIT::compileStringSlice):
401         (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
402         (JSC::DFG::SpeculativeJIT::compileArraySlice):
403         (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
404         * dfg/DFGSpeculativeJIT.h:
405         (JSC::DFG::SpeculativeJIT::callOperation):
406         * dfg/DFGSpeculativeJIT32_64.cpp:
407         (JSC::DFG::SpeculativeJIT::compile):
408         * dfg/DFGSpeculativeJIT64.cpp:
409         (JSC::DFG::SpeculativeJIT::compile):
410         * ftl/FTLCapabilities.cpp:
411         (JSC::FTL::canCompile):
412         * ftl/FTLLowerDFGToB3.cpp:
413         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
414         (JSC::FTL::DFG::LowerDFGToB3::populateSliceRange):
415         (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
416         (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
417         * jit/JITOperations.h:
418         * runtime/Intrinsic.cpp:
419         (JSC::intrinsicName):
420         * runtime/Intrinsic.h:
421         * runtime/StringPrototype.cpp:
422         (JSC::StringPrototype::finishCreation):
423
424 2017-10-31  JF Bastien  <jfbastien@apple.com>
425
426         WebAssembly: Wasm::IndexOrName has a raw pointer to Name
427         https://bugs.webkit.org/show_bug.cgi?id=176644
428
429         Reviewed by Michael Saboff.
430
431         IndexOrName now keeps a RefPtr to its original NameSection, which
432         holds the Name (or references nullptr if Index). Holding onto the
433         entire section seems like the better thing to do, since backtraces
434         probably contain multiple names from the same Module.
435
436         * JavaScriptCore.xcodeproj/project.pbxproj:
437         * interpreter/Interpreter.cpp:
438         (JSC::GetStackTraceFunctor::operator() const):
439         * interpreter/StackVisitor.h: Frame is no longer POD because of the
440         RefPtr.
441         * runtime/StackFrame.cpp:
442         (JSC::StackFrame::StackFrame):
443         * runtime/StackFrame.h: Drop the union, size is now 40 bytes.
444         (JSC::StackFrame::StackFrame): Deleted. Initialized in class instead.
445         (JSC::StackFrame::wasm): Deleted. Make it a ctor instead.
446         * wasm/WasmBBQPlanInlines.h:
447         (JSC::Wasm::BBQPlan::initializeCallees):
448         * wasm/WasmCallee.cpp:
449         (JSC::Wasm::Callee::Callee):
450         * wasm/WasmCallee.h:
451         (JSC::Wasm::Callee::create):
452         * wasm/WasmFormat.h: Move NameSection to its own header.
453         (JSC::Wasm::isValidNameType):
454         (JSC::Wasm::NameSection::get): Deleted.
455         * wasm/WasmIndexOrName.cpp:
456         (JSC::Wasm::IndexOrName::IndexOrName):
457         (JSC::Wasm::makeString):
458         * wasm/WasmIndexOrName.h:
459         (JSC::Wasm::IndexOrName::IndexOrName):
460         (JSC::Wasm::IndexOrName::isEmpty const):
461         (JSC::Wasm::IndexOrName::isIndex const):
462         * wasm/WasmModuleInformation.cpp:
463         (JSC::Wasm::ModuleInformation::ModuleInformation):
464         * wasm/WasmModuleInformation.h:
465         (JSC::Wasm::ModuleInformation::ModuleInformation): Deleted.
466         * wasm/WasmNameSection.h:
467         (JSC::Wasm::NameSection::get):
468         (JSC::Wasm::NameSection::create): Deleted.
469         * wasm/WasmNameSectionParser.cpp:
470         (JSC::Wasm::NameSectionParser::parse):
471         * wasm/WasmNameSectionParser.h:
472         * wasm/WasmOMGPlan.cpp:
473         (JSC::Wasm::OMGPlan::work):
474
475 2017-10-31  Tim Horton  <timothy_horton@apple.com>
476
477         Clean up some drag and drop feature flags
478         https://bugs.webkit.org/show_bug.cgi?id=179082
479
480         Reviewed by Simon Fraser.
481
482         * Configurations/FeatureDefines.xcconfig:
483
484 2017-10-31  Commit Queue  <commit-queue@webkit.org>
485
486         Unreviewed, rolling out r224243, r224246, and r224248.
487         https://bugs.webkit.org/show_bug.cgi?id=179083
488
489         The patch and fix broke the Windows build. (Requested by
490         mlewis13 on #webkit).
491
492         Reverted changesets:
493
494         "StructureStubInfo should have GPRReg members not int8_ts"
495         https://bugs.webkit.org/show_bug.cgi?id=179071
496         https://trac.webkit.org/changeset/224243
497
498         "Make all register enums be backed by uint8_t."
499         https://bugs.webkit.org/show_bug.cgi?id=179074
500         https://trac.webkit.org/changeset/224246
501
502         "Unreviewed, windows build fix."
503         https://trac.webkit.org/changeset/224248
504
505 2017-10-31  Tim Horton  <timothy_horton@apple.com>
506
507         Fix up some content filtering feature flags
508         https://bugs.webkit.org/show_bug.cgi?id=179079
509
510         Reviewed by Simon Fraser.
511
512         * Configurations/FeatureDefines.xcconfig:
513
514 2017-10-31  Keith Miller  <keith_miller@apple.com>
515
516         Unreviewed, windows build fix.
517
518         * assembler/X86Assembler.h:
519         (JSC::X86Assembler::numberOfRegisters):
520         (JSC::X86Assembler::numberOfSPRegisters):
521         (JSC::X86Assembler::numberOfFPRegisters):
522
523 2017-10-31  Keith Miller  <keith_miller@apple.com>
524
525         Make all register enums be backed by uint8_t.
526         https://bugs.webkit.org/show_bug.cgi?id=179074
527
528         Reviewed by Mark Lam.
529
530         * assembler/ARM64Assembler.h:
531         * assembler/ARMAssembler.h:
532         * assembler/ARMv7Assembler.h:
533         * assembler/MIPSAssembler.h:
534         * assembler/MacroAssembler.h:
535         * assembler/X86Assembler.h:
536
537 2017-10-31  Keith Miller  <keith_miller@apple.com>
538
539         StructureStubInfo should have GPRReg members not int8_ts
540         https://bugs.webkit.org/show_bug.cgi?id=179071
541
542         Reviewed by Michael Saboff.
543
544         This patch makes the various RegisterID enums be backed by
545         uint8_t. This means that we can remove the old int8_t members in
546         StructureStubInfo and replace them with the correct enum types.
547
548         Also, this fixes an indentation issue in ARMv7Assembler.h.
549
550         * assembler/ARM64Assembler.h:
551         * assembler/ARMAssembler.h:
552         * assembler/ARMv7Assembler.h:
553         (JSC::ARMRegisters::asSingle):
554         (JSC::ARMRegisters::asDouble):
555         * assembler/MIPSAssembler.h:
556         * assembler/X86Assembler.h:
557         * bytecode/InlineAccess.cpp:
558         (JSC::InlineAccess::generateSelfPropertyAccess):
559         (JSC::getScratchRegister):
560         * bytecode/PolymorphicAccess.cpp:
561         (JSC::PolymorphicAccess::regenerate):
562         * bytecode/StructureStubInfo.h:
563         (JSC::StructureStubInfo::valueRegs const):
564         * dfg/DFGSpeculativeJIT.cpp:
565         (JSC::DFG::SpeculativeJIT::compileIn):
566         * ftl/FTLLowerDFGToB3.cpp:
567         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
568         * jit/JITInlineCacheGenerator.cpp:
569         (JSC::JITByIdGenerator::JITByIdGenerator):
570         (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
571
572 2017-10-31  Devin Rousso  <webkit@devinrousso.com>
573
574         Web Inspector: make ScriptCallStack::maxCallStackSizeToCapture the default value when capturing backtraces
575         https://bugs.webkit.org/show_bug.cgi?id=179048
576
577         Reviewed by Mark Lam.
578
579         * inspector/ScriptCallStackFactory.h:
580         * inspector/ScriptCallStackFactory.cpp:
581         (createScriptCallStack):
582         (createScriptCallStackForConsole):
583         (createScriptCallStackFromException):
584
585         * inspector/ConsoleMessage.cpp:
586         (Inspector::ConsoleMessage::autogenerateMetadata):
587         * inspector/JSGlobalObjectInspectorController.cpp:
588         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
589         * inspector/agents/InspectorConsoleAgent.cpp:
590         (Inspector::InspectorConsoleAgent::count):
591         * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
592         (Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):
593
594 2017-10-31  Carlos Garcia Campos  <cgarcia@igalia.com>
595
596         Unreviewed. Fix GTK+ make distcheck.
597
598         Ensure DERIVED_SOURCES_JAVASCRIPTCORE_DIR/yarr is created before scripts generating files there are run.
599
600         * CMakeLists.txt:
601
602 2017-10-30  Saam Barati  <sbarati@apple.com>
603
604         We need a storeStoreFence before storing to the instruction stream's live variable catch data
605         https://bugs.webkit.org/show_bug.cgi?id=178649
606
607         Reviewed by Keith Miller.
608
609         * bytecode/CodeBlock.cpp:
610         (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
611
612 2017-10-30  Michael Catanzaro  <mcatanzaro@igalia.com>
613
614         [WPE] Fix build warnings
615         https://bugs.webkit.org/show_bug.cgi?id=178899
616
617         Reviewed by Carlos Alberto Lopez Perez.
618
619         * PlatformWPE.cmake:
620
621 2017-10-30  Zan Dobersek  <zdobersek@igalia.com>
622
623         [ARMv7] Fix initial start register support in YarrJIT
624         https://bugs.webkit.org/show_bug.cgi?id=178641
625
626         Reviewed by Saam Barati.
627
628         * yarr/YarrJIT.cpp: On ARMv7, use r8 as the initialStart register in the
629         YarrGenerator class. r6 should be avoided since it's already used inside
630         MacroAssemblerARMv7 as addressTempRegister. r7 isn't picked because it
631         can be used as the frame pointer register when targetting ARM Thumb2.
632
633 2017-10-30  Zan Dobersek  <zdobersek@igalia.com>
634
635         [ARM64][Linux] Re-enable Gigacage
636         https://bugs.webkit.org/show_bug.cgi?id=178130
637
638         Reviewed by Michael Catanzaro.
639
640         Guard the current globaladdr opcode implementation for ARM64 with
641         OS(DARWIN) as it's only usable for Mach-O.
642
643         For OS(LINUX), ELF-supported :got: and :got_lo12: relocation specifiers
644         have to be used. The .loh directive can't be used as it's not supported
645         in GCC or the ld linker.
646
647         On every other OS target, a compilation error is thrown.
648
649         * offlineasm/arm64.rb:
650
651 2017-10-27  Devin Rousso  <webkit@devinrousso.com>
652
653         Web Inspector: Canvas Tab: no way to see backtrace of where a canvas context was created
654         https://bugs.webkit.org/show_bug.cgi?id=178799
655         <rdar://problem/35175805>
656
657         Reviewed by Brian Burg.
658
659         * inspector/protocol/Canvas.json:
660         Add optional `backtrace` to Canvas type that is an array of Console.CallFrame.
661
662 2017-10-27  Yusuke Suzuki  <utatane.tea@gmail.com>
663
664         [JSC] Tweak ES6 generator function to allow inlining
665         https://bugs.webkit.org/show_bug.cgi?id=178935
666
667         Reviewed by Saam Barati.
668
669         We optimize builtins' generator helper functions to allow them inlined in the caller side.
670         This patch adjust the layer between @generatorResume, next(), throw(), and return() to allow
671         them inlined in DFG.
672
673                                        baseline                  patched
674
675         spread-generator.es6      301.2637+-11.1011    ^    260.5905+-14.2258       ^ definitely 1.1561x faster
676         generator.es6             269.6030+-13.2435    ^    148.8840+-6.7614        ^ definitely 1.8108x faster
677
678         * builtins/GeneratorPrototype.js:
679         (globalPrivate.generatorResume):
680         (next):
681         (return):
682         (throw):
683
684 2017-10-27  Saam Barati  <sbarati@apple.com>
685
686         Bytecode liveness should live on UnlinkedCodeBlock so it can be shared amongst CodeBlocks
687         https://bugs.webkit.org/show_bug.cgi?id=178949
688
689         Reviewed by Keith Miller.
690
691         This patch stores BytecodeLiveness on UnlinkedCodeBlock instead of CodeBlock
692         so that we don't need to recompute liveness for the same UnlinkedCodeBlock
693         more than once. To do this, this patch solidifies the invariant that CodeBlock
694         linking can't do anything that would change the result of liveness. For example,
695         it can't introduce new locals. This invariant was met my JSC before, because we
696         didn't do anything in bytecode linking that would change liveness. However, it is
697         now a correctness requirement that we don't do anything that would change the
698         result of running liveness. To support this change, I've refactored BytecodeGraph
699         to not be tied to a CodeBlockType*. Things that perform liveness will pass in
700         CodeBlockType* and the instruction stream as needed. This means that we may
701         compute liveness with one CodeBlock*'s instruction stream, and then perform
702         queries on that analysis with a different CodeBlock*'s instruction stream.
703
704         This seems to be a 2% JSBench progression.
705
706         * bytecode/BytecodeGeneratorification.cpp:
707         (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
708         (JSC::BytecodeGeneratorification::graph):
709         (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
710         (JSC::GeneratorLivenessAnalysis::run):
711         (JSC::BytecodeGeneratorification::run):
712         * bytecode/BytecodeGraph.h:
713         (JSC::BytecodeGraph::BytecodeGraph):
714         (JSC::BytecodeGraph::codeBlock const): Deleted.
715         (JSC::BytecodeGraph::instructions): Deleted.
716         (JSC::BytecodeGraph<Block>::BytecodeGraph): Deleted.
717         * bytecode/BytecodeLivenessAnalysis.cpp:
718         (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
719         (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
720         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
721         (JSC::BytecodeLivenessAnalysis::computeKills):
722         (JSC::BytecodeLivenessAnalysis::dumpResults):
723         (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): Deleted.
724         (JSC::BytecodeLivenessAnalysis::compute): Deleted.
725         * bytecode/BytecodeLivenessAnalysis.h:
726         * bytecode/BytecodeLivenessAnalysisInlines.h:
727         (JSC::BytecodeLivenessPropagation::stepOverInstruction):
728         (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset):
729         (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock):
730         (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset):
731         (JSC::BytecodeLivenessPropagation::runLivenessFixpoint):
732         * bytecode/BytecodeRewriter.cpp:
733         (JSC::BytecodeRewriter::applyModification):
734         (JSC::BytecodeRewriter::execute):
735         (JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
736         * bytecode/BytecodeRewriter.h:
737         (JSC::BytecodeRewriter::BytecodeRewriter):
738         (JSC::BytecodeRewriter::removeBytecode):
739         (JSC::BytecodeRewriter::graph):
740         * bytecode/CodeBlock.cpp:
741         (JSC::CodeBlock::finishCreation):
742         (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
743         (JSC::CodeBlock::validate):
744         (JSC::CodeBlock::livenessAnalysisSlow): Deleted.
745         * bytecode/CodeBlock.h:
746         (JSC::CodeBlock::livenessAnalysis):
747         * bytecode/UnlinkedCodeBlock.cpp:
748         (JSC::UnlinkedCodeBlock::applyModification):
749         (JSC::UnlinkedCodeBlock::livenessAnalysisSlow):
750         * bytecode/UnlinkedCodeBlock.h:
751         (JSC::UnlinkedCodeBlock::livenessAnalysis):
752         * dfg/DFGGraph.cpp:
753         (JSC::DFG::Graph::livenessFor):
754         (JSC::DFG::Graph::killsFor):
755         * dfg/DFGPlan.cpp:
756         (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
757         * jit/JIT.cpp:
758         (JSC::JIT::privateCompileMainPass):
759
760 2017-10-27  Keith Miller  <keith_miller@apple.com>
761
762         Add unified source list files and build scripts to Xcode project navigator
763         https://bugs.webkit.org/show_bug.cgi?id=178959
764
765         Reviewed by Andy Estes.
766
767         Also, Add some extra source files for so new .cpp/.mm files don't cause the build
768         to fail right away. We already do this in WebCore.
769
770         * JavaScriptCore.xcodeproj/project.pbxproj:
771         * PlatformMac.cmake:
772         * SourcesCocoa.txt: Renamed from Source/JavaScriptCore/SourcesMac.txt.
773
774 2017-10-27  JF Bastien  <jfbastien@apple.com>
775
776         WebAssembly: update arbitrary limits to what browsers use
777         https://bugs.webkit.org/show_bug.cgi?id=178946
778         <rdar://problem/34257412>
779         <rdar://problem/34501154>
780
781         Reviewed by Saam Barati.
782
783         https://github.com/WebAssembly/design/issues/1138 discusses the
784         arbitrary function size limit, which it turns out Chrome and
785         Firefox didn't enforce. We didn't use it because it was
786         ridiculously low and actual programs ran into that limit (bummer
787         for Edge which just shipped it...). Now that we agree on a high
788         arbitrary program limit, let's update it! While I'm doing this
789         there are a few other spots that I polished to use Checked or
790         better check limits overall.
791
792         * wasm/WasmB3IRGenerator.cpp:
793         (JSC::Wasm::B3IRGenerator::addLocal):
794         * wasm/WasmFormat.cpp:
795         (JSC::Wasm::Segment::create):
796         * wasm/WasmFunctionParser.h:
797         (JSC::Wasm::FunctionParser<Context>::parse):
798         * wasm/WasmInstance.cpp:
799         * wasm/WasmLimits.h:
800         * wasm/WasmModuleParser.cpp:
801         (JSC::Wasm::ModuleParser::parseGlobal):
802         (JSC::Wasm::ModuleParser::parseCode):
803         (JSC::Wasm::ModuleParser::parseData):
804         * wasm/WasmSignature.h:
805         (JSC::Wasm::Signature::allocatedSize):
806         * wasm/WasmTable.cpp:
807         (JSC::Wasm::Table::Table):
808         * wasm/js/JSWebAssemblyTable.cpp:
809         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
810         (JSC::JSWebAssemblyTable::grow):
811
812 2017-10-26  Michael Saboff  <msaboff@apple.com>
813
814         REGRESSION(r222601): We fail to properly backtrack into a sub pattern of a parenthesis with non-zero minimum
815         https://bugs.webkit.org/show_bug.cgi?id=178890
816
817         Reviewed by Keith Miller.
818
819         We need to let a contained subpattern backtrack before declaring that the containing
820         parenthesis doesn't match.  If the subpattern fails to match backtracking, then we
821         can check to see if we trying to backtrack below the minimum match count.
822         
823         * yarr/YarrInterpreter.cpp:
824         (JSC::Yarr::Interpreter::backtrackParentheses):
825
826 2017-10-26  Mark Lam  <mark.lam@apple.com>
827
828         JSRopeString::RopeBuilder::append() should check for overflows.
829         https://bugs.webkit.org/show_bug.cgi?id=178385
830         <rdar://problem/35027468>
831
832         Reviewed by Saam Barati.
833
834         1. Made RopeString check for overflow like the Checked class does.
835         2. Added a missing overflow check in objectProtoFuncToString().
836
837         * runtime/JSString.cpp:
838         (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
839         (JSC::JSRopeString::RopeBuilder::expand): Deleted.
840         * runtime/JSString.h:
841         * runtime/ObjectPrototype.cpp:
842         (JSC::objectProtoFuncToString):
843         * runtime/Operations.h:
844         (JSC::jsStringFromRegisterArray):
845         (JSC::jsStringFromArguments):
846
847 2017-10-26  JF Bastien  <jfbastien@apple.com>
848
849         WebAssembly: no VM / JS version of our implementation
850         https://bugs.webkit.org/show_bug.cgi?id=177472
851
852         Reviewed by Michael Saboff.
853
854         This patch removes all appearances of "JS" and "VM" in the wasm
855         directory. These now only appear in the wasm/js directory, which
856         is only used in a JS embedding of wasm. It should therefore now be
857         possible to create non-JS embeddings of wasm through JSC, though
858         it'll still require:
859
860           - Mild codegen for wasm<->embedder calls;
861           - A strategy for trap handling (no need for full unwind! Could kill).
862           - Creation of the Wasm::* objects.
863           - Calling convention handling to call the embedder.
864           - Handling of multiple embedders (see #177475, this is optional).
865
866         Most of the patch consists in renaming JSWebAssemblyInstance to
867         Instance, and removing temporary copies which I'd added to make
868         this specific patch very simple.
869
870         * interpreter/CallFrame.cpp:
871         (JSC::CallFrame::wasmAwareLexicalGlobalObject): this one place
872         which needs to know about who "owns" the Wasm::Instance. In a JS
873         embedding it's the JSWebAssemblyInstance.
874         * wasm/WasmB3IRGenerator.cpp:
875         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
876         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
877         (JSC::Wasm::B3IRGenerator::addGrowMemory):
878         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
879         (JSC::Wasm::B3IRGenerator::getGlobal):
880         (JSC::Wasm::B3IRGenerator::setGlobal):
881         (JSC::Wasm::B3IRGenerator::addCall):
882         (JSC::Wasm::B3IRGenerator::addCallIndirect):
883         * wasm/WasmBinding.cpp:
884         (JSC::Wasm::wasmToWasm):
885         * wasm/WasmContext.cpp:
886         (JSC::Wasm::Context::load const):
887         (JSC::Wasm::Context::store):
888         * wasm/WasmContext.h:
889         * wasm/WasmEmbedder.h:
890         * wasm/WasmInstance.cpp:
891         (JSC::Wasm::Instance::Instance):
892         (JSC::Wasm::Instance::create):
893         (JSC::Wasm::Instance::extraMemoryAllocated const):
894         * wasm/WasmInstance.h: add an "owner", the Wasm::Context, move the
895         "tail" import information from JSWebAssemblyInstance over to here.
896         (JSC::Wasm::Instance::finalizeCreation):
897         (JSC::Wasm::Instance::owner const):
898         (JSC::Wasm::Instance::offsetOfOwner):
899         (JSC::Wasm::Instance::context const):
900         (JSC::Wasm::Instance::setMemory):
901         (JSC::Wasm::Instance::setTable):
902         (JSC::Wasm::Instance::offsetOfMemory):
903         (JSC::Wasm::Instance::offsetOfGlobals):
904         (JSC::Wasm::Instance::offsetOfTable):
905         (JSC::Wasm::Instance::offsetOfTail):
906         (JSC::Wasm::Instance::numImportFunctions const):
907         (JSC::Wasm::Instance::importFunctionInfo):
908         (JSC::Wasm::Instance::offsetOfTargetInstance):
909         (JSC::Wasm::Instance::offsetOfWasmEntrypoint):
910         (JSC::Wasm::Instance::offsetOfWasmToEmbedderStubExecutableAddress):
911         (JSC::Wasm::Instance::offsetOfImportFunction):
912         (JSC::Wasm::Instance::importFunction):
913         (JSC::Wasm::Instance::allocationSize):
914         (JSC::Wasm::Instance::create): Deleted.
915         * wasm/WasmOMGPlan.cpp:
916         (JSC::Wasm::OMGPlan::runForIndex):
917         * wasm/WasmOMGPlan.h:
918         * wasm/WasmTable.cpp:
919         (JSC::Wasm::Table::Table):
920         (JSC::Wasm::Table::setFunction):
921         * wasm/WasmTable.h:
922         * wasm/WasmThunks.cpp:
923         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
924         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
925         * wasm/js/JSToWasm.cpp:
926         (JSC::Wasm::createJSToWasmWrapper):
927         * wasm/js/JSWebAssemblyInstance.cpp: delete code that is now on Wasm::Instance
928         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): The embedder
929         decides what the import function is. Here we must properly
930         placement-new it to what we've elected (and initialize it later).
931         (JSC::JSWebAssemblyInstance::visitChildren):
932         (JSC::JSWebAssemblyInstance::finalizeCreation):
933         (JSC::JSWebAssemblyInstance::create):
934         * wasm/js/JSWebAssemblyInstance.h: delete code that is now on Wasm::Instance
935         (JSC::JSWebAssemblyInstance::instance):
936         (JSC::JSWebAssemblyInstance::moduleNamespaceObject):
937         (JSC::JSWebAssemblyInstance::setMemory):
938         (JSC::JSWebAssemblyInstance::table):
939         (JSC::JSWebAssemblyInstance::setTable):
940         (JSC::JSWebAssemblyInstance::offsetOfInstance):
941         (JSC::JSWebAssemblyInstance::offsetOfCallee):
942         (JSC::JSWebAssemblyInstance::context const): Deleted.
943         (JSC::JSWebAssemblyInstance::offsetOfTail): Deleted.
944         (): Deleted.
945         (JSC::JSWebAssemblyInstance::importFunctionInfo): Deleted.
946         (JSC::JSWebAssemblyInstance::offsetOfTargetInstance): Deleted.
947         (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint): Deleted.
948         (JSC::JSWebAssemblyInstance::offsetOfWasmToEmbedderStubExecutableAddress): Deleted.
949         (JSC::JSWebAssemblyInstance::offsetOfImportFunction): Deleted.
950         (JSC::JSWebAssemblyInstance::importFunction): Deleted.
951         (JSC::JSWebAssemblyInstance::internalMemory): Deleted.
952         (JSC::JSWebAssemblyInstance::wasmCodeBlock const): Deleted.
953         (JSC::JSWebAssemblyInstance::offsetOfWasmTable): Deleted.
954         (JSC::JSWebAssemblyInstance::offsetOfGlobals): Deleted.
955         (JSC::JSWebAssemblyInstance::offsetOfCodeBlock): Deleted.
956         (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock): Deleted.
957         (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit): Deleted.
958         (JSC::JSWebAssemblyInstance::offsetOfWasmMemory): Deleted.
959         (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer): Deleted.
960         (JSC::JSWebAssemblyInstance::cachedStackLimit const): Deleted.
961         (JSC::JSWebAssemblyInstance::setCachedStackLimit): Deleted.
962         (JSC::JSWebAssemblyInstance::wasmMemory): Deleted.
963         (JSC::JSWebAssemblyInstance::wasmModule): Deleted.
964         (JSC::JSWebAssemblyInstance::allocationSize): Deleted.
965         * wasm/js/JSWebAssemblyTable.cpp:
966         (JSC::JSWebAssemblyTable::setFunction):
967         * wasm/js/WasmToJS.cpp: One extra indirection to find the JSWebAssemblyInstance.
968         (JSC::Wasm::materializeImportJSCell):
969         (JSC::Wasm::handleBadI64Use):
970         (JSC::Wasm::wasmToJS):
971         (JSC::Wasm::wasmToJSException):
972         * wasm/js/WasmToJS.h:
973         * wasm/js/WebAssemblyFunction.cpp:
974         (JSC::callWebAssemblyFunction):
975         * wasm/js/WebAssemblyInstanceConstructor.cpp:
976         (JSC::constructJSWebAssemblyInstance):
977         * wasm/js/WebAssemblyModuleRecord.cpp:
978         (JSC::WebAssemblyModuleRecord::link):
979         (JSC::WebAssemblyModuleRecord::evaluate):
980         * wasm/js/WebAssemblyPrototype.cpp:
981         (JSC::instantiate):
982         * wasm/js/WebAssemblyWrapperFunction.cpp:
983         (JSC::WebAssemblyWrapperFunction::create):
984
985 2017-10-25  Devin Rousso  <webkit@devinrousso.com>
986
987         Web Inspector: provide a way to enable/disable event listeners
988         https://bugs.webkit.org/show_bug.cgi?id=177451
989         <rdar://problem/34994925>
990
991         Reviewed by Joseph Pecoraro.
992
993         * inspector/protocol/DOM.json:
994         Add `setEventListenerDisabled` command that enables/disables a specific event listener
995         during event dispatch. When a disabled event listener is fired, the listener's callback will
996         not be called.
997
998 2017-10-25  Commit Queue  <commit-queue@webkit.org>
999
1000         Unreviewed, rolling out r223691 and r223729.
1001         https://bugs.webkit.org/show_bug.cgi?id=178834
1002
1003         Broke Speedometer 2 React-Redux-TodoMVC test case (Requested
1004         by rniwa on #webkit).
1005
1006         Reverted changesets:
1007
1008         "Turn recursive tail calls into loops"
1009         https://bugs.webkit.org/show_bug.cgi?id=176601
1010         https://trac.webkit.org/changeset/223691
1011
1012         "REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning:
1013         comparison is always false due to limited range of data type
1014         [-Wtype-limits]"
1015         https://bugs.webkit.org/show_bug.cgi?id=178543
1016         https://trac.webkit.org/changeset/223729
1017
1018 2017-10-25  Michael Saboff  <msaboff@apple.com>
1019
1020         REGRESSION(r223937): Use of -fobjc-weak causes build failures with older compilers
1021         https://bugs.webkit.org/show_bug.cgi?id=178825
1022
1023         Reviewed by Mark Lam.
1024
1025         Enable ARC for ARM64_32.  This eliminate the need for setting CLANG_ENABLE_OBJC_WEAK.
1026
1027         * Configurations/ToolExecutable.xcconfig:
1028
1029 2017-10-25  Keith Miller  <keith_miller@apple.com>
1030
1031         Fix implicit cast of enum, which seems to break the windows build of unified sources.
1032         https://bugs.webkit.org/show_bug.cgi?id=178822
1033
1034         Reviewed by Saam Barati.
1035
1036         * bytecode/DFGExitProfile.h:
1037         (JSC::DFG::FrequentExitSite::hash const):
1038
1039 2017-10-24  Michael Saboff  <msaboff@apple.com>
1040
1041         Allow OjbC Weak References when building TestAPI
1042         https://bugs.webkit.org/show_bug.cgi?id=178748
1043
1044         Reviewed by Dan Bernstein.
1045
1046         Set TestAPI build flag Weak References in Manual Retain Release to true.
1047
1048         * JavaScriptCore.xcodeproj/project.pbxproj: Reverted.
1049         * Configurations/ToolExecutable.xcconfig: Changed the flag here instead.
1050
1051 2017-10-24  Eric Carlson  <eric.carlson@apple.com>
1052
1053         Web Inspector: Enable WebKit logging configuration and display
1054         https://bugs.webkit.org/show_bug.cgi?id=177027
1055         <rdar://problem/33964767>
1056
1057         Reviewed by Joseph Pecoraro.
1058
1059         * inspector/ConsoleMessage.cpp:
1060         (Inspector::messageSourceValue): Inspector::Protocol::Console::ConsoleMessage -> 
1061             Inspector::Protocol::Console::ChannelSource.
1062         * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
1063         (Inspector::JSGlobalObjectConsoleAgent::getLoggingChannels): There are no logging channels
1064             specific to a JSContext yet, so return an empty channel array.
1065         (Inspector::JSGlobalObjectConsoleAgent::setLoggingChannelLevel): No channels, return an error.
1066         * inspector/agents/JSGlobalObjectConsoleAgent.h:
1067
1068         * inspector/protocol/Console.json: Add ChannelSource, ChannelLevel, and Channel. Add getLoggingChannels
1069             and setLoggingChannelLevel.
1070
1071         * inspector/scripts/codegen/generator.py: Special case "webrtc"-> "WebRTC".
1072         * inspector/scripts/tests/generic/expected/enum-values.json-result:
1073         * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
1074         * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
1075         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
1076         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
1077
1078         * runtime/ConsoleTypes.h: Add Media and WebRTC.
1079
1080 2017-10-24  Michael Saboff  <msaboff@apple.com>
1081
1082         Allow OjbC Weak References when building TestAPI
1083         https://bugs.webkit.org/show_bug.cgi?id=178748
1084
1085         Reviewed by Saam Barati.
1086
1087         Set TestAPI build flag Weak References in Manual Retain Release to true.
1088
1089         * JavaScriptCore.xcodeproj/project.pbxproj:
1090
1091 2017-10-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1092
1093         [FTL] Support NewStringObject
1094         https://bugs.webkit.org/show_bug.cgi?id=178737
1095
1096         Reviewed by Saam Barati.
1097
1098         FTL should support NewStringObject and encourage use of NewStringObject in DFG pipeline.
1099         After this change, we can convert `CallObjectConstructor(String)` to `NewStringObject(String)`.
1100
1101         * ftl/FTLAbstractHeapRepository.h:
1102         * ftl/FTLCapabilities.cpp:
1103         (JSC::FTL::canCompile):
1104         * ftl/FTLLowerDFGToB3.cpp:
1105         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1106         (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
1107
1108 2017-10-24  Guillaume Emont  <guijemont@igalia.com>
1109
1110         [mips] fix offsets of branches that have to go over a jump
1111         https://bugs.webkit.org/show_bug.cgi?id=153464
1112
1113         The jump() function creates 8 instructions, but the offsets of branches
1114         meant to go over them only account for 6. In most cases, this is not an
1115         issue as the last two instructions of jump() would be nops, but in the
1116         rarer case where the jump destination is in a different 256 MB segment,
1117         MIPSAssembler::linkWithOffset() will rewrite the code in a way in which
1118         the last 4 instructions would be a 2 instruction load (lui/ori) into
1119         $t9, a "j $t9" and then a nop. The wrong offset will mean that the
1120         previous branches meant to go over the whole jump will branch to the
1121         "j $t9" instruction, which would jump to whatever is currently in $t9
1122         (since lui/ori would not be executed).
1123
1124         Reviewed by Michael Catanzaro.
1125
1126         * assembler/MacroAssemblerMIPS.h:
1127         (JSC::MacroAssemblerMIPS::branchAdd32):
1128         (JSC::MacroAssemblerMIPS::branchMul32):
1129         (JSC::MacroAssemblerMIPS::branchSub32):
1130         Fix the offsets of branches meant to go over code generated by jump().
1131
1132 2017-10-24  JF Bastien  <jfbastien@apple.com>
1133
1134         WebAssembly: NFC renames of things that aren't JS-specific
1135         https://bugs.webkit.org/show_bug.cgi?id=178738
1136
1137         Reviewed by Saam Barati.
1138
1139         * wasm/WasmB3IRGenerator.cpp:
1140         (JSC::Wasm::parseAndCompile):
1141         * wasm/WasmB3IRGenerator.h:
1142         * wasm/WasmBBQPlan.cpp:
1143         (JSC::Wasm::BBQPlan::complete):
1144         * wasm/WasmCodeBlock.cpp:
1145         (JSC::Wasm::CodeBlock::CodeBlock):
1146         * wasm/WasmCodeBlock.h:
1147         (JSC::Wasm::CodeBlock::embedderEntrypointCalleeFromFunctionIndexSpace):
1148         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
1149         * wasm/WasmFormat.h:
1150         * wasm/js/JSToWasm.cpp:
1151         (JSC::Wasm::createJSToWasmWrapper):
1152         * wasm/js/WebAssemblyModuleRecord.cpp:
1153         (JSC::WebAssemblyModuleRecord::link):
1154         (JSC::WebAssemblyModuleRecord::evaluate):
1155
1156 2017-10-24  Stephan Szabo  <stephan.szabo@sony.com>
1157
1158         [Win][JSCOnly] Make jsconly build testapi and dlls and copy dlls when running tests
1159         https://bugs.webkit.org/show_bug.cgi?id=177279
1160
1161         Reviewed by Yusuke Suzuki.
1162
1163         * shell/PlatformJSCOnly.cmake: Added.
1164
1165 2017-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1166
1167         [JSC] modules can be visited more than once when resolving bindings through "star" exports as long as the exportName is different each time
1168         https://bugs.webkit.org/show_bug.cgi?id=178308
1169
1170         Reviewed by Mark Lam.
1171
1172         With the change of the spec[1], we now do not need to remember star resolution modules.
1173         We reflect this change to our implementation. Since this change is covered by test262,
1174         this patch improves the score of test262.
1175
1176         We also add logging to ResolveExport to debug it easily.
1177
1178         [1]: https://github.com/tc39/ecma262/commit/a865e778ff0fc60e26e3e1c589635103710766a1
1179
1180         * runtime/AbstractModuleRecord.cpp:
1181         (JSC::AbstractModuleRecord::ResolveQuery::dump const):
1182         (JSC::AbstractModuleRecord::resolveExportImpl):
1183
1184 2017-10-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1185
1186         [JSC] Use emitDumbVirtualCall in 32bit JIT
1187         https://bugs.webkit.org/show_bug.cgi?id=178644
1188
1189         Reviewed by Mark Lam.
1190
1191         This patch aligns 32bit JIT op_call_eval slow case to 64bit version by using emitDumbVirtualCall.
1192
1193         * jit/JITCall32_64.cpp:
1194         (JSC::JIT::compileCallEvalSlowCase):
1195
1196 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1197
1198         [JSC] Drop ArityCheckData
1199         https://bugs.webkit.org/show_bug.cgi?id=178648
1200
1201         Reviewed by Mark Lam.
1202
1203         ArityCheckData is used to return a pair of `slotsToAdd` and `thunkToCall`.
1204         However, use of `thunkToCall` is removed in 64bit environment at r189575.
1205
1206         We remove `thunkToCall` and align 32bit implementation to 64bit implementation.
1207         Since we no longer need to have the above pair, we can remove ArityCheckData too.
1208
1209         * llint/LowLevelInterpreter32_64.asm:
1210         * llint/LowLevelInterpreter64.asm:
1211         * runtime/CommonSlowPaths.cpp:
1212         (JSC::SLOW_PATH_DECL):
1213         (JSC::setupArityCheckData): Deleted.
1214         * runtime/CommonSlowPaths.h:
1215         * runtime/VM.cpp:
1216         (JSC::VM::VM):
1217         * runtime/VM.h:
1218
1219 2017-10-23  Keith Miller  <keith_miller@apple.com>
1220
1221         Unreviewed, reland r223866
1222
1223         Didn't break the windows build...
1224
1225         Restored changeset:
1226
1227         "WebAssembly: topEntryFrame on Wasm::Instance"
1228         https://bugs.webkit.org/show_bug.cgi?id=178690
1229         https://trac.webkit.org/changeset/223866
1230
1231
1232 2017-10-23  Commit Queue  <commit-queue@webkit.org>
1233
1234         Unreviewed, rolling out r223866.
1235         https://bugs.webkit.org/show_bug.cgi?id=178699
1236
1237         Probably broke the windows build (Requested by keith_miller on
1238         #webkit).
1239
1240         Reverted changeset:
1241
1242         "WebAssembly: topEntryFrame on Wasm::Instance"
1243         https://bugs.webkit.org/show_bug.cgi?id=178690
1244         https://trac.webkit.org/changeset/223866
1245
1246 2017-10-23  Joseph Pecoraro  <pecoraro@apple.com>
1247
1248         Web Inspector: Remove unused Console.setMonitoringXHREnabled
1249         https://bugs.webkit.org/show_bug.cgi?id=178617
1250
1251         Reviewed by Sam Weinig.
1252
1253         * JavaScriptCore.xcodeproj/project.pbxproj:
1254         * Sources.txt:
1255         * inspector/agents/InspectorConsoleAgent.h:
1256         * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
1257         * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
1258         * inspector/protocol/Console.json:
1259         Removed files and method.
1260
1261         * inspector/JSGlobalObjectInspectorController.cpp:
1262         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1263         This can use the base ConsoleAgent now.
1264
1265 2017-10-23  JF Bastien  <jfbastien@apple.com>
1266
1267         WebAssembly: topEntryFrame on Wasm::Instance
1268         https://bugs.webkit.org/show_bug.cgi?id=178690
1269
1270         Reviewed by Saam Barati.
1271
1272         topEntryFrame is usually on VM, but for a no-VM WebAssembly we
1273         need to hold topEntryFrame elsewhere, and generated code cannot
1274         hard-code where topEntryFrame live. Do this at creation time of
1275         Wasm::Instance, and then generated code will just load from
1276         wherever Wasm::Instance was told topEntryFrame is. In a JavaScript
1277         embedding this is still from VM, so all of the unwinding machinery
1278         stays the same.
1279
1280         * dfg/DFGOSREntry.cpp:
1281         (JSC::DFG::prepareOSREntry):
1282         * dfg/DFGOSRExit.cpp:
1283         (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
1284         (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
1285         * ftl/FTLOSRExitCompiler.cpp:
1286         (JSC::FTL::compileStub):
1287         * interpreter/Interpreter.cpp:
1288         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
1289         * jit/AssemblyHelpers.cpp:
1290         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
1291         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
1292         * jit/AssemblyHelpers.h:
1293         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
1294         The default parameter was never non-defaulted from any of the
1295         callers. The new version calls the impl directly because it
1296         doesn't have VM and doesn't hard-code the address of
1297         topEntryFrame.
1298         * jit/RegisterSet.cpp:
1299         (JSC::RegisterSet::vmCalleeSaveRegisterOffsets): This was weird on
1300         VM because it's not really VM-specific.
1301         * jit/RegisterSet.h:
1302         * runtime/VM.cpp:
1303         (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted.
1304         * runtime/VM.h:
1305         (JSC::VM::getCTIStub):
1306         * wasm/WasmB3IRGenerator.cpp:
1307         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1308         (JSC::Wasm::B3IRGenerator::addCall):
1309         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1310         * wasm/WasmInstance.cpp:
1311         (JSC::Wasm::Instance::Instance):
1312         * wasm/WasmInstance.h: topEntryFramePointer will eventually live
1313         here for real. Right now it's mirrored in JSWebAssemblyInstance
1314         because that's the acting Context.
1315         (JSC::Wasm::Instance::create):
1316         (JSC::Wasm::Instance::offsetOfTopEntryFramePointer):
1317         * wasm/WasmThunks.cpp:
1318         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
1319         * wasm/js/JSWebAssemblyInstance.cpp:
1320         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
1321         * wasm/js/JSWebAssemblyInstance.h: Mirror Wasm::Instance temporarily.
1322         (JSC::JSWebAssemblyInstance::offsetOfCallee):
1323         (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer):
1324         (JSC::JSWebAssemblyInstance::offsetOfVM): Deleted.
1325         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1326         (JSC::constructJSWebAssemblyInstance):
1327         * wasm/js/WebAssemblyPrototype.cpp:
1328         (JSC::instantiate):
1329
1330 2017-10-23  Joseph Pecoraro  <pecoraro@apple.com>
1331
1332         Web Inspector: Please support HAR Export for network traffic
1333         https://bugs.webkit.org/show_bug.cgi?id=146692
1334         <rdar://problem/7463672>
1335
1336         Reviewed by Brian Burg.
1337
1338         * inspector/protocol/Network.json:
1339         Add a walltime to each send request.
1340
1341 2017-10-23  Matt Lewis  <jlewis3@apple.com>
1342
1343         Unreviewed, rolling out r223820.
1344
1345         This caused a build break on Windows.
1346
1347         Reverted changeset:
1348
1349         "Web Inspector: Remove unused Console.setMonitoringXHREnabled"
1350         https://bugs.webkit.org/show_bug.cgi?id=178617
1351         https://trac.webkit.org/changeset/223820
1352
1353 2017-10-23  Yusuke Suzuki  <utatane.tea@gmail.com>
1354
1355         [JSC] Use fastJoin in Array#toString
1356         https://bugs.webkit.org/show_bug.cgi?id=178062
1357
1358         Reviewed by Darin Adler.
1359
1360         Array#toString()'s fast path uses original join operation.
1361         But this should use fastJoin if possible.
1362         This patch adds a fast path using fastJoin in Array#toString.
1363         And we also extend fastJoin to perform fast joining for int32
1364         arrays.
1365
1366                                              baseline                  patched
1367
1368         double-array-to-string          126.6157+-5.8625     ^    103.7343+-4.4968        ^ definitely 1.2206x faster
1369         int32-array-to-string            64.7792+-2.6524           61.2390+-2.1749          might be 1.0578x faster
1370         contiguous-array-to-string       62.6224+-2.6388     ^     56.9899+-2.0852        ^ definitely 1.0988x faster
1371
1372
1373         * runtime/ArrayPrototype.cpp:
1374         (JSC::fastJoin):
1375         (JSC::arrayProtoFuncToString):
1376         (JSC::arrayProtoFuncToLocaleString):
1377         * runtime/JSStringJoiner.h:
1378         (JSC::JSStringJoiner::appendWithoutSideEffects):
1379         (JSC::JSStringJoiner::appendInt32):
1380         (JSC::JSStringJoiner::appendDouble):
1381
1382 2017-10-22  Zan Dobersek  <zdobersek@igalia.com>
1383
1384         [JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h
1385         https://bugs.webkit.org/show_bug.cgi?id=178452
1386
1387         Reviewed by Yusuke Suzuki.
1388
1389         * heap/RegisterState.h: Re-enable the custom RegisterState and
1390         ALLOCATE_AND_GET_REGISTER_STATE definitions on ARM64 Linux. These don't
1391         cause any crashes nowadays.
1392
1393 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1394
1395         [JSC][Baseline] Use linkAllSlowCasesForBytecodeOffset as much as possible to simplify slow cases handling
1396         https://bugs.webkit.org/show_bug.cgi?id=178647
1397
1398         Reviewed by Saam Barati.
1399
1400         There is much code counting slow cases in fast paths to call `linkSlowCase` carefully. This is really error-prone
1401         since the number of slow cases depends on values of instruction's metadata. We have linkAllSlowCasesForBytecodeOffset,
1402         which drains all slow cases for a specified bytecode offset. In typical cases like just calling a slow path function,
1403         this is enough. We use linkAllSlowCasesForBytecodeOffset as much as possible. It significantly simplifies the code.
1404
1405         * jit/JIT.h:
1406         (JSC::JIT::linkAllSlowCases):
1407         * jit/JITArithmetic.cpp:
1408         (JSC::JIT::emitSlow_op_unsigned):
1409         (JSC::JIT::emit_compareAndJump):
1410         (JSC::JIT::emit_compareAndJumpSlow):
1411         (JSC::JIT::emitSlow_op_inc):
1412         (JSC::JIT::emitSlow_op_dec):
1413         (JSC::JIT::emitSlow_op_mod):
1414         (JSC::JIT::emitSlow_op_negate):
1415         (JSC::JIT::emitSlow_op_bitand):
1416         (JSC::JIT::emitSlow_op_bitor):
1417         (JSC::JIT::emitSlow_op_bitxor):
1418         (JSC::JIT::emitSlow_op_lshift):
1419         (JSC::JIT::emitSlow_op_rshift):
1420         (JSC::JIT::emitSlow_op_urshift):
1421         (JSC::JIT::emitSlow_op_add):
1422         (JSC::JIT::emitSlow_op_div):
1423         (JSC::JIT::emitSlow_op_mul):
1424         (JSC::JIT::emitSlow_op_sub):
1425         * jit/JITArithmetic32_64.cpp:
1426         (JSC::JIT::emit_compareAndJumpSlow):
1427         (JSC::JIT::emitSlow_op_unsigned):
1428         (JSC::JIT::emitSlow_op_inc):
1429         (JSC::JIT::emitSlow_op_dec):
1430         (JSC::JIT::emitSlow_op_mod):
1431         * jit/JITCall.cpp:
1432         (JSC::JIT::compileCallEvalSlowCase):
1433         (JSC::JIT::compileOpCallSlowCase):
1434         * jit/JITCall32_64.cpp:
1435         (JSC::JIT::compileCallEvalSlowCase):
1436         (JSC::JIT::compileOpCallSlowCase):
1437         * jit/JITInlines.h:
1438         (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
1439         * jit/JITOpcodes.cpp:
1440         (JSC::JIT::emitSlow_op_new_object):
1441         (JSC::JIT::emitSlow_op_create_this):
1442         (JSC::JIT::emitSlow_op_check_tdz):
1443         (JSC::JIT::emitSlow_op_to_this):
1444         (JSC::JIT::emitSlow_op_to_primitive):
1445         (JSC::JIT::emitSlow_op_not):
1446         (JSC::JIT::emitSlow_op_eq):
1447         (JSC::JIT::emitSlow_op_neq):
1448         (JSC::JIT::emitSlow_op_stricteq):
1449         (JSC::JIT::emitSlow_op_nstricteq):
1450         (JSC::JIT::emitSlow_op_instanceof):
1451         (JSC::JIT::emitSlow_op_instanceof_custom):
1452         (JSC::JIT::emitSlow_op_to_number):
1453         (JSC::JIT::emitSlow_op_to_string):
1454         (JSC::JIT::emitSlow_op_loop_hint):
1455         (JSC::JIT::emitSlow_op_check_traps):
1456         (JSC::JIT::emitSlow_op_has_indexed_property):
1457         (JSC::JIT::emitSlow_op_get_direct_pname):
1458         (JSC::JIT::emitSlow_op_has_structure_property):
1459         * jit/JITOpcodes32_64.cpp:
1460         (JSC::JIT::emitSlow_op_new_object):
1461         (JSC::JIT::emitSlow_op_instanceof):
1462         (JSC::JIT::emitSlow_op_instanceof_custom):
1463         (JSC::JIT::emitSlow_op_to_primitive):
1464         (JSC::JIT::emitSlow_op_not):
1465         (JSC::JIT::emitSlow_op_stricteq):
1466         (JSC::JIT::emitSlow_op_nstricteq):
1467         (JSC::JIT::emitSlow_op_to_number):
1468         (JSC::JIT::emitSlow_op_to_string):
1469         (JSC::JIT::emitSlow_op_create_this):
1470         (JSC::JIT::emitSlow_op_to_this):
1471         (JSC::JIT::emitSlow_op_check_tdz):
1472         (JSC::JIT::emitSlow_op_has_indexed_property):
1473         (JSC::JIT::emitSlow_op_get_direct_pname):
1474         * jit/JITPropertyAccess.cpp:
1475         (JSC::JIT::emitSlow_op_try_get_by_id):
1476         (JSC::JIT::emitSlow_op_get_by_id):
1477         (JSC::JIT::emitSlow_op_get_by_id_with_this):
1478         (JSC::JIT::emitSlow_op_put_by_id):
1479         (JSC::JIT::emitSlow_op_resolve_scope):
1480         (JSC::JIT::emitSlow_op_get_from_scope):
1481         (JSC::JIT::emitSlow_op_put_to_scope):
1482         * jit/JITPropertyAccess32_64.cpp:
1483         (JSC::JIT::emitSlow_op_try_get_by_id):
1484         (JSC::JIT::emitSlow_op_get_by_id):
1485         (JSC::JIT::emitSlow_op_get_by_id_with_this):
1486         (JSC::JIT::emitSlow_op_put_by_id):
1487         (JSC::JIT::emitSlow_op_resolve_scope):
1488         (JSC::JIT::emitSlow_op_get_from_scope):
1489         (JSC::JIT::emitSlow_op_put_to_scope):
1490
1491 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1492
1493         [JSC] Clean up baseline slow path
1494         https://bugs.webkit.org/show_bug.cgi?id=178646
1495
1496         Reviewed by Saam Barati.
1497
1498         If the given op is just calling a slow path function, we should use DEFINE_SLOW_OP instead.
1499         It is good since (1) we can reduce the manual emitting code and (2) it can clarify which
1500         function is implemented as a slow path call. This patch is an attempt to reduce 32bit specific
1501         code in baseline JIT.
1502
1503         * jit/JIT.cpp:
1504         (JSC::JIT::privateCompileMainPass):
1505         * jit/JIT.h:
1506         * jit/JITArithmetic.cpp:
1507         (JSC::JIT::emit_op_pow): Deleted.
1508         * jit/JITArithmetic32_64.cpp:
1509         (JSC::JIT::emitSlow_op_mod):
1510         * jit/JITOpcodes.cpp:
1511         (JSC::JIT::emit_op_strcat): Deleted.
1512         (JSC::JIT::emit_op_push_with_scope): Deleted.
1513         (JSC::JIT::emit_op_assert): Deleted.
1514         (JSC::JIT::emit_op_create_lexical_environment): Deleted.
1515         (JSC::JIT::emit_op_throw_static_error): Deleted.
1516         (JSC::JIT::emit_op_new_array_with_spread): Deleted.
1517         (JSC::JIT::emit_op_spread): Deleted.
1518         (JSC::JIT::emit_op_get_enumerable_length): Deleted.
1519         (JSC::JIT::emit_op_has_generic_property): Deleted.
1520         (JSC::JIT::emit_op_get_property_enumerator): Deleted.
1521         (JSC::JIT::emit_op_to_index_string): Deleted.
1522         (JSC::JIT::emit_op_create_direct_arguments): Deleted.
1523         (JSC::JIT::emit_op_create_scoped_arguments): Deleted.
1524         (JSC::JIT::emit_op_create_cloned_arguments): Deleted.
1525         (JSC::JIT::emit_op_create_rest): Deleted.
1526         (JSC::JIT::emit_op_unreachable): Deleted.
1527         * jit/JITOpcodes32_64.cpp:
1528         (JSC::JIT::emit_op_strcat): Deleted.
1529         (JSC::JIT::emit_op_push_with_scope): Deleted.
1530         (JSC::JIT::emit_op_assert): Deleted.
1531         (JSC::JIT::emit_op_create_lexical_environment): Deleted.
1532         * jit/JITPropertyAccess.cpp:
1533         (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
1534         (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
1535         (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
1536         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
1537         (JSC::JIT::emit_op_define_data_property): Deleted.
1538         (JSC::JIT::emit_op_define_accessor_property): Deleted.
1539         * jit/JITPropertyAccess32_64.cpp:
1540         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
1541         (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
1542         (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
1543         (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
1544
1545 2017-10-21  Joseph Pecoraro  <pecoraro@apple.com>
1546
1547         Web Inspector: Remove unused Console.setMonitoringXHREnabled
1548         https://bugs.webkit.org/show_bug.cgi?id=178617
1549
1550         Reviewed by Sam Weinig.
1551
1552         * JavaScriptCore.xcodeproj/project.pbxproj:
1553         * Sources.txt:
1554         * inspector/agents/InspectorConsoleAgent.h:
1555         * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
1556         * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
1557         * inspector/protocol/Console.json:
1558         Removed files and method.
1559
1560         * inspector/JSGlobalObjectInspectorController.cpp:
1561         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1562         This can use the base ConsoleAgent now.
1563
1564 2017-10-21  Yusuke Suzuki  <utatane.tea@gmail.com>
1565
1566         [JSC] Remove per-host-function CTI stub in 32bit environment
1567         https://bugs.webkit.org/show_bug.cgi?id=178581
1568
1569         Reviewed by Saam Barati.
1570
1571         JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub.
1572         The only difference is that it embed the address of the host function directly in the generated stub. This means
1573         that we have per-host-function CTI stub only in 32bit environment.
1574
1575         This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation.
1576
1577         * jit/JIT.cpp:
1578         (JSC::JIT::compileCTINativeCall): Deleted.
1579         * jit/JIT.h:
1580         * jit/JITOpcodes.cpp:
1581         (JSC::JIT::privateCompileCTINativeCall): Deleted.
1582         * jit/JITOpcodes32_64.cpp:
1583         (JSC::JIT::privateCompileCTINativeCall): Deleted.
1584         * jit/JITThunks.cpp:
1585         (JSC::JITThunks::hostFunctionStub):
1586
1587 2017-10-20  Antoine Quint  <graouts@apple.com>
1588
1589         [Web Animations] Provide basic timeline and animation interfaces
1590         https://bugs.webkit.org/show_bug.cgi?id=178526
1591
1592         Reviewed by Dean Jackson.
1593
1594         Remove the WEB_ANIMATIONS compile-time flag.
1595
1596         * Configurations/FeatureDefines.xcconfig:
1597
1598 2017-10-20  Commit Queue  <commit-queue@webkit.org>
1599
1600         Unreviewed, rolling out r223744, r223750, and r223751.
1601         https://bugs.webkit.org/show_bug.cgi?id=178594
1602
1603         These caused consistent failures in test that existed and were
1604         added in the patches. (Requested by mlewis13 on #webkit).
1605
1606         Reverted changesets:
1607
1608         "[JSC] ScriptFetcher should be notified directly from module
1609         pipeline"
1610         https://bugs.webkit.org/show_bug.cgi?id=178340
1611         https://trac.webkit.org/changeset/223744
1612
1613         "Unreviewed, fix changed line number in test expect files"
1614         https://bugs.webkit.org/show_bug.cgi?id=178340
1615         https://trac.webkit.org/changeset/223750
1616
1617         "Unreviewed, follow up to reflect comments"
1618         https://bugs.webkit.org/show_bug.cgi?id=178340
1619         https://trac.webkit.org/changeset/223751
1620
1621 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1622
1623         Unreviewed, follow up to reflect comments
1624         https://bugs.webkit.org/show_bug.cgi?id=178340
1625
1626         * runtime/JSModuleLoader.cpp:
1627         (JSC::JSModuleLoader::notifyCompleted):
1628
1629 2017-10-20  Saam Barati  <sbarati@apple.com>
1630
1631         Optimize accesses to how we get the direct prototype
1632         https://bugs.webkit.org/show_bug.cgi?id=178548
1633
1634         Reviewed by Yusuke Suzuki.
1635
1636         This patch makes JSObject::getPrototypeDirect take VM& as a parameter
1637         so it can use the faster version of the structure accessor function.
1638         The reason for making this change is that JSObjet::getPrototypeDirect
1639         is called on the hot path in property lookup.
1640
1641         * API/JSObjectRef.cpp:
1642         (JSObjectGetPrototype):
1643         * jsc.cpp:
1644         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
1645         (WTF::DOMJITGetterBaseJSObject::customGetter):
1646         (functionCreateProxy):
1647         * runtime/ArrayPrototype.cpp:
1648         (JSC::speciesWatchpointIsValid):
1649         * runtime/ErrorInstance.cpp:
1650         (JSC::ErrorInstance::sanitizedToString):
1651         * runtime/JSArray.cpp:
1652         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
1653         * runtime/JSGlobalObject.cpp:
1654         (JSC::JSGlobalObject::init):
1655         (JSC::lastInPrototypeChain):
1656         (JSC::JSGlobalObject::resetPrototype):
1657         (JSC::JSGlobalObject::finishCreation):
1658         * runtime/JSGlobalObjectInlines.h:
1659         (JSC::JSGlobalObject::objectPrototypeIsSane):
1660         (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
1661         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
1662         * runtime/JSLexicalEnvironment.cpp:
1663         (JSC::JSLexicalEnvironment::getOwnPropertySlot):
1664         * runtime/JSMap.cpp:
1665         (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
1666         * runtime/JSObject.cpp:
1667         (JSC::JSObject::calculatedClassName):
1668         (JSC::JSObject::setPrototypeWithCycleCheck):
1669         (JSC::JSObject::getPrototype):
1670         (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
1671         (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
1672         (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
1673         (JSC::JSObject::prototypeChainMayInterceptStoreTo):
1674         * runtime/JSObject.h:
1675         (JSC::JSObject::finishCreation):
1676         (JSC::JSObject::getPrototypeDirect const):
1677         (JSC::JSObject::getPrototype):
1678         * runtime/JSObjectInlines.h:
1679         (JSC::JSObject::canPerformFastPutInline):
1680         (JSC::JSObject::getPropertySlot):
1681         (JSC::JSObject::getNonIndexPropertySlot):
1682         * runtime/JSProxy.cpp:
1683         (JSC::JSProxy::setTarget):
1684         * runtime/JSSet.cpp:
1685         (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
1686         * runtime/ProgramExecutable.cpp:
1687         (JSC::ProgramExecutable::initializeGlobalProperties):
1688         * runtime/StructureInlines.h:
1689         (JSC::Structure::isValid const):
1690
1691 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1692
1693         [ARM64] static_cast<int32_t>() in BinaryOpNode::emitBytecode() prevents op_unsigned emission
1694         https://bugs.webkit.org/show_bug.cgi?id=178379
1695
1696         Reviewed by Saam Barati.
1697
1698         We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t
1699         in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue.
1700
1701         * bytecompiler/NodesCodegen.cpp:
1702         (JSC::BinaryOpNode::emitBytecode):
1703
1704 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1705
1706         [JSC] ScriptFetcher should be notified directly from module pipeline
1707         https://bugs.webkit.org/show_bug.cgi?id=178340
1708
1709         Reviewed by Sam Weinig.
1710
1711         Previously, we use JSStdFunction to let WebCore inform the module pipeline results.
1712         We setup JSStdFunction to the resulted promise of the module pipeline. It is super
1713         ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced.
1714         JSStdFunction's lambda can capture variables, but they are not able to be marked by GC.
1715
1716         But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline
1717         notification mechanism by using JSStdFunction. But it is appropriate one to receive notification
1718         from the module pipeline by observer style.
1719
1720         This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives
1721         completion/failure notifications from the module pipeline.
1722
1723         * builtins/ModuleLoaderPrototype.js:
1724         (loadModule):
1725         (loadAndEvaluateModule):
1726         * runtime/Completion.cpp:
1727         (JSC::loadModule):
1728         * runtime/Completion.h:
1729         * runtime/JSModuleLoader.cpp:
1730         (JSC::jsValueToModuleKey):
1731         (JSC::JSModuleLoader::notifyCompleted):
1732         (JSC::JSModuleLoader::notifyFailed):
1733         * runtime/JSModuleLoader.h:
1734         * runtime/ModuleLoaderPrototype.cpp:
1735         (JSC::moduleLoaderPrototypeNotifyCompleted):
1736         (JSC::moduleLoaderPrototypeNotifyFailed):
1737         * runtime/ScriptFetcher.h:
1738         (JSC::ScriptFetcher::notifyLoadCompleted):
1739         (JSC::ScriptFetcher::notifyLoadFailed):
1740
1741 2017-10-19  JF Bastien  <jfbastien@apple.com>
1742
1743         WebAssembly: no VM / JS version of everything but Instance
1744         https://bugs.webkit.org/show_bug.cgi?id=177473
1745
1746         Reviewed by Filip Pizlo, Saam Barati.
1747
1748         This change entails cleaning up and splitting a bunch of code which we had
1749         intertwined between C++ classes which represent JS objects, and pure C++
1750         implementation objects. This specific change goes most of the way towards
1751         allowing JSC's WebAssembly to work without VM / JS, up to but excluding
1752         JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
1753         yet). Because of this we still have a few FIXME identifying places that need to
1754         change. A follow-up change will go the rest of the way.
1755
1756         I went about this change in the simplest way possible: grep the
1757         JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
1758         sub-directory (which contains the JS implementation of WebAssembly).
1759
1760         None of this change removes the need for a JIT entitlement to be able to use
1761         WebAssembly. We don't have an interpreter, the process therefore still needs to
1762         be allowed to JIT to use these pure-C++ APIs.
1763
1764         Interesting things to note:
1765
1766           - Remove VM from Plan and associated places. It can just live as a capture in
1767             the callback lambda if it's needed.
1768           - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
1769             collect. We now instead pass two lambdas at construction time for this
1770             purpose: one to notify of memory pressure, and the other to ask for
1771             syncrhonous memory reclamation. This allows whoever creates the memory to
1772             dictate how to react to both these cases, and for a JS embedding that's to
1773             call the GC (async or sync, respectively).
1774           - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
1775             there, with an enum class for failure types.
1776           - Exceeding max on memory growth now returns a range error as per spec. This
1777             is a (very minor) breaking change: it used to throw OOM error. Update the
1778             corresponding test.
1779           - When generating the grow_memory opcode, no need to get the VM. Instead,
1780             reach directly for Wasm::Memory and grow it.
1781           - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
1782             ever called from JS (not from grow_memory as before).
1783           - Wasm::Memory now takes a callback for successful growth. This allows JS
1784             wrappers to register themselves when growth succeeds without Wasm::Memory
1785             knowning anything about JS. It'll also allow creating a list of callbacks
1786             for when we add thread support (we'll want to notify many wrappers, all
1787             under a lock).
1788           - Wasm::Memory is now back to being the source of truth about address / size,
1789             used directly by generated code instead of JSWebAssemblyMemory.
1790           - Move wasmToJS from the general WasmBinding header to its own header under
1791             wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
1792             and therefore isn't general WebAssembly.
1793           - Make Wasm::Context an actual type (just a struct holding a
1794             JSWebAssemlyInstance for now) instead of an alias for that. Notably this
1795             doesn't add anything to the Context and doesn't change what actually gets
1796             passed around in JIT code (fast TLS or registers) because these changes
1797             potentially impact performance. The entire purpose of this change is to
1798             allow passing Wasm::Context around without having to know about VM. Since VM
1799             contains a Wasm::Context the JS embedding is effectively the same, but with
1800             this setup a non-JS embedding is much better off.
1801           - Move JSWebAssembly into the JS folder.
1802           - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
1803           - wasm->JS stubs are now on the instance's tail as raw pointers, instead of
1804             being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
1805             stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
1806             called wasm->JS stub. This move means that the embedder must, after creating
1807             a Wasm::CodeBlock, somehow create the stubs to call back into the
1808             embedder. This removes an indirection in the generated code because
1809             the B3 IR generator now reaches into the instance instead of
1810             JSWebAssemblyCodeBlock.
1811           - Move more CodeBlock things. Compilation completion is now marked by its own
1812             atomic<bool> flag instead of a nullptr plan: that required using a lock, and
1813             was causing a deadlock in stack-trace.js because before my changes
1814             JSWebAssemblyCodeBlock did its own completion checking separately from
1815             Wasm::CodeBlock, without getting the lock. Now that everything points to
1816             Wasm::CodeBlock and there's no cached completion marker, the lock was being
1817             acquired in a sanity-check assertion.
1818           - Embedder -> Wasm wrappers are now generated through a function that's passed
1819             in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
1820           - WasmMemory doens't need to know about fault handling thunks. Only the IR
1821             generator should know, and should make sure that the exception throwing
1822             thunk is generated if any memory is present (note: with signal handling not
1823             all of them generate an exception check).
1824           - Make exception throwing pluggable: instead of having a hard-coded
1825             JS-specific lambda we now have a regular C++ function being called from JIT
1826             code when a WebAssembly exception is thrown. This allows any embedder to get
1827             called as they wish. For now a process can only have a single of these
1828             functions (i.e. only one embedder per process) because the trap handler is a
1829             singleton. That can be fixed in in #177475.
1830           - Create WasmEmbedder.h where all embedder plugging will live.
1831           - Split up JSWebAssemblyTable into Wasm::Table which is
1832             refcounted. JSWebAssemblyTable now only contains the JS functions in the
1833             table, and Wasm::Table is what's used by the JIT code to lookup where to
1834             call and do the instance check (for context switch). Note that this creates
1835             an extra allocation for all the instances in Wasm::Table, and in exchange
1836             removes an indirection in JIT code because the instance used to be obtained
1837             off of the JS function. Also note that it's the embedder than keeps the
1838             instances alive, not Wasm::Table (which holds a dumb pointer to the
1839             instance), because doing otherwise would cause reference cycles.
1840            - Add WasmInstance. It doesn't do much for now, owns globals.
1841            - JSWebAssembly instance now doesn't just contain the imported functions as
1842              JSObjects, it also has the corresponding import's instance and wasm
1843              entrypoint. This triples the space allocated per instance's imported
1844              function, but there shouldn't be that many imports. This has two upsides: it
1845              creates smaller and faster code, and makes is easier to disassociate
1846              embedder-specific things from embedder-neutral things. The small / faster
1847              win is in two places: B3 IR generator only needs offsetOfImportFunction for
1848              the call opcode (when the called index is an import) to know whether the
1849              import is wasm->wasm or wasm->embedder (this isn't known at compile-time
1850              because it's dependent on the import object), this is now done by seeing if
1851              that import function has an associated target instance (only wasm->wasm
1852              does); the other place is wasmBinding which uses offsetOfImportFunction to
1853              figure out the wasm->wasm target instance, and then gets
1854              WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
1855              call. The disassociation comes because the target instance can be
1856              Wasm::Instance once we change what the Context is, and
1857              WasmEntrypointLoadLocation is already embedder-independent. As a next step I
1858              can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
1859              and leave importFunction in as an opaque pointer which is embedder-specific,
1860              and in JS will remain WriteBarrier<JSObject>.
1861            - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
1862              around instead of VM. This is a first step in allowing entry frames which
1863              aren't stored on VM, but which are instead stored in an embedder-specific
1864              location. That change won't really affect JS except through code churn, but
1865              will allow WebAssembly to use some machinery in a generic manner without
1866              having a VM.
1867
1868         * JavaScriptCore.xcodeproj/project.pbxproj:
1869         * Sources.txt:
1870         * bytecode/PolymorphicAccess.cpp:
1871         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
1872         * debugger/Debugger.cpp:
1873         (JSC::Debugger::stepOutOfFunction):
1874         (JSC::Debugger::returnEvent):
1875         (JSC::Debugger::unwindEvent):
1876         (JSC::Debugger::didExecuteProgram):
1877         * dfg/DFGJITCompiler.cpp:
1878         (JSC::DFG::JITCompiler::compileExceptionHandlers):
1879         * dfg/DFGOSREntry.cpp:
1880         (JSC::DFG::prepareOSREntry):
1881         * dfg/DFGOSRExit.cpp:
1882         (JSC::DFG::OSRExit::compileOSRExit):
1883         (JSC::DFG::OSRExit::compileExit):
1884         * dfg/DFGThunks.cpp:
1885         (JSC::DFG::osrEntryThunkGenerator):
1886         * ftl/FTLCompile.cpp:
1887         (JSC::FTL::compile):
1888         * ftl/FTLLink.cpp:
1889         (JSC::FTL::link):
1890         * ftl/FTLLowerDFGToB3.cpp:
1891         (JSC::FTL::DFG::LowerDFGToB3::lower):
1892         * ftl/FTLOSRExitCompiler.cpp:
1893         (JSC::FTL::compileStub):
1894         * interpreter/CallFrame.cpp:
1895         (JSC::CallFrame::wasmAwareLexicalGlobalObject):
1896         (JSC::CallFrame::callerFrame):
1897         (JSC::CallFrame::unsafeCallerFrame):
1898         * interpreter/CallFrame.h:
1899         (JSC::ExecState::callerFrame const):
1900         (JSC::ExecState::callerFrameOrEntryFrame const):
1901         (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
1902         * interpreter/FrameTracers.h:
1903         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
1904         (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
1905         (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
1906         * interpreter/Interpreter.cpp:
1907         (JSC::UnwindFunctor::operator() const):
1908         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
1909         (JSC::Interpreter::unwind):
1910         * interpreter/StackVisitor.cpp:
1911         (JSC::StackVisitor::StackVisitor):
1912         (JSC::StackVisitor::gotoNextFrame):
1913         (JSC::StackVisitor::readNonInlinedFrame):
1914         (JSC::StackVisitor::Frame::dump const):
1915         * interpreter/StackVisitor.h:
1916         (JSC::StackVisitor::Frame::callerIsEntryFrame const):
1917         * interpreter/VMEntryRecord.h:
1918         (JSC::VMEntryRecord::prevTopEntryFrame):
1919         (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
1920         (JSC::EntryFrame::vmEntryRecordOffset):
1921         * jit/AssemblyHelpers.cpp:
1922         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
1923         (JSC::AssemblyHelpers::loadWasmContextInstance):
1924         (JSC::AssemblyHelpers::storeWasmContextInstance):
1925         (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
1926         (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
1927         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
1928         * jit/AssemblyHelpers.h:
1929         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
1930         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
1931         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
1932         * jit/JIT.cpp:
1933         (JSC::JIT::emitEnterOptimizationCheck):
1934         (JSC::JIT::privateCompileExceptionHandlers):
1935         * jit/JITExceptions.cpp:
1936         (JSC::genericUnwind):
1937         * jit/JITOpcodes.cpp:
1938         (JSC::JIT::emit_op_throw):
1939         (JSC::JIT::emit_op_catch):
1940         (JSC::JIT::emitSlow_op_loop_hint):
1941         * jit/JITOpcodes32_64.cpp:
1942         (JSC::JIT::emit_op_throw):
1943         (JSC::JIT::emit_op_catch):
1944         * jit/JITOperations.cpp:
1945         * jit/ThunkGenerators.cpp:
1946         (JSC::throwExceptionFromCallSlowPathGenerator):
1947         (JSC::nativeForGenerator):
1948         * jsc.cpp:
1949         (functionDumpCallFrame):
1950         * llint/LLIntSlowPaths.cpp:
1951         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1952         * llint/LLIntThunks.cpp:
1953         (JSC::vmEntryRecord):
1954         * llint/LowLevelInterpreter.asm:
1955         * llint/LowLevelInterpreter32_64.asm:
1956         * llint/LowLevelInterpreter64.asm:
1957         * runtime/Options.cpp:
1958         (JSC::recomputeDependentOptions):
1959         * runtime/Options.h:
1960         * runtime/SamplingProfiler.cpp:
1961         (JSC::FrameWalker::FrameWalker):
1962         (JSC::FrameWalker::advanceToParentFrame):
1963         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1964         * runtime/ThrowScope.cpp:
1965         (JSC::ThrowScope::~ThrowScope):
1966         * runtime/VM.cpp:
1967         (JSC::VM::VM):
1968         (JSC::VM::~VM):
1969         * runtime/VM.h:
1970         (JSC::VM::topEntryFrameOffset):
1971         * runtime/VMTraps.cpp:
1972         (JSC::isSaneFrame):
1973         (JSC::VMTraps::tryInstallTrapBreakpoints):
1974         (JSC::VMTraps::invalidateCodeBlocksOnStack):
1975         * wasm/WasmB3IRGenerator.cpp:
1976         (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
1977         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1978         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1979         (JSC::Wasm::B3IRGenerator::addGrowMemory):
1980         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
1981         (JSC::Wasm::B3IRGenerator::addCall):
1982         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1983         (JSC::Wasm::parseAndCompile):
1984         * wasm/WasmB3IRGenerator.h:
1985         * wasm/WasmBBQPlan.cpp:
1986         (JSC::Wasm::BBQPlan::BBQPlan):
1987         (JSC::Wasm::BBQPlan::compileFunctions):
1988         (JSC::Wasm::BBQPlan::complete):
1989         * wasm/WasmBBQPlan.h:
1990         * wasm/WasmBBQPlanInlines.h:
1991         (JSC::Wasm::BBQPlan::initializeCallees):
1992         * wasm/WasmBinding.cpp:
1993         (JSC::Wasm::wasmToWasm):
1994         * wasm/WasmBinding.h:
1995         * wasm/WasmCodeBlock.cpp:
1996         (JSC::Wasm::CodeBlock::create):
1997         (JSC::Wasm::CodeBlock::CodeBlock):
1998         (JSC::Wasm::CodeBlock::compileAsync):
1999         (JSC::Wasm::CodeBlock::setCompilationFinished):
2000         * wasm/WasmCodeBlock.h:
2001         (JSC::Wasm::CodeBlock::offsetOfImportStubs):
2002         (JSC::Wasm::CodeBlock::allocationSize):
2003         (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
2004         (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
2005         (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
2006         (JSC::Wasm::CodeBlock::compilationFinished):
2007         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
2008         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
2009         * wasm/WasmContext.cpp:
2010         (JSC::Wasm::Context::useFastTLS):
2011         (JSC::Wasm::Context::load const):
2012         (JSC::Wasm::Context::store):
2013         * wasm/WasmContext.h:
2014         * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
2015         * wasm/WasmFaultSignalHandler.cpp:
2016         * wasm/WasmFaultSignalHandler.h:
2017         * wasm/WasmFormat.h:
2018         * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2019         (JSC::Wasm::Instance::Instance):
2020         (JSC::Wasm::Instance::~Instance):
2021         (JSC::Wasm::Instance::extraMemoryAllocated const):
2022         * wasm/WasmInstance.h: Added.
2023         (JSC::Wasm::Instance::create):
2024         (JSC::Wasm::Instance::finalizeCreation):
2025         (JSC::Wasm::Instance::module):
2026         (JSC::Wasm::Instance::codeBlock):
2027         (JSC::Wasm::Instance::memory):
2028         (JSC::Wasm::Instance::table):
2029         (JSC::Wasm::Instance::loadI32Global const):
2030         (JSC::Wasm::Instance::loadI64Global const):
2031         (JSC::Wasm::Instance::loadF32Global const):
2032         (JSC::Wasm::Instance::loadF64Global const):
2033         (JSC::Wasm::Instance::setGlobal):
2034         (JSC::Wasm::Instance::offsetOfCachedStackLimit):
2035         (JSC::Wasm::Instance::cachedStackLimit const):
2036         (JSC::Wasm::Instance::setCachedStackLimit):
2037         * wasm/WasmMemory.cpp:
2038         (JSC::Wasm::Memory::Memory):
2039         (JSC::Wasm::Memory::create):
2040         (JSC::Wasm::Memory::~Memory):
2041         (JSC::Wasm::Memory::grow):
2042         * wasm/WasmMemory.h:
2043         (JSC::Wasm::Memory::offsetOfMemory):
2044         (JSC::Wasm::Memory::offsetOfSize):
2045         * wasm/WasmMemoryInformation.cpp:
2046         (JSC::Wasm::PinnedRegisterInfo::get):
2047         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
2048         * wasm/WasmMemoryInformation.h:
2049         (JSC::Wasm::PinnedRegisterInfo::toSave const):
2050         * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2051         (JSC::Wasm::makeString):
2052         * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2053         * wasm/WasmModule.cpp:
2054         (JSC::Wasm::makeValidationCallback):
2055         (JSC::Wasm::Module::validateSync):
2056         (JSC::Wasm::Module::validateAsync):
2057         (JSC::Wasm::Module::getOrCreateCodeBlock):
2058         (JSC::Wasm::Module::compileSync):
2059         (JSC::Wasm::Module::compileAsync):
2060         * wasm/WasmModule.h:
2061         * wasm/WasmModuleParser.cpp:
2062         (JSC::Wasm::ModuleParser::parseTableHelper):
2063         * wasm/WasmOMGPlan.cpp:
2064         (JSC::Wasm::OMGPlan::OMGPlan):
2065         (JSC::Wasm::OMGPlan::runForIndex):
2066         * wasm/WasmOMGPlan.h:
2067         * wasm/WasmPageCount.h:
2068         (JSC::Wasm::PageCount::isValid const):
2069         * wasm/WasmPlan.cpp:
2070         (JSC::Wasm::Plan::Plan):
2071         (JSC::Wasm::Plan::runCompletionTasks):
2072         (JSC::Wasm::Plan::addCompletionTask):
2073         (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
2074         * wasm/WasmPlan.h:
2075         (JSC::Wasm::Plan::dontFinalize):
2076         * wasm/WasmSignature.cpp:
2077         * wasm/WasmSignature.h:
2078         * wasm/WasmTable.cpp: Added.
2079         (JSC::Wasm::Table::create):
2080         (JSC::Wasm::Table::~Table):
2081         (JSC::Wasm::Table::Table):
2082         (JSC::Wasm::Table::grow):
2083         (JSC::Wasm::Table::clearFunction):
2084         (JSC::Wasm::Table::setFunction):
2085         * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
2086         (JSC::Wasm::Table::maximum const):
2087         (JSC::Wasm::Table::size const):
2088         (JSC::Wasm::Table::offsetOfSize):
2089         (JSC::Wasm::Table::offsetOfFunctions):
2090         (JSC::Wasm::Table::offsetOfInstances):
2091         (JSC::Wasm::Table::isValidSize):
2092         * wasm/WasmThunks.cpp:
2093         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
2094         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
2095         (JSC::Wasm::Thunks::setThrowWasmException):
2096         (JSC::Wasm::Thunks::throwWasmException):
2097         * wasm/WasmThunks.h:
2098         * wasm/WasmWorklist.cpp:
2099         (JSC::Wasm::Worklist::stopAllPlansForContext):
2100         * wasm/WasmWorklist.h:
2101         * wasm/js/JSToWasm.cpp: Added.
2102         (JSC::Wasm::createJSToWasmWrapper):
2103         * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
2104         * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
2105         * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
2106         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2107         (JSC::JSWebAssemblyCodeBlock::create):
2108         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
2109         * wasm/js/JSWebAssemblyCodeBlock.h:
2110         * wasm/js/JSWebAssemblyInstance.cpp:
2111         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
2112         (JSC::JSWebAssemblyInstance::finishCreation):
2113         (JSC::JSWebAssemblyInstance::visitChildren):
2114         (JSC::JSWebAssemblyInstance::finalizeCreation):
2115         (JSC::JSWebAssemblyInstance::create):
2116         * wasm/js/JSWebAssemblyInstance.h:
2117         (JSC::JSWebAssemblyInstance::instance):
2118         (JSC::JSWebAssemblyInstance::context const):
2119         (JSC::JSWebAssemblyInstance::table):
2120         (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
2121         (JSC::JSWebAssemblyInstance::setMemory):
2122         (JSC::JSWebAssemblyInstance::offsetOfTail):
2123         (JSC::JSWebAssemblyInstance::importFunctionInfo):
2124         (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
2125         (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
2126         (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
2127         (JSC::JSWebAssemblyInstance::importFunction):
2128         (JSC::JSWebAssemblyInstance::internalMemory):
2129         (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
2130         (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
2131         (JSC::JSWebAssemblyInstance::offsetOfCallee):
2132         (JSC::JSWebAssemblyInstance::offsetOfGlobals):
2133         (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
2134         (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
2135         (JSC::JSWebAssemblyInstance::cachedStackLimit const):
2136         (JSC::JSWebAssemblyInstance::setCachedStackLimit):
2137         (JSC::JSWebAssemblyInstance::wasmMemory):
2138         (JSC::JSWebAssemblyInstance::wasmModule):
2139         (JSC::JSWebAssemblyInstance::allocationSize):
2140         (JSC::JSWebAssemblyInstance::module const):
2141         * wasm/js/JSWebAssemblyMemory.cpp:
2142         (JSC::JSWebAssemblyMemory::create):
2143         (JSC::JSWebAssemblyMemory::adopt):
2144         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
2145         (JSC::JSWebAssemblyMemory::grow):
2146         (JSC::JSWebAssemblyMemory::growSuccessCallback):
2147         * wasm/js/JSWebAssemblyMemory.h:
2148         * wasm/js/JSWebAssemblyModule.cpp:
2149         (JSC::JSWebAssemblyModule::moduleInformation const):
2150         (JSC::JSWebAssemblyModule::exportSymbolTable const):
2151         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
2152         (JSC::JSWebAssemblyModule::callee const):
2153         (JSC::JSWebAssemblyModule::codeBlock):
2154         (JSC::JSWebAssemblyModule::module):
2155         * wasm/js/JSWebAssemblyModule.h:
2156         * wasm/js/JSWebAssemblyTable.cpp:
2157         (JSC::JSWebAssemblyTable::create):
2158         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
2159         (JSC::JSWebAssemblyTable::visitChildren):
2160         (JSC::JSWebAssemblyTable::grow):
2161         (JSC::JSWebAssemblyTable::getFunction):
2162         (JSC::JSWebAssemblyTable::clearFunction):
2163         (JSC::JSWebAssemblyTable::setFunction):
2164         * wasm/js/JSWebAssemblyTable.h:
2165         (JSC::JSWebAssemblyTable::isValidSize):
2166         (JSC::JSWebAssemblyTable::maximum const):
2167         (JSC::JSWebAssemblyTable::size const):
2168         (JSC::JSWebAssemblyTable::table):
2169         * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
2170         (JSC::Wasm::materializeImportJSCell):
2171         (JSC::Wasm::wasmToJS):
2172         (JSC::Wasm::wasmToJSException):
2173         * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
2174         * wasm/js/WebAssemblyFunction.cpp:
2175         (JSC::callWebAssemblyFunction):
2176         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2177         (JSC::constructJSWebAssemblyInstance):
2178         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2179         (JSC::constructJSWebAssemblyMemory):
2180         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2181         (JSC::webAssemblyMemoryProtoFuncGrow):
2182         * wasm/js/WebAssemblyModuleConstructor.cpp:
2183         (JSC::constructJSWebAssemblyModule):
2184         (JSC::WebAssemblyModuleConstructor::createModule):
2185         * wasm/js/WebAssemblyModuleConstructor.h:
2186         * wasm/js/WebAssemblyModuleRecord.cpp:
2187         (JSC::WebAssemblyModuleRecord::link):
2188         (JSC::WebAssemblyModuleRecord::evaluate):
2189         * wasm/js/WebAssemblyPrototype.cpp:
2190         (JSC::webAssemblyCompileFunc):
2191         (JSC::instantiate):
2192         (JSC::compileAndInstantiate):
2193         (JSC::webAssemblyValidateFunc):
2194         * wasm/js/WebAssemblyTableConstructor.cpp:
2195         (JSC::constructJSWebAssemblyTable):
2196         * wasm/js/WebAssemblyWrapperFunction.cpp:
2197         (JSC::WebAssemblyWrapperFunction::create):
2198
2199 2017-10-19  Mark Lam  <mark.lam@apple.com>
2200
2201         Stringifier::appendStringifiedValue() is missing an exception check.
2202         https://bugs.webkit.org/show_bug.cgi?id=178386
2203         <rdar://problem/35027610>
2204
2205         Reviewed by Saam Barati.
2206
2207         * runtime/JSONObject.cpp:
2208         (JSC::Stringifier::appendStringifiedValue):
2209
2210 2017-10-19  Saam Barati  <sbarati@apple.com>
2211
2212         REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
2213         https://bugs.webkit.org/show_bug.cgi?id=178543
2214
2215         Reviewed by Filip Pizlo.
2216
2217         * dfg/DFGByteCodeParser.cpp:
2218         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2219
2220 2017-10-19  Saam Barati  <sbarati@apple.com>
2221
2222         re-inline ObjectAllocationProfile::initializeProfile
2223         https://bugs.webkit.org/show_bug.cgi?id=178532
2224
2225         Rubber stamped by Michael Saboff.
2226
2227         I un-inlined this function when implementing poly proto.
2228         This patch re-inlines it. In my testing, it looks like it
2229         might be a 0.5% speedometer progression to inline it.
2230
2231         * JavaScriptCore.xcodeproj/project.pbxproj:
2232         * Sources.txt:
2233         * bytecode/CodeBlock.cpp:
2234         * bytecode/ObjectAllocationProfile.cpp: Removed.
2235         * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp.
2236         (JSC::ObjectAllocationProfile::initializeProfile):
2237         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
2238         * runtime/FunctionRareData.cpp:
2239
2240 2017-10-19  Michael Saboff  <msaboff@apple.com>
2241
2242         Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation
2243         https://bugs.webkit.org/show_bug.cgi?id=178521
2244
2245         Reviewed by JF Bastien.
2246
2247         * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent
2248         standard version.  The prior version was the draft 6.0 version.
2249
2250 2017-10-19  Saam Barati  <sbarati@apple.com>
2251
2252         We should hard code the poly proto offset
2253         https://bugs.webkit.org/show_bug.cgi?id=178531
2254
2255         Reviewed by Filip Pizlo.
2256
2257         This patch embraces that the poly proto offset is always zero. It's already
2258         the case that we would always get the inline offset zero for poly proto just
2259         by construction. This just hardcodes this assumption throughout the codebase.
2260         This appears to be a 1% speedometer progression in my testing.
2261         
2262         The downside of this patch is that it may require changing how we do
2263         things when we implement poly proto when inheriting from builtin
2264         types. I think we can face this problem when we decide to implement
2265         that.
2266
2267         * bytecode/AccessCase.cpp:
2268         (JSC::AccessCase::generateWithGuard):
2269         * dfg/DFGOperations.cpp:
2270         * dfg/DFGSpeculativeJIT.cpp:
2271         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
2272         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
2273         * ftl/FTLLowerDFGToB3.cpp:
2274         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
2275         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2276         * jit/JITOpcodes.cpp:
2277         (JSC::JIT::emit_op_instanceof):
2278         * jit/JITOpcodes32_64.cpp:
2279         (JSC::JIT::emit_op_instanceof):
2280         * runtime/CommonSlowPaths.cpp:
2281         (JSC::SLOW_PATH_DECL):
2282         * runtime/JSObject.cpp:
2283         (JSC::JSObject::setPrototypeDirect):
2284         * runtime/JSObject.h:
2285         (JSC::JSObject::locationForOffset const):
2286         (JSC::JSObject::locationForOffset):
2287         (JSC::JSObject::getDirect const):
2288         * runtime/PropertyOffset.h:
2289         * runtime/Structure.cpp:
2290         (JSC::Structure::create):
2291         (JSC::Structure::dump const):
2292         * runtime/Structure.h:
2293         * runtime/StructureInlines.h:
2294         (JSC::Structure::storedPrototype const):
2295         (JSC::Structure::storedPrototypeObject const):
2296
2297 2017-10-19  Saam Barati  <sbarati@apple.com>
2298
2299         Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
2300         https://bugs.webkit.org/show_bug.cgi?id=178529
2301
2302         Reviewed by Mark Lam.
2303
2304         * runtime/Structure.h:
2305         * runtime/StructureInlines.h:
2306         (JSC::Structure::storedPrototypeObject const):
2307         (JSC::Structure::storedPrototypeStructure const):
2308         (JSC::Structure::storedPrototype const):
2309         (JSC::Structure::prototypeForLookup const):
2310         (JSC::Structure::prototypeChain const):
2311
2312 2017-10-19  Saam Barati  <sbarati@apple.com>
2313
2314         Turn poly proto back on by default and remove the option
2315         https://bugs.webkit.org/show_bug.cgi?id=178525
2316
2317         Reviewed by Mark Lam.
2318
2319         I added this option because I thought it'd speed speedometer up because the
2320         original poly proto patch slowed speedometer down. It turns out that
2321         allocating poly proto objects is not what slows speedometer down. It's
2322         other code I added in the runtime that needs to be poly proto aware. I'll
2323         be addressing these in follow up patches.
2324
2325         * runtime/Options.h:
2326         * runtime/StructureInlines.h:
2327         (JSC::Structure::shouldConvertToPolyProto):
2328
2329 2017-10-19  Robin Morisset  <rmorisset@apple.com>
2330
2331         Turn recursive tail calls into loops
2332         https://bugs.webkit.org/show_bug.cgi?id=176601
2333
2334         Reviewed by Saam Barati.
2335
2336         We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
2337         One difficulty is that we need to split the entry block of the function we are jumping to in order to have somewhere to jump to.
2338         Worse: it is not necessarily the first block of the codeBlock, because of inlining! So we must do the splitting in the DFGByteCodeParser, at the same time as inlining.
2339         We do this part through modifying the computation of the jump targets.
2340         Importantly, we only do this splitting for functions that have tail calls.
2341         It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.
2342
2343         We must then do the actual transformation also in DFGByteCodeParser, to avoid code motion moving code out of the body of what will become a loop.
2344         The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.
2345
2346         * bytecode/CodeBlock.h:
2347         (JSC::CodeBlock::hasTailCalls const):
2348         * bytecode/PreciseJumpTargets.cpp:
2349         (JSC::getJumpTargetsForBytecodeOffset):
2350         (JSC::computePreciseJumpTargetsInternal):
2351         * bytecode/UnlinkedCodeBlock.cpp:
2352         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2353         * bytecode/UnlinkedCodeBlock.h:
2354         (JSC::UnlinkedCodeBlock::hasTailCalls const):
2355         (JSC::UnlinkedCodeBlock::setHasTailCalls):
2356         * bytecompiler/BytecodeGenerator.cpp:
2357         (JSC::BytecodeGenerator::emitEnter):
2358         (JSC::BytecodeGenerator::emitCallInTailPosition):
2359         * dfg/DFGByteCodeParser.cpp:
2360         (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
2361         (JSC::DFG::ByteCodeParser::makeBlockTargetable):
2362         (JSC::DFG::ByteCodeParser::handleCall):
2363         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2364         (JSC::DFG::ByteCodeParser::parseBlock):
2365         (JSC::DFG::ByteCodeParser::parse):
2366
2367 2017-10-18  Mark Lam  <mark.lam@apple.com>
2368
2369         RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
2370         https://bugs.webkit.org/show_bug.cgi?id=177600
2371         <rdar://problem/34710985>
2372
2373         Reviewed by Saam Barati.
2374
2375         According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
2376         section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
2377         descriptor value is present.
2378
2379         * runtime/RegExpObject.cpp:
2380         (JSC::RegExpObject::defineOwnProperty):
2381
2382 2017-10-18  Keith Miller  <keith_miller@apple.com>
2383
2384         Setup WebCore build to start using unified sources.
2385         https://bugs.webkit.org/show_bug.cgi?id=178362
2386
2387         Reviewed by Tim Horton.
2388
2389         Change comments in source list files. Also, pass explicit names for build files.
2390
2391         * CMakeLists.txt:
2392         * PlatformGTK.cmake:
2393         * PlatformMac.cmake:
2394         * Sources.txt:
2395         * SourcesGTK.txt:
2396         * SourcesMac.txt:
2397
2398 2017-10-18  Commit Queue  <commit-queue@webkit.org>
2399
2400         Unreviewed, rolling out r223321.
2401         https://bugs.webkit.org/show_bug.cgi?id=178476
2402
2403         This protocol change broke some internal builds (Requested by
2404         brrian__ on #webkit).
2405
2406         Reverted changeset:
2407
2408         "Web Inspector: provide a way to enable/disable event
2409         listeners"
2410         https://bugs.webkit.org/show_bug.cgi?id=177451
2411         https://trac.webkit.org/changeset/223321
2412
2413 2017-10-18  Mark Lam  <mark.lam@apple.com>
2414
2415         The compiler should always register a structure when it adds its transitionWatchPointSet.
2416         https://bugs.webkit.org/show_bug.cgi?id=178420
2417         <rdar://problem/34814024>
2418
2419         Reviewed by Saam Barati and Filip Pizlo.
2420
2421         Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we
2422         now invoke Graph::registerAndWatchStructureTransition() on the structure.
2423         registerAndWatchStructureTransition() both registers the structure and add its
2424         transitionWatchpointSet to the plan desired watchpoints.
2425
2426         Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure()
2427         except registerAndWatchStructureTransition() adds the structure's
2428         transitionWatchpointSet unconditionally.
2429
2430         * dfg/DFGArgumentsEliminationPhase.cpp:
2431         * dfg/DFGArrayMode.cpp:
2432         (JSC::DFG::ArrayMode::refine const):
2433         * dfg/DFGByteCodeParser.cpp:
2434         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2435         * dfg/DFGFixupPhase.cpp:
2436         (JSC::DFG::FixupPhase::fixupNode):
2437
2438         * dfg/DFGGraph.cpp:
2439         (JSC::DFG::Graph::registerAndWatchStructureTransition):
2440         * dfg/DFGGraph.h:
2441
2442         * dfg/DFGSpeculativeJIT.cpp:
2443         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
2444         - The second set of addLazily()s is redundant.  This set is executed only when
2445           prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and
2446           only if we've executed the if statement above it.  That preceding if statement
2447           already registerAndWatchStructureTransition() the same 2 structures.  Hence,
2448           this second set can be deleted.
2449
2450         * dfg/DFGWatchpointCollectionPhase.cpp:
2451         (JSC::DFG::WatchpointCollectionPhase::addLazily):
2452         - Deleted an unused function.
2453
2454         * ftl/FTLLowerDFGToB3.cpp:
2455         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
2456
2457 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2458
2459         [JSC] Remove unused private name structure
2460         https://bugs.webkit.org/show_bug.cgi?id=178436
2461
2462         Reviewed by Sam Weinig.
2463
2464         It is no longer used. This patch just removes it.
2465
2466         * runtime/JSGlobalObject.h:
2467         (JSC::JSGlobalObject::numberObjectStructure const):
2468         (JSC::JSGlobalObject::privateNameStructure const): Deleted.
2469
2470 2017-10-18  Ryosuke Niwa  <rniwa@webkit.org>
2471
2472         Fix macOS and iOS builds after r223594.
2473
2474         * JavaScriptCore.xcodeproj/project.pbxproj:
2475
2476 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2477
2478         [JSC] __proto__ getter should be fast
2479         https://bugs.webkit.org/show_bug.cgi?id=178067
2480
2481         Reviewed by Saam Barati.
2482
2483         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
2484         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
2485         Call node for this. It is inefficient since typically we know the `prototype` of the given
2486         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
2487         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
2488         we can still change this to efficient access to poly proto slot.
2489
2490         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
2491         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
2492         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
2493         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
2494         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
2495         for ARES-6 ML.
2496
2497         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
2498
2499         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
2500         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
2501         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
2502
2503         This patch improves SixSpeed super.es6 by 3.42x.
2504
2505                                  baseline                  patched
2506
2507         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
2508
2509         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
2510
2511         * dfg/DFGAbstractInterpreterInlines.h:
2512         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2513         * dfg/DFGByteCodeParser.cpp:
2514         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2515         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
2516         (JSC::DFG::ByteCodeParser::handleGetById):
2517         * dfg/DFGClobberize.h:
2518         (JSC::DFG::clobberize):
2519         * dfg/DFGDoesGC.cpp:
2520         (JSC::DFG::doesGC):
2521         * dfg/DFGFixupPhase.cpp:
2522         (JSC::DFG::FixupPhase::fixupNode):
2523         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
2524         * dfg/DFGHeapLocation.cpp:
2525         (WTF::printInternal):
2526         * dfg/DFGHeapLocation.h:
2527         * dfg/DFGNode.h:
2528         (JSC::DFG::Node::hasHeapPrediction):
2529         (JSC::DFG::Node::shouldSpeculateFunction):
2530         * dfg/DFGNodeType.h:
2531         * dfg/DFGOperations.cpp:
2532         * dfg/DFGOperations.h:
2533         * dfg/DFGPredictionPropagationPhase.cpp:
2534         * dfg/DFGSafeToExecute.h:
2535         (JSC::DFG::safeToExecute):
2536         * dfg/DFGSpeculativeJIT.cpp:
2537         (JSC::DFG::SpeculativeJIT::speculateFunction):
2538         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
2539         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
2540         * dfg/DFGSpeculativeJIT.h:
2541         (JSC::DFG::SpeculativeJIT::callOperation):
2542         * dfg/DFGSpeculativeJIT32_64.cpp:
2543         (JSC::DFG::SpeculativeJIT::compile):
2544         * dfg/DFGSpeculativeJIT64.cpp:
2545         (JSC::DFG::SpeculativeJIT::compile):
2546         * ftl/FTLCapabilities.cpp:
2547         (JSC::FTL::canCompile):
2548         * ftl/FTLLowerDFGToB3.cpp:
2549         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2550         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
2551         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2552         * jit/IntrinsicEmitter.cpp:
2553         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
2554         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2555         * jit/JITOperations.h:
2556         * runtime/Intrinsic.cpp:
2557         (JSC::intrinsicName):
2558         * runtime/Intrinsic.h:
2559         * runtime/JSGlobalObject.cpp:
2560         (JSC::JSGlobalObject::init):
2561         * runtime/JSGlobalObject.h:
2562         (JSC::JSGlobalObject::booleanPrototype const):
2563         (JSC::JSGlobalObject::numberPrototype const):
2564         (JSC::JSGlobalObject::booleanObjectStructure const):
2565         * runtime/JSGlobalObjectFunctions.cpp:
2566         (JSC::globalFuncProtoGetter):
2567         * runtime/JSGlobalObjectFunctions.h:
2568         * runtime/ObjectConstructor.cpp:
2569         * runtime/ReflectObject.cpp:
2570
2571 2017-10-17  Ryan Haddad  <ryanhaddad@apple.com>
2572
2573         Unreviewed, rolling out r223523.
2574
2575         A test for this change is failing on debug JSC bots.
2576
2577         Reverted changeset:
2578
2579         "[JSC] __proto__ getter should be fast"
2580         https://bugs.webkit.org/show_bug.cgi?id=178067
2581         https://trac.webkit.org/changeset/223523
2582
2583 2017-10-17  Youenn Fablet  <youenn@apple.com>
2584
2585         Add preliminary support for fetch event
2586         https://bugs.webkit.org/show_bug.cgi?id=178171
2587
2588         Reviewed by Chris Dumez.
2589
2590         Adding events
2591
2592         * runtime/JSPromise.h:
2593
2594 2017-10-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2595
2596         [JSC] __proto__ getter should be fast
2597         https://bugs.webkit.org/show_bug.cgi?id=178067
2598
2599         Reviewed by Saam Barati.
2600
2601         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
2602         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
2603         Call node for this. It is inefficient since typically we know the `prototype` of the given
2604         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
2605         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
2606         we can still change this to efficient access to poly proto slot.
2607
2608         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
2609         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
2610         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
2611         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
2612         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
2613         for ARES-6 ML.
2614
2615         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
2616
2617         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
2618         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
2619         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
2620
2621         This patch improves SixSpeed super.es6 by 3.42x.
2622
2623                                  baseline                  patched
2624
2625         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
2626
2627         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
2628
2629         * dfg/DFGAbstractInterpreterInlines.h:
2630         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2631         * dfg/DFGByteCodeParser.cpp:
2632         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2633         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
2634         (JSC::DFG::ByteCodeParser::handleGetById):
2635         * dfg/DFGClobberize.h:
2636         (JSC::DFG::clobberize):
2637         * dfg/DFGDoesGC.cpp:
2638         (JSC::DFG::doesGC):
2639         * dfg/DFGFixupPhase.cpp:
2640         (JSC::DFG::FixupPhase::fixupNode):
2641         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
2642         * dfg/DFGHeapLocation.cpp:
2643         (WTF::printInternal):
2644         * dfg/DFGHeapLocation.h:
2645         * dfg/DFGNode.h:
2646         (JSC::DFG::Node::hasHeapPrediction):
2647         (JSC::DFG::Node::shouldSpeculateFunction):
2648         * dfg/DFGNodeType.h:
2649         * dfg/DFGOperations.cpp:
2650         * dfg/DFGOperations.h:
2651         * dfg/DFGPredictionPropagationPhase.cpp:
2652         * dfg/DFGSafeToExecute.h:
2653         (JSC::DFG::safeToExecute):
2654         * dfg/DFGSpeculativeJIT.cpp:
2655         (JSC::DFG::SpeculativeJIT::speculateFunction):
2656         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
2657         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
2658         * dfg/DFGSpeculativeJIT.h:
2659         * dfg/DFGSpeculativeJIT32_64.cpp:
2660         (JSC::DFG::SpeculativeJIT::compile):
2661         * dfg/DFGSpeculativeJIT64.cpp:
2662         (JSC::DFG::SpeculativeJIT::compile):
2663         * ftl/FTLCapabilities.cpp:
2664         (JSC::FTL::canCompile):
2665         * ftl/FTLLowerDFGToB3.cpp:
2666         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2667         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
2668         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2669         * jit/IntrinsicEmitter.cpp:
2670         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
2671         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2672         * runtime/Intrinsic.cpp:
2673         (JSC::intrinsicName):
2674         * runtime/Intrinsic.h:
2675         * runtime/JSGlobalObject.cpp:
2676         (JSC::JSGlobalObject::init):
2677         * runtime/JSGlobalObjectFunctions.cpp:
2678         (JSC::globalFuncProtoGetter):
2679         * runtime/JSGlobalObjectFunctions.h:
2680         * runtime/ObjectConstructor.cpp:
2681         * runtime/ReflectObject.cpp:
2682
2683 2017-10-17  Keith Miller  <keith_miller@apple.com>
2684
2685         Change WebCore sources to work with unified source builds
2686         https://bugs.webkit.org/show_bug.cgi?id=178229
2687
2688         Rubber stamped by Tim Horton.
2689
2690         * Configurations/FeatureDefines.xcconfig:
2691
2692 2017-10-15  Filip Pizlo  <fpizlo@apple.com>
2693
2694         Make some asserts into release asserts
2695         https://bugs.webkit.org/show_bug.cgi?id=178324
2696
2697         Reviewed by Saam Barati.
2698         
2699         These asserts are not on perf critical paths, so they might as well be release asserts.
2700
2701         * runtime/DataView.h:
2702         (JSC::DataView::get):
2703         (JSC::DataView::set):
2704
2705 2017-10-16  JF Bastien  <jfbastien@apple.com>
2706
2707         JSRunLoopTimer: reduce likely race when used improperly
2708         https://bugs.webkit.org/show_bug.cgi?id=178298
2709         <rdar://problem/32899816>
2710
2711         Reviewed by Saam Barati.
2712
2713         If an API user sets a timer on JSRunLoopTimer, and then racily
2714         destroys the JSRunLoopTimer while the timer is firing then it's
2715         possible for timerDidFire to cause a use-after-free and / or crash
2716         because e.g. m_apiLock becomes a nullptr while timerDidFire is
2717         executing. That results from an invalid use of JSRunLoopTimer, but
2718         we should try to be more resilient for that type of misuse because
2719         it's not necessarily easy to catch by inspection.
2720
2721         With this change the only remaining race is if the timer fires,
2722         and then only timerDidFire's prologue executes, but not the load
2723         of the m_apiLock pointer from `this`. It's a much smaller race.
2724
2725         Separately, I'll reach out to API users who are seemingly misusing
2726         the API.
2727
2728         * runtime/JSRunLoopTimer.cpp:
2729         (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack,
2730         and checks for nullptr. This prevents loading it twice off of
2731         `this` and turns a nullptr deref into "just" a use-after-free.
2732         (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before
2733         calling m_vm->unregisterRunLoopTimer(this), which in turn does
2734         CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents
2735         timerDidFire from doing much while the timers are un-registered.
2736         ~JSRunLoopTimer also needs to set m_apiLock to nullptr before
2737         releasing the lock, so it needs its own local copy.
2738
2739 2017-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
2740
2741         [JSC] Perform module specifier validation at parsing time
2742         https://bugs.webkit.org/show_bug.cgi?id=178256
2743
2744         Reviewed by Darin Adler.
2745
2746         This patch make module loader's `resolve` operation synchronous. And we validate
2747         module's requested module names when instantiating the module instead of satisfying
2748         module's dependencies. This change is not observable to users. But this is precise
2749         to the spec and this optimizes & simplifies the current module loader a bit by
2750         reducing object allocations.
2751
2752         Previously, we have an object called pair in the module loader. This is pair of
2753         module's name and module's record. And we use it to link one module to dependent
2754         modules. Now, it is replaced with module's registry entry.
2755
2756         We also change our loader functions to take a registry entry instead of a module key.
2757         Previous design is due to the consideration that these APIs may be exposed to users
2758         in whatwg/loader spec. However, this won't happen. This change removes unnecessary
2759         repeatedly hash map lookups.
2760
2761         * builtins/ModuleLoaderPrototype.js:
2762         (globalPrivate.newRegistryEntry):
2763         (requestFetch):
2764         (requestInstantiate):
2765         (requestSatisfy):
2766         (link):
2767         (moduleEvaluation):
2768         (loadModule):
2769         * jsc.cpp:
2770         (GlobalObject::moduleLoaderResolve):
2771         * runtime/AbstractModuleRecord.cpp:
2772         (JSC::AbstractModuleRecord::finishCreation):
2773         (JSC::AbstractModuleRecord::hostResolveImportedModule):
2774         * runtime/JSGlobalObject.h:
2775         * runtime/JSModuleLoader.cpp:
2776         (JSC::JSModuleLoader::resolveSync):
2777         (JSC::JSModuleLoader::resolve):
2778         * runtime/JSModuleLoader.h:
2779         * runtime/ModuleLoaderPrototype.cpp:
2780         (JSC::moduleLoaderPrototypeResolveSync):
2781
2782 2017-10-14  Devin Rousso  <webkit@devinrousso.com>
2783
2784         Web Inspector: provide a way to enable/disable event listeners
2785         https://bugs.webkit.org/show_bug.cgi?id=177451
2786
2787         Reviewed by Joseph Pecoraro.
2788
2789         * inspector/protocol/DOM.json:
2790         Add `setEventListenerDisabled` command that enables/disables a specific event listener
2791         during event dispatch. When a disabled event listener is fired, the listener's callback will
2792         not be called.
2793
2794 2017-10-14  Yusuke Suzuki  <utatane.tea@gmail.com>
2795
2796         Reland "Add Above/Below comparisons for UInt32 patterns"
2797         https://bugs.webkit.org/show_bug.cgi?id=177281
2798
2799         Reviewed by Saam Barati.
2800
2801         We reland this patch without DFGStrengthReduction change to see what causes
2802         regression in the iOS bot.
2803
2804         Sometimes, we would like to have UInt32 operations in JS. While VM does
2805         not support UInt32 nicely, VM supports efficient Int32 operations. As long
2806         as signedness does not matter, we can just perform Int32 operations instead
2807         and recognize its bit pattern as UInt32.
2808
2809         But of course, some operations respect signedness. The most frequently
2810         used one is comparison. Octane/zlib performs UInt32 comparison by performing
2811         `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
2812         UInt32 in Int32 form. And op_unsigned will generate Double value if
2813         the generated Int32 is < 0 (which should be UInt32).
2814
2815         There is a chance for optimization. The given code pattern is the following.
2816
2817             op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))
2818
2819         This can be converted to the following.
2820
2821             op_urshift(@1) below:< op_urshift(@2)
2822
2823         The above conversion is nice since
2824
2825         1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
2826         this check depends on the value of Int32, dropping this check is not as easy as
2827         removing Int32 edge filters.
2828
2829         2. We can perform unsigned comparison in Int32 form. We do not need to convert
2830         them to DoubleRep.
2831
2832         Since the above comparison exists in Octane/zlib's *super* hot path, dropping
2833         op_unsigned offers huge win.
2834
2835         At first, my patch attempts to convert the above thing in DFG pipeline.
2836         However it poses several problems.
2837
2838         1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
2839         2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,
2840
2841             2: UInt32ToNumber(@0)
2842             3: MovHint(@2, xxx)
2843             4: UInt32ToNumber(@1)
2844             5: MovHint(@1, xxx)
2845
2846         we could drop @5's MovHint. But @3 is difficult since @4 can exit.
2847
2848         So, instead, we start introducing a simple optimization in the bytecode compiler.
2849         It performs pattern matching for op_urshift and comparison to drop op_unsigned.
2850         We adds op_below and op_above families to bytecodes. They only accept Int32 and
2851         perform unsigned comparison.
2852
2853         This offers 4% performance improvement in Octane/zlib.
2854
2855                                     baseline                  patched
2856
2857         zlib           x2     431.07483+-16.28434       414.33407+-9.38375         might be 1.0404x faster
2858
2859         * bytecode/BytecodeDumper.cpp:
2860         (JSC::BytecodeDumper<Block>::printCompareJump):
2861         (JSC::BytecodeDumper<Block>::dumpBytecode):
2862         * bytecode/BytecodeDumper.h:
2863         * bytecode/BytecodeList.json:
2864         * bytecode/BytecodeUseDef.h:
2865         (JSC::computeUsesForBytecodeOffset):
2866         (JSC::computeDefsForBytecodeOffset):
2867         * bytecode/Opcode.h:
2868         (JSC::isBranch):
2869         * bytecode/PreciseJumpTargetsInlines.h:
2870         (JSC::extractStoredJumpTargetsForBytecodeOffset):
2871         * bytecompiler/BytecodeGenerator.cpp:
2872         (JSC::BytecodeGenerator::emitJumpIfTrue):
2873         (JSC::BytecodeGenerator::emitJumpIfFalse):
2874         * bytecompiler/NodesCodegen.cpp:
2875         (JSC::BinaryOpNode::emitBytecode):
2876         * dfg/DFGAbstractInterpreterInlines.h:
2877         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2878         * dfg/DFGByteCodeParser.cpp:
2879         (JSC::DFG::ByteCodeParser::parseBlock):
2880         * dfg/DFGCapabilities.cpp:
2881         (JSC::DFG::capabilityLevel):
2882         * dfg/DFGClobberize.h:
2883         (JSC::DFG::clobberize):
2884         * dfg/DFGDoesGC.cpp:
2885         (JSC::DFG::doesGC):
2886         * dfg/DFGFixupPhase.cpp:
2887         (JSC::DFG::FixupPhase::fixupNode):
2888         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2889         * dfg/DFGNodeType.h:
2890         * dfg/DFGPredictionPropagationPhase.cpp:
2891         * dfg/DFGSafeToExecute.h:
2892         (JSC::DFG::safeToExecute):
2893         * dfg/DFGSpeculativeJIT.cpp:
2894         (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
2895         * dfg/DFGSpeculativeJIT.h:
2896         * dfg/DFGSpeculativeJIT32_64.cpp:
2897         (JSC::DFG::SpeculativeJIT::compile):
2898         * dfg/DFGSpeculativeJIT64.cpp:
2899         (JSC::DFG::SpeculativeJIT::compile):
2900         * dfg/DFGValidate.cpp:
2901         * ftl/FTLCapabilities.cpp:
2902         (JSC::FTL::canCompile):
2903         * ftl/FTLLowerDFGToB3.cpp:
2904         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2905         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
2906         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
2907         * jit/JIT.cpp:
2908         (JSC::JIT::privateCompileMainPass):
2909         * jit/JIT.h:
2910         * jit/JITArithmetic.cpp:
2911         (JSC::JIT::emit_op_below):
2912         (JSC::JIT::emit_op_beloweq):
2913         (JSC::JIT::emit_op_jbelow):
2914         (JSC::JIT::emit_op_jbeloweq):
2915         (JSC::JIT::emit_compareUnsignedAndJump):
2916         (JSC::JIT::emit_compareUnsigned):
2917         * jit/JITArithmetic32_64.cpp:
2918         (JSC::JIT::emit_compareUnsignedAndJump):
2919         (JSC::JIT::emit_compareUnsigned):
2920         * llint/LowLevelInterpreter.asm:
2921         * llint/LowLevelInterpreter32_64.asm:
2922         * llint/LowLevelInterpreter64.asm:
2923         * parser/Nodes.h:
2924         (JSC::ExpressionNode::isBinaryOpNode const):
2925
2926 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2927
2928         WebAssembly: Wasm functions should have either JSFunctionType or TypeOfShouldCallGetCallData
2929         https://bugs.webkit.org/show_bug.cgi?id=178210
2930
2931         Reviewed by Saam Barati.
2932
2933         In Wasm, we have two JS functions exposed to users: WebAssemblyFunction and WebAssemblyWrapperFunction.
2934         The former is an exported wasm function and the latter is an imported & exported function. Since they
2935         have [[Call]], they should be categorized into "function" in typeof operation.
2936
2937         However, these functions do not implement our function protocol correctly. They inherit JSFunction.
2938         But JSType of WebAssemblyFunction is WebAssemblyFunctionType, and one of WebAssemblyWrapperFunction is
2939         ObjectType. Since both do not have TypeOfShouldCallGetCallData, they return "object" when performing
2940         typeof operation.
2941
2942         In this patch, we address the above issue by the following 2 fixes.
2943
2944         1. We add TypeOfShouldCallGetCallData to WebAssemblyFunction. This is the same way how we implement
2945         InternalFunction. Since WebAssemblyFunction requires WebAssemblyFunctionType for fast checking in Wasm
2946         implementation, we cannot make this JSFunctionType.
2947
2948         2. On the other hand, WebAssemblyWrapperFunction does not require a specific JSType. So this patch
2949         changes JSType of WebAssemblyWrapperFunction to JSFunctionType. JSFunctionType can be usable for derived
2950         classes of JSFunction (e.g. JSCustomGetterSetterFunction).
2951
2952         * wasm/js/WebAssemblyFunction.h:
2953         (JSC::WebAssemblyFunction::signatureIndex const): Deleted.
2954         (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation const): Deleted.
2955         (JSC::WebAssemblyFunction::callableFunction const): Deleted.
2956         (JSC::WebAssemblyFunction::jsEntrypoint): Deleted.
2957         (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): Deleted.
2958         * wasm/js/WebAssemblyWrapperFunction.cpp:
2959         (JSC::WebAssemblyWrapperFunction::createStructure):
2960         * wasm/js/WebAssemblyWrapperFunction.h:
2961         (JSC::WebAssemblyWrapperFunction::signatureIndex const): Deleted.
2962         (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation const): Deleted.
2963         (JSC::WebAssemblyWrapperFunction::callableFunction const): Deleted.
2964         (JSC::WebAssemblyWrapperFunction::function): Deleted.
2965
2966 2017-10-12  Per Arne Vollan  <pvollan@apple.com>
2967
2968         [Win64] JSC compile error.
2969         https://bugs.webkit.org/show_bug.cgi?id=178213
2970
2971         Reviewed by Alex Christensen.
2972
2973         Add static cast from int64 to uintptr_t.
2974
2975         * dfg/DFGOSRExit.cpp:
2976         (JSC::DFG::OSRExit::executeOSRExit):
2977
2978 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
2979
2980         Enable gigacage on iOS
2981         https://bugs.webkit.org/show_bug.cgi?id=177586
2982
2983         Reviewed by JF Bastien.
2984
2985         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
2986         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
2987         have Gigacage. So, this teaches ARM64 how to load from global variables.
2988         
2989         Also, this makes the code handle disabling the gigacage a bit better.
2990
2991         * ftl/FTLLowerDFGToB3.cpp:
2992         (JSC::FTL::DFG::LowerDFGToB3::caged):
2993         * jit/AssemblyHelpers.h:
2994         (JSC::AssemblyHelpers::cage):
2995         (JSC::AssemblyHelpers::cageConditionally):
2996         * offlineasm/arm64.rb:
2997         * offlineasm/asm.rb:
2998         * offlineasm/instructions.rb:
2999
3000 2017-10-11  Sam Weinig  <sam@webkit.org>
3001
3002         Remove out-parameter variants of copyToVector
3003         https://bugs.webkit.org/show_bug.cgi?id=178155
3004
3005         Reviewed by Tim Horton.
3006
3007         * inspector/ScriptDebugServer.cpp:
3008         (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
3009         (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
3010         (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
3011         (Inspector::ScriptDebugServer::dispatchDidParseSource):
3012         (Inspector::ScriptDebugServer::dispatchFailedToParseSource):
3013         (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
3014             
3015             Replace out-parameter based copyToVector, with one that returns a Vector.
3016
3017 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
3018
3019         Support integrity="" on module scripts
3020         https://bugs.webkit.org/show_bug.cgi?id=177959
3021
3022         Reviewed by Sam Weinig.
3023
3024         This patch adds Subresource Integrity check for module scripts. Currently,
3025         only top-level module can be verified with integrity parameter since there
3026         is no way to perform integrity check onto the imported modules.
3027
3028         In JSC side, we add `parameters` to the entry point of the module loader
3029         pipeline. This is fetching parameters and used when fetching modules.
3030
3031         We separately pass this parameters to the pipeline along with the script fetcher.
3032         The script fetcher is only one for module graph since this is the initiator of
3033         this module graph loading. On the other hand, this parameters is for each
3034         module fetching. While setting "integrity" parameters to this script fetcher is
3035         sufficient to pass parameters to top-level-module's fetching, it is not enough
3036         for the future extension.
3037
3038         In the future, we will investigate a way to pass parameters to each non-top-level
3039         module. At that time, this `parameters` should be per-module. This is because
3040         "integrity" value should be different for each module. For example, we will accept
3041         some form of syntax to add parameters to `import`. Some proposed syntax is like
3042         https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861
3043
3044         import "./xxx.js" integrity "xxxxxxx"
3045
3046         In this case, this `parameters` will be passed to "./xxx.js" module fetching. This
3047         `parameters` should be different from the one of top-level-module's one. That's why
3048         we need per-module `parameters` and why this patch adds `parameters` to the module pipeline.
3049
3050         On the other hand, we also want to keep script fetcher. This `per-module-graph` thing
3051         is important to offer module-graph-wide information. For example, import.meta would
3052         have `import.meta.scriptElement`, which is the script element fetching the module graph
3053         including this. So, we keep the both, script fetcher and parameters.
3054         https://github.com/tc39/proposal-import-meta
3055
3056         This parameters will be finally used by pipeline's fetch hook, and WebCore side
3057         can use this parameters to fetch modules.
3058
3059         We also further clean up the module pipeline by dropping unnecessary features.
3060
3061         * JavaScriptCore.xcodeproj/project.pbxproj:
3062         * Sources.txt:
3063         * builtins/ModuleLoaderPrototype.js:
3064         (requestFetch):
3065         (requestInstantiate):
3066         (requestSatisfy):
3067         (loadModule):
3068         (loadAndEvaluateModule):
3069         This loadAndEvaluateModule should be implemented by just calling loadModule and
3070         linkAndEvaluateModule. We can drop requestReady and requestLink.
3071
3072         (requestLink): Deleted.
3073         (requestImportModule): Deleted.
3074         * jsc.cpp:
3075         (GlobalObject::moduleLoaderImportModule):
3076         (GlobalObject::moduleLoaderFetch):
3077         import and fetch hook takes parameters. Currently, we always pass `undefined` for
3078         import hook. When dynamic `import()` is extended to accept additional parameters
3079         like integrity, this parameters will be replaced with the actual value.
3080
3081         (functionLoadModule):
3082         (runWithOptions):
3083         * runtime/Completion.cpp:
3084         (JSC::loadAndEvaluateModule):
3085         (JSC::loadModule):
3086         (JSC::importModule):
3087         * runtime/Completion.h:
3088         * runtime/JSGlobalObject.h:
3089         * runtime/JSGlobalObjectFunctions.cpp:
3090         (JSC::globalFuncImportModule):
3091         * runtime/JSModuleLoader.cpp:
3092         (JSC::JSModuleLoader::loadAndEvaluateModule):
3093         (JSC::JSModuleLoader::loadModule):
3094         (JSC::JSModuleLoader::requestImportModule):
3095         (JSC::JSModuleLoader::importModule):
3096         (JSC::JSModuleLoader::fetch):
3097         * runtime/JSModuleLoader.h:
3098         * runtime/JSScriptFetchParameters.cpp: Added.
3099         (JSC::JSScriptFetchParameters::destroy):
3100         * runtime/JSScriptFetchParameters.h: Added.
3101         (JSC::JSScriptFetchParameters::createStructure):
3102         (JSC::JSScriptFetchParameters::create):
3103         (JSC::JSScriptFetchParameters::parameters const):
3104         (JSC::JSScriptFetchParameters::JSScriptFetchParameters):
3105         Add ScriptFetchParameters' JSCell wrapper, JSScriptFetchParameters.
3106         It is used in the module pipeline.
3107
3108         * runtime/JSType.h:
3109         * runtime/ModuleLoaderPrototype.cpp:
3110         (JSC::moduleLoaderPrototypeFetch):
3111         * runtime/ScriptFetchParameters.h: Added.
3112         (JSC::ScriptFetchParameters::~ScriptFetchParameters):
3113         Add ScriptFetchParameters. We can define our own custom ScriptFetchParameters
3114         by inheriting this class. WebCore creates ModuleFetchParameters by inheriting
3115         this.
3116
3117         * runtime/VM.cpp:
3118         (JSC::VM::VM):
3119         * runtime/VM.h:
3120
3121 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
3122
3123         import.meta should not be assignable
3124         https://bugs.webkit.org/show_bug.cgi?id=178202
3125
3126         Reviewed by Saam Barati.
3127
3128         `import.meta` cannot be used for LHS. This patch adds MetaPropertyNode
3129         and make NewTargetNode and ImportMetaNode as derived classes of MetaPropertyNode.
3130         We change the parser not to allow assignments for MetaPropertyNode.
3131
3132         * bytecompiler/NodesCodegen.cpp:
3133         (JSC::ImportMetaNode::emitBytecode):
3134         * parser/ASTBuilder.h:
3135         (JSC::ASTBuilder::createImportMetaExpr):
3136         (JSC::ASTBuilder::isMetaProperty):
3137         (JSC::ASTBuilder::isImportMeta):
3138         * parser/NodeConstructors.h:
3139         (JSC::MetaPropertyNode::MetaPropertyNode):
3140         (JSC::NewTargetNode::NewTargetNode):
3141         (JSC::ImportMetaNode::ImportMetaNode):
3142         * parser/Nodes.h:
3143         (JSC::ExpressionNode::isMetaProperty const):
3144         (JSC::ExpressionNode::isImportMeta const):
3145         * parser/Parser.cpp:
3146         (JSC::Parser<LexerType>::metaPropertyName):
3147         (JSC::Parser<LexerType>::parseAssignmentExpression):
3148         (JSC::Parser<LexerType>::parseMemberExpression):
3149         (JSC::Parser<LexerType>::parseUnaryExpression):
3150         * parser/Parser.h:
3151         * parser/SyntaxChecker.h:
3152         (JSC::SyntaxChecker::createImportMetaExpr):
3153         (JSC::SyntaxChecker::isMetaProperty):
3154         (JSC::SyntaxChecker::isImportMeta):
3155
3156 2017-10-11  Saam Barati  <sbarati@apple.com>
3157
3158         Runtime disable poly proto because it may be a 3-4% Speedometer regression
3159         https://bugs.webkit.org/show_bug.cgi?id=178192
3160
3161         Reviewed by JF Bastien.
3162
3163         * runtime/Options.h:
3164         * runtime/StructureInlines.h:
3165         (JSC::Structure::shouldConvertToPolyProto):
3166
3167 2017-10-11  Commit Queue  <commit-queue@webkit.org>
3168
3169         Unreviewed, rolling out r223113 and r223121.
3170         https://bugs.webkit.org/show_bug.cgi?id=178182
3171
3172         Reintroduced 20% regression on Kraken (Requested by rniwa on
3173         #webkit).
3174
3175         Reverted changesets:
3176
3177         "Enable gigacage on iOS"
3178         https://bugs.webkit.org/show_bug.cgi?id=177586
3179         https://trac.webkit.org/changeset/223113
3180
3181         "Use one virtual allocation for all gigacages and their
3182         runways"
3183         https://bugs.webkit.org/show_bug.cgi?id=178050
3184         https://trac.webkit.org/changeset/223121
3185
3186 2017-10-11  Michael Saboff  <msaboff@apple.com>
3187
3188         Update JavaScriptCore/ucd/CaseFolding.txt to Unicode database 10.0
3189         https://bugs.webkit.org/show_bug.cgi?id=178106
3190
3191         Reviewed by Keith Miller.
3192
3193         * ucd/CaseFolding.txt:
3194
3195 2017-10-11  Caio Lima  <ticaiolima@gmail.com>
3196
3197         Object properties are undefined in super.call() but not in this.call()
3198         https://bugs.webkit.org/show_bug.cgi?id=177230
3199
3200         Reviewed by Saam Barati.
3201
3202         Bytecode generation for "super.call(...)" or "super.apply(...)"
3203         shouldn't be considered as CallFunctionCallDotNode or
3204         ApplyFunctionCallDotNode because they should be considered as common
3205         super property access as any other function. According to spec[1],
3206         "super" is not refering to parent constructor.
3207
3208         [1] - https://tc39.github.io/ecma262/#sec-super-keyword-runtime-semantics-evaluation
3209
3210         * parser/ASTBuilder.h:
3211         (JSC::ASTBuilder::makeFunctionCallNode):
3212         * parser/Parser.cpp:
3213         (JSC::Parser<LexerType>::parseMemberExpression):
3214         * parser/SyntaxChecker.h:
3215         (JSC::SyntaxChecker::makeFunctionCallNode):
3216
3217 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
3218
3219         [JSC] Drop Instantiate hook in ES6 module loader
3220         https://bugs.webkit.org/show_bug.cgi?id=178162
3221
3222         Reviewed by Sam Weinig.
3223
3224         This patch is a part of patch series for module loader refactoring to adopt
3225         integrity="" parameters and introduce new whatwg module import mechanism.
3226
3227         In this patch, we drop instantiate hook in module loader. This hook is originally
3228         introduced because it is defined in whatwg/loader spec. But this hook is not
3229         used in our implementation, and this hook won't be used since (1) whatwg/loader
3230         spec is abandoned, and (2) this type of hooks should be done in Service Workers.
3231
3232         In addition, this patch applies some cleaning up of our module loader JS code
3233         to simplify things. This change paves the way to more efficient loader implementation
3234         with great flexibility to adopt integrity="" parameters.
3235
3236         * builtins/ModuleLoaderPrototype.js:
3237         (requestInstantiate):
3238         (provideFetch):
3239         provide is changed to provideFetch since we only used this function with Fetch stage parameter.
3240
3241         (fulfillInstantiate): Deleted.
3242         (commitInstantiated): Deleted.
3243         (instantiation): Deleted.
3244         They are merged into requestInstantiate code. This is simpler.
3245
3246         (provide): Deleted.
3247         * jsc.cpp:
3248         * runtime/Completion.cpp:
3249         (JSC::loadAndEvaluateModule):
3250         (JSC::loadModule):
3251         * runtime/JSGlobalObject.cpp:
3252         * runtime/JSGlobalObject.h:
3253         * runtime/JSModuleLoader.cpp:
3254         (JSC::JSModuleLoader::provideFetch):
3255         (JSC::JSModuleLoader::provide): Deleted.
3256         Changed to provideFetch.
3257
3258         (JSC::JSModuleLoader::instantiate): Deleted.
3259         Drop this hook.
3260
3261         * runtime/JSModuleLoader.h:
3262         * runtime/ModuleLoaderPrototype.cpp:
3263         (JSC::moduleLoaderPrototypeInstantiate): Deleted.
3264         Drop this hook.
3265
3266 2017-10-10  Saam Barati  <sbarati@apple.com>
3267
3268         Prototype structure transition should be a deferred transition
3269         https://bugs.webkit.org/show_bug.cgi?id=177734
3270
3271         Reviewed by Keith Miller.
3272
3273         Absence ObjectPropertyConditions work by verifying both that the Structure 
3274         does not have a particular property and that its prototype has
3275         remained constant. However, the prototype transition was firing
3276         the transition watchpoint before setting the object's structure.
3277         This meant that isValid for Absence would never return false because
3278         the prototype changed. Clearly this is wrong. The reason this didn't
3279         break OPCs in general is that we'd also check if we could still watch
3280         the OPC. In this case, we can't still watch it because we're inspecting
3281         a structure with an invalidated transition watchpoint. To fix
3282         this weird quirk of the code, I'm making it so that doing a prototype
3283         transition uses the DeferredStructureTransitionWatchpointFire machinery.
3284         
3285         This patch also fixes some dead code that I left in regarding
3286         poly proto in OPC.
3287
3288         * bytecode/PropertyCondition.cpp:
3289         (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
3290         * runtime/JSObject.cpp:
3291         (JSC::JSObject::setPrototypeDirect):
3292         * runtime/Structure.cpp:
3293         (JSC::Structure::changePrototypeTransition):
3294         * runtime/Structure.h:
3295
3296 2017-10-10  Robin Morisset  <rmorisset@apple.com>
3297
3298         Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining()
3299         https://bugs.webkit.org/show_bug.cgi?id=177926
3300
3301         Reviewed by Saam Barati.
3302
3303         When doing polyvariant inlining, there used to be a landing block for each callee, each of which was then linked to a continuation block.
3304         With this change, we allocate the continuation block first, and pass it to the inlining routine so that op_ret in the callee link directly to it.
3305         The only subtlety is that when inlining an intrinsic we must do the jump by hand, and also remember to call processSetLocalQueue with nextOffset before it.
3306
3307         * dfg/DFGByteCodeParser.cpp:
3308         (JSC::DFG::ByteCodeParser::inlineCall):
3309         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
3310         (JSC::DFG::ByteCodeParser::handleInlining):
3311         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
3312         (JSC::DFG::ByteCodeParser::parse):
3313
3314 2017-10-10  Guillaume Emont  <guijemont@igalia.com>
3315
3316         Fix compilation when MASM_PROBE (and therefore DFG) are disabled
3317         https://bugs.webkit.org/show_bug.cgi?id=178134
3318
3319         Reviewed by Saam Barati.
3320
3321         * bytecode/CodeBlock.cpp:
3322         * bytecode/CodeBlock.h:
3323         Disable some code when building without DFG_JIT.
3324
3325 2017-10-10  Sam Weinig  <sam@webkit.org>
3326
3327         Replace copyKeysToVector/copyValuesToVector with copyToVector(map.keys())/copyToVector(map.values())
3328         https://bugs.webkit.org/show_bug.cgi?id=178102
3329
3330         Reviewed by Tim Horton.
3331
3332         * inspector/agents/InspectorDebuggerAgent.cpp:
3333         (Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState):
3334
3335 2017-10-10  Michael Saboff  <msaboff@apple.com>
3336
3337         Unreviewed build fix.
3338
3339         Removed unused lambda capture.
3340
3341         * yarr/YarrPattern.cpp:
3342         (JSC::Yarr::CharacterClassConstructor::appendInverted):
3343
3344 2017-10-10  Saam Barati  <sbarati@apple.com>
3345
3346         The prototype cache should be aware of the Executable it generates a Structure for
3347         https://bugs.webkit.org/show_bug.cgi?id=177907
3348