Invalid DFG JIT genereation in high CPU usage state
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-05-08  Yusuke Suzuki  <ysuzuki@apple.com>
2
3         Invalid DFG JIT genereation in high CPU usage state
4         https://bugs.webkit.org/show_bug.cgi?id=197453
5
6         Reviewed by Saam Barati.
7
8         We have a DFG graph like this.
9
10             a: JSConstant(rope JSString)
11             b: CheckStringIdent(Check:StringUse:@a)
12             ... AI think this is unreachable ...
13
14         When executing StringUse edge filter onto @a, AbstractValue::filterValueByType clears AbstractValue and makes it None.
15         This is because @a constant produces SpecString (SpecStringVar | SpecStringIdent) while StringUse edge filter requires
16         SpecStringIdent. AbstractValue::filterValueByType has an assumption that the JS constant always produces the same
17         SpeculatedType. So it clears AbstractValue completely.
18         But this assumption is wrong. JSString can produce SpecStringIdent later if the string is resolved to AtomicStringImpl.
19         AI think that we always fail. But once the string is resolved to AtomicStringImpl, we pass this check. So we execute
20         the breakpoint emitted by DFG since DFG think this is unreachable.
21
22         In this patch, we just clear the `m_value` if AbstractValue type filter fails with the held constant, since the constant
23         may produce a narrower type which can meet the type filter later.
24
25         * dfg/DFGAbstractValue.cpp:
26         (JSC::DFG::AbstractValue::filterValueByType):
27
28 2019-05-08  Robin Morisset  <rmorisset@apple.com>
29
30         All prototypes should call didBecomePrototype()
31         https://bugs.webkit.org/show_bug.cgi?id=196315
32
33         Reviewed by Saam Barati.
34
35         This changelog already landed, but the commit was missing the actual changes.
36
37         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
38
39         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
40         create structures with invalid prototypes.
41         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
42         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
43
44         * runtime/BigIntPrototype.cpp:
45         (JSC::BigIntPrototype::finishCreation):
46         * runtime/BooleanPrototype.cpp:
47         (JSC::BooleanPrototype::finishCreation):
48         * runtime/DatePrototype.cpp:
49         (JSC::DatePrototype::finishCreation):
50         * runtime/ErrorConstructor.cpp:
51         (JSC::ErrorConstructor::finishCreation):
52         * runtime/ErrorPrototype.cpp:
53         (JSC::ErrorPrototype::finishCreation):
54         * runtime/FunctionConstructor.cpp:
55         (JSC::FunctionConstructor::finishCreation):
56         * runtime/FunctionPrototype.cpp:
57         (JSC::FunctionPrototype::finishCreation):
58         * runtime/IntlCollatorPrototype.cpp:
59         (JSC::IntlCollatorPrototype::finishCreation):
60         * runtime/IntlDateTimeFormatPrototype.cpp:
61         (JSC::IntlDateTimeFormatPrototype::finishCreation):
62         * runtime/IntlNumberFormatPrototype.cpp:
63         (JSC::IntlNumberFormatPrototype::finishCreation):
64         * runtime/IntlPluralRulesPrototype.cpp:
65         (JSC::IntlPluralRulesPrototype::finishCreation):
66         * runtime/JSArrayBufferPrototype.cpp:
67         (JSC::JSArrayBufferPrototype::finishCreation):
68         * runtime/JSDataViewPrototype.cpp:
69         (JSC::JSDataViewPrototype::finishCreation):
70         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
71         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
72         * runtime/JSGlobalObject.cpp:
73         (JSC::createConsoleProperty):
74         * runtime/JSPromisePrototype.cpp:
75         (JSC::JSPromisePrototype::finishCreation):
76         * runtime/JSTypedArrayViewConstructor.cpp:
77         (JSC::JSTypedArrayViewConstructor::finishCreation):
78         * runtime/JSTypedArrayViewPrototype.cpp:
79         (JSC::JSTypedArrayViewPrototype::finishCreation):
80         * runtime/NumberPrototype.cpp:
81         (JSC::NumberPrototype::finishCreation):
82         * runtime/RegExpPrototype.cpp:
83         (JSC::RegExpPrototype::finishCreation):
84         * runtime/StringPrototype.cpp:
85         (JSC::StringPrototype::finishCreation):
86         * runtime/Structure.cpp:
87         (JSC::Structure::isValidPrototype):
88         (JSC::Structure::changePrototypeTransition):
89         * runtime/Structure.h:
90         * runtime/SymbolPrototype.cpp:
91         (JSC::SymbolPrototype::finishCreation):
92         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
93         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
94         * wasm/js/WebAssemblyInstancePrototype.cpp:
95         (JSC::WebAssemblyInstancePrototype::finishCreation):
96         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
97         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
98         * wasm/js/WebAssemblyMemoryPrototype.cpp:
99         (JSC::WebAssemblyMemoryPrototype::finishCreation):
100         * wasm/js/WebAssemblyModulePrototype.cpp:
101         (JSC::WebAssemblyModulePrototype::finishCreation):
102         * wasm/js/WebAssemblyPrototype.cpp:
103         (JSC::WebAssemblyPrototype::finishCreation):
104         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
105         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
106         * wasm/js/WebAssemblyTablePrototype.cpp:
107         (JSC::WebAssemblyTablePrototype::finishCreation):
108
109 2019-05-08  Keith Miller  <keith_miller@apple.com>
110
111         Remove Gigacage from arm64 and use PAC for arm64e instead
112         https://bugs.webkit.org/show_bug.cgi?id=197110
113
114         Reviewed by Saam Barati.
115
116         This patch makes a bunch of changes. I'll start with global changes then go over changes to each tier and finish with bug fixes.
117
118         Global Changes:
119         Change CagedBarrierPtr to work with PAC so constructors and accessors now expect to receive a length.
120         Update assembler helper methods to use do PAC when caging.
121
122         LLInt:
123         Add arm64e.rb backend as we missed that when originally open sourcing our arm64e code.
124         Add a new optional t6 temporary, which is only used currently on arm64e for GetByVal on a TypedArray.
125         Refactor caging into two helper macros for Primitive/JSValue cages.
126
127         Baseline/DFG:
128         Add authentication where needed for GetByVal and inline object construction.
129
130         FTL:
131         Add a new ValueRep that allows for a late register use. We want this for the authentication patchpoint since we use the length register at the same time as we are defing the authenticated pointer.
132
133         Wasm:
134         Use the TaggedArrayStoragePtr class for the memory base pointer. In theory we should be caging those pointers but I don't want to risk introducing a performance regression with the rest of this change. I've filed https://bugs.webkit.org/show_bug.cgi?id=197620 to do this later.
135         As we no longer have the Gigacage using most of our VA memory, we can enable fast memories on iOS.
136         Using fast memories leads to roughly a 2% JetStream2 speedup.
137
138         * assembler/MacroAssemblerARM64E.h:
139         (JSC::MacroAssemblerARM64E::tagArrayPtr):
140         (JSC::MacroAssemblerARM64E::untagArrayPtr):
141         (JSC::MacroAssemblerARM64E::removeArrayPtrTag):
142         * b3/B3LowerToAir.cpp:
143         * b3/B3PatchpointSpecial.cpp:
144         (JSC::B3::PatchpointSpecial::admitsStack):
145         * b3/B3StackmapSpecial.cpp:
146         (JSC::B3::StackmapSpecial::forEachArgImpl):
147         (JSC::B3::StackmapSpecial::isArgValidForRep):
148         * b3/B3Validate.cpp:
149         * b3/B3ValueRep.cpp:
150         (JSC::B3::ValueRep::addUsedRegistersTo const):
151         (JSC::B3::ValueRep::dump const):
152         (WTF::printInternal):
153         * b3/B3ValueRep.h:
154         (JSC::B3::ValueRep::ValueRep):
155         (JSC::B3::ValueRep::isReg const):
156         * dfg/DFGOperations.cpp:
157         (JSC::DFG::newTypedArrayWithSize):
158         * dfg/DFGSpeculativeJIT.cpp:
159         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
160         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
161         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
162         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
163         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
164         * dfg/DFGSpeculativeJIT.h:
165         * dfg/DFGSpeculativeJIT64.cpp:
166         (JSC::DFG::SpeculativeJIT::compile):
167         * ftl/FTLLowerDFGToB3.cpp:
168         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
169         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
170         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
171         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
172         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
173         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
174         (JSC::FTL::DFG::LowerDFGToB3::caged):
175         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
176         * jit/AssemblyHelpers.h:
177         (JSC::AssemblyHelpers::cageConditionally):
178         * jit/IntrinsicEmitter.cpp:
179         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
180         * jit/JITPropertyAccess.cpp:
181         (JSC::JIT::emitDirectArgumentsGetByVal):
182         (JSC::JIT::emitIntTypedArrayGetByVal):
183         (JSC::JIT::emitFloatTypedArrayGetByVal):
184         (JSC::JIT::emitIntTypedArrayPutByVal):
185         (JSC::JIT::emitFloatTypedArrayPutByVal):
186         * jit/PolymorphicCallStubRoutine.cpp:
187         (JSC::PolymorphicCallNode::clearCallLinkInfo):
188         * llint/LowLevelInterpreter64.asm:
189         * offlineasm/arm64.rb:
190         * offlineasm/arm64e.rb: Added.
191         * offlineasm/ast.rb:
192         * offlineasm/instructions.rb:
193         * offlineasm/registers.rb:
194         * offlineasm/x86.rb:
195         * runtime/ArrayBuffer.cpp:
196         (JSC::SharedArrayBufferContents::SharedArrayBufferContents):
197         (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
198         (JSC::ArrayBufferContents::ArrayBufferContents):
199         (JSC::ArrayBufferContents::destroy):
200         (JSC::ArrayBufferContents::tryAllocate):
201         (JSC::ArrayBufferContents::makeShared):
202         (JSC::ArrayBufferContents::copyTo):
203         * runtime/ArrayBuffer.h:
204         (JSC::SharedArrayBufferContents::data const):
205         (JSC::ArrayBufferContents::data const):
206         (JSC::ArrayBuffer::data):
207         (JSC::ArrayBuffer::data const):
208         (JSC::ArrayBuffer::byteLength const):
209         * runtime/ArrayBufferView.cpp:
210         (JSC::ArrayBufferView::ArrayBufferView):
211         * runtime/ArrayBufferView.h:
212         (JSC::ArrayBufferView::baseAddress const):
213         (JSC::ArrayBufferView::byteLength const):
214         (JSC::ArrayBufferView::setRangeImpl):
215         (JSC::ArrayBufferView::getRangeImpl):
216         * runtime/CachedTypes.cpp:
217         (JSC::CachedScopedArgumentsTable::encode):
218         (JSC::CachedScopedArgumentsTable::decode const):
219         * runtime/CagedBarrierPtr.h:
220         (JSC::CagedBarrierPtr::CagedBarrierPtr):
221         (JSC::CagedBarrierPtr::set):
222         (JSC::CagedBarrierPtr::get const):
223         (JSC::CagedBarrierPtr::getMayBeNull const):
224         (JSC::CagedBarrierPtr::getUnsafe const):
225         (JSC::CagedBarrierPtr::at const):
226         (JSC::CagedBarrierPtr::operator== const):
227         (JSC::CagedBarrierPtr::operator bool const):
228         (JSC::CagedBarrierPtr::setWithoutBarrier):
229         (JSC::CagedBarrierPtr::operator* const): Deleted.
230         (JSC::CagedBarrierPtr::operator-> const): Deleted.
231         (JSC::CagedBarrierPtr::operator[] const): Deleted.
232         (): Deleted.
233         * runtime/DataView.cpp:
234         (JSC::DataView::DataView):
235         * runtime/DataView.h:
236         (JSC::DataView::get):
237         (JSC::DataView::set):
238         * runtime/DirectArguments.cpp:
239         (JSC::DirectArguments::visitChildren):
240         (JSC::DirectArguments::overrideThings):
241         (JSC::DirectArguments::unmapArgument):
242         * runtime/DirectArguments.h:
243         * runtime/GenericArguments.h:
244         * runtime/GenericArgumentsInlines.h:
245         (JSC::GenericArguments<Type>::visitChildren):
246         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
247         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
248         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
249         * runtime/GenericTypedArrayView.h:
250         * runtime/GenericTypedArrayViewInlines.h:
251         (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
252         * runtime/JSArrayBufferView.cpp:
253         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
254         (JSC::JSArrayBufferView::JSArrayBufferView):
255         (JSC::JSArrayBufferView::finalize):
256         (JSC::JSArrayBufferView::slowDownAndWasteMemory):
257         * runtime/JSArrayBufferView.h:
258         (JSC::JSArrayBufferView::ConstructionContext::vector const):
259         (JSC::JSArrayBufferView::isNeutered):
260         (JSC::JSArrayBufferView::hasVector const):
261         (JSC::JSArrayBufferView::vector const):
262         * runtime/JSGenericTypedArrayViewInlines.h:
263         (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
264         (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
265         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
266         * runtime/Options.h:
267         * runtime/ScopedArgumentsTable.cpp:
268         (JSC::ScopedArgumentsTable::clone):
269         (JSC::ScopedArgumentsTable::setLength):
270         * runtime/ScopedArgumentsTable.h:
271         * runtime/SymbolTable.h:
272         * wasm/WasmAirIRGenerator.cpp:
273         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
274         (JSC::Wasm::AirIRGenerator::addCallIndirect):
275         * wasm/WasmB3IRGenerator.cpp:
276         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
277         (JSC::Wasm::B3IRGenerator::addCallIndirect):
278         * wasm/WasmBBQPlan.cpp:
279         (JSC::Wasm::BBQPlan::complete):
280         * wasm/WasmBinding.cpp:
281         (JSC::Wasm::wasmToWasm):
282         * wasm/WasmInstance.h:
283         (JSC::Wasm::Instance::cachedMemory const):
284         (JSC::Wasm::Instance::updateCachedMemory):
285         * wasm/WasmMemory.cpp:
286         (JSC::Wasm::Memory::Memory):
287         (JSC::Wasm::Memory::~Memory):
288         (JSC::Wasm::Memory::grow):
289         (JSC::Wasm::Memory::dump const):
290         * wasm/WasmMemory.h:
291         (JSC::Wasm::Memory::memory const):
292         * wasm/js/JSToWasm.cpp:
293         (JSC::Wasm::createJSToWasmWrapper):
294         * wasm/js/WebAssemblyFunction.cpp:
295         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
296
297 2019-05-08  Caio Lima  <ticaiolima@gmail.com>
298
299         [BigInt] Add ValueMod into DFG
300         https://bugs.webkit.org/show_bug.cgi?id=186174
301
302         Reviewed by Saam Barati.
303
304         This patch is introducing a new DFG node called ValueMod, that is
305         responsible to handle BigInt and Untyped specialization of op_mod.
306         With the introduction of BigInt, we think that cases with
307         ValueMod(Untyped, Untyped) can be more common and we introduced
308         support for such kind of node.
309
310         * dfg/DFGAbstractInterpreter.h:
311         * dfg/DFGAbstractInterpreterInlines.h:
312         (JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantDivOp):
313
314         We are abstracting the constant rules of division operations. It
315         includes ArithDiv, ValueDiv, ArithMod and ValueMod, since they perform
316         the same analysis.
317
318         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
319         * dfg/DFGBackwardsPropagationPhase.cpp:
320         (JSC::DFG::BackwardsPropagationPhase::propagate):
321         * dfg/DFGByteCodeParser.cpp:
322         (JSC::DFG::ByteCodeParser::makeSafe):
323         (JSC::DFG::ByteCodeParser::parseBlock):
324
325         Here we check if lhs and rhs have number result to emit ArithMod.
326         Otherwise, we need to fallback to ValueMod and let fixup replace this
327         operation when possible.
328
329         * dfg/DFGClobberize.h:
330         (JSC::DFG::clobberize):
331
332         ValueMod(BigIntUse) doesn't clobberize world because it only calls
333         `operationModBigInt`.
334
335         * dfg/DFGDoesGC.cpp:
336         (JSC::DFG::doesGC):
337
338         ValueMod(BigIntUse) can trigger GC since it allocates intermediate
339         JSBigInt to perform calculation. ValueMod(UntypedUse) can trigger GC
340         because it can execute arbritary code from user.
341
342         * dfg/DFGFixupPhase.cpp:
343         (JSC::DFG::FixupPhase::fixupArithDivInt32):
344
345         Function created to simplify readability of ArithDiv/AirthMod fixup
346         operation.
347
348         (JSC::DFG::FixupPhase::fixupArithDiv):
349         (JSC::DFG::FixupPhase::fixupNode):
350
351         Following the same fixup rules of ArithDiv.
352
353         * dfg/DFGNodeType.h:
354         * dfg/DFGOperations.cpp:
355         (JSC::DFG::binaryOp):
356         * dfg/DFGOperations.h:
357         * dfg/DFGPredictionPropagationPhase.cpp:
358
359         ValueMod follows the same prediction propagation rules of ArithMod and
360         the same rules for `doDoubleVoting`.
361
362         * dfg/DFGSafeToExecute.h:
363         (JSC::DFG::safeToExecute):
364         * dfg/DFGSpeculativeJIT.cpp:
365         (JSC::DFG::SpeculativeJIT::compileValueMod):
366         * dfg/DFGSpeculativeJIT.h:
367         * dfg/DFGSpeculativeJIT32_64.cpp:
368         (JSC::DFG::SpeculativeJIT::compile):
369         * dfg/DFGSpeculativeJIT64.cpp:
370         (JSC::DFG::SpeculativeJIT::compile):
371         * dfg/DFGValidate.cpp:
372         * ftl/FTLCapabilities.cpp:
373         (JSC::FTL::canCompile):
374         * ftl/FTLLowerDFGToB3.cpp:
375         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
376         (JSC::FTL::DFG::LowerDFGToB3::compileValueMod):
377
378 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
379
380         [JSC] DFG_ASSERT failed in lowInt52
381         https://bugs.webkit.org/show_bug.cgi?id=197569
382
383         Reviewed by Saam Barati.
384
385         GetStack with FlushedInt52 should load the flushed value in Int52 form and put the result in m_int52Values / m_strictInt52Values. Previously,
386         we load it in JSValue / Int32 form and lowInt52 fails to get appropriate one since GetStack does not put the result in m_int52Values / m_strictInt52Values.
387
388         * ftl/FTLLowerDFGToB3.cpp:
389         (JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
390
391 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
392
393         [JSC] LLIntPrototypeLoadAdaptiveStructureWatchpoint does not require Bag<>
394         https://bugs.webkit.org/show_bug.cgi?id=197645
395
396         Reviewed by Saam Barati.
397
398         We are using HashMap<std::tuple<Structure*, const Instruction*>, Bag<LLIntPrototypeLoadAdaptiveStructureWatchpoint>> for LLIntPrototypeLoadAdaptiveStructureWatchpoint,
399         but this has several memory inefficiency.
400
401         1. Structure* and Instruction* are too large. We can just use StructureID and bytecodeOffset (unsigned).
402         2. While we are using Bag<>, we do not add a new LLIntPrototypeLoadAdaptiveStructureWatchpoint after constructing this Bag first. So we can
403            use Vector<LLIntPrototypeLoadAdaptiveStructureWatchpoint> instead. We ensure that new entry won't be added to this Vector by making Watchpoint
404            non-movable.
405         3. Instead of having OpGetById::Metadata&, we just hold `unsigned` bytecodeOffset, and get Metadata& from the owner CodeBlock when needed.
406
407         * bytecode/CodeBlock.cpp:
408         (JSC::CodeBlock::finalizeLLIntInlineCaches):
409         * bytecode/CodeBlock.h:
410         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
411         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
412         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
413         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
414         * bytecode/Watchpoint.h:
415         * llint/LLIntSlowPaths.cpp:
416         (JSC::LLInt::setupGetByIdPrototypeCache):
417
418 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
419
420         JSC: A bug in BytecodeGenerator::emitEqualityOpImpl
421         https://bugs.webkit.org/show_bug.cgi?id=197479
422
423         Reviewed by Saam Barati.
424
425         Our peephole optimization in BytecodeGenerator is (1) rewinding the previous instruction and (2) emit optimized instruction instead.
426         If we have jump target between the previous instruction and the subsequent instruction, this peephole optimization breaks the jump target.
427         To prevent it, we had a mechanism disabling peephole optimization, setting m_lastOpcodeID = op_end and checking m_lastOpcodeID when performing
428         peephole optimization. However, BytecodeGenerator::emitEqualityOpImpl checks `m_lastInstruction->is<OpTypeof>` instead of `m_lastOpcodeID == op_typeof`,
429         and miss `op_end` case.
430
431         This patch makes the following changes.
432
433         1. Add canDoPeepholeOptimization method to clarify the intent of `m_lastInstruction = op_end`.
434         2. Check canDoPeepholeOptimization status before performing peephole optimization in emitJumpIfTrue, emitJumpIfFalse, and emitEqualityOpImpl.
435         3. Add `ASSERT(canDoPeepholeOptimization())` in fuseCompareAndJump and fuseTestAndJmp to ensure that peephole optimization is allowed.
436
437         * bytecompiler/BytecodeGenerator.cpp:
438         (JSC::BytecodeGenerator::fuseCompareAndJump):
439         (JSC::BytecodeGenerator::fuseTestAndJmp):
440         (JSC::BytecodeGenerator::emitJumpIfTrue):
441         (JSC::BytecodeGenerator::emitJumpIfFalse):
442         (JSC::BytecodeGenerator::emitEqualityOpImpl):
443         * bytecompiler/BytecodeGenerator.h:
444         (JSC::BytecodeGenerator::canDoPeepholeOptimization const):
445
446 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
447
448         TemplateObject passed to template literal tags are not always identical for the same source location.
449         https://bugs.webkit.org/show_bug.cgi?id=190756
450
451         Reviewed by Saam Barati.
452
453         Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
454         when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
455
456         1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
457         2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
458
459         In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
460         ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
461         But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
462         which maps source locations to cached site objects.
463
464         1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
465         2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
466         3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
467         4. TemplateObjectMap is indexed with endOffset of TaggedTemplate.
468
469         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
470         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
471         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
472         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
473         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
474         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
475         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
476         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
477         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
478         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
479         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
480         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
481         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
482         * Scripts/wkbuiltins/builtins_templates.py:
483         * bytecode/CodeBlock.cpp:
484         (JSC::CodeBlock::finishCreation):
485         (JSC::CodeBlock::setConstantRegisters):
486         * bytecode/CodeBlock.h:
487         * bytecode/UnlinkedFunctionExecutable.cpp:
488         (JSC::UnlinkedFunctionExecutable::link):
489         * bytecode/UnlinkedFunctionExecutable.h:
490         * bytecompiler/BytecodeGenerator.cpp:
491         (JSC::BytecodeGenerator::addTemplateObjectConstant):
492         (JSC::BytecodeGenerator::emitGetTemplateObject):
493         * bytecompiler/BytecodeGenerator.h:
494         * parser/ASTBuilder.h:
495         (JSC::ASTBuilder::createTaggedTemplate):
496         * runtime/CachedTypes.cpp:
497         (JSC::CachedTemplateObjectDescriptor::encode):
498         (JSC::CachedTemplateObjectDescriptor::decode const):
499         (JSC::CachedJSValue::encode):
500         (JSC::CachedJSValue::decode const):
501         * runtime/EvalExecutable.cpp:
502         (JSC::EvalExecutable::ensureTemplateObjectMap):
503         (JSC::EvalExecutable::visitChildren):
504         * runtime/EvalExecutable.h:
505         * runtime/FunctionExecutable.cpp:
506         (JSC::FunctionExecutable::finishCreation):
507         (JSC::FunctionExecutable::visitChildren):
508         (JSC::FunctionExecutable::fromGlobalCode):
509         (JSC::FunctionExecutable::ensureRareDataSlow):
510         (JSC::FunctionExecutable::ensureTemplateObjectMap):
511         * runtime/FunctionExecutable.h:
512         * runtime/JSModuleRecord.cpp:
513         (JSC::JSModuleRecord::instantiateDeclarations):
514         * runtime/JSTemplateObjectDescriptor.cpp:
515         (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
516         (JSC::JSTemplateObjectDescriptor::create):
517         * runtime/JSTemplateObjectDescriptor.h:
518         * runtime/ModuleProgramExecutable.cpp:
519         (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
520         (JSC::ModuleProgramExecutable::visitChildren):
521         * runtime/ModuleProgramExecutable.h:
522         * runtime/ProgramExecutable.cpp:
523         (JSC::ProgramExecutable::ensureTemplateObjectMap):
524         (JSC::ProgramExecutable::visitChildren):
525         * runtime/ProgramExecutable.h:
526         * runtime/ScriptExecutable.cpp:
527         (JSC::ScriptExecutable::topLevelExecutable):
528         (JSC::ScriptExecutable::createTemplateObject):
529         (JSC::ScriptExecutable::ensureTemplateObjectMapImpl):
530         (JSC::ScriptExecutable::ensureTemplateObjectMap):
531         * runtime/ScriptExecutable.h:
532         * tools/JSDollarVM.cpp:
533         (JSC::functionCreateBuiltin):
534         (JSC::functionDeleteAllCodeWhenIdle):
535         (JSC::JSDollarVM::finishCreation):
536
537 2019-05-07  Robin Morisset  <rmorisset@apple.com>
538
539         [B3] Constants should be hoisted to the root block until moveConstants
540         https://bugs.webkit.org/show_bug.cgi?id=197265
541
542         Reviewed by Saam Barati.
543
544         This patch does the following:
545         - B3ReduceStrength now hoists all constants to the root BB, and de-duplicates them along the way
546         - B3PureCSE no longer bothers with constants, since they are already de-duplicated by the time it gets to see them
547         - We now run eliminateDeadCode just after moveConstants, so that the Nops that moveConstants generates are freed instead of staying live throughout Air compilation, reducing memory pressure.
548         - I also took the opportunity to fix typos in comments in various parts of the code base.
549
550         Here are a few numbers to justify this patch:
551         - In JetStream2, about 27% of values at the beginning of B3 are constants
552         - In JetStream2, about 11% of values at the end of B3 are Nops
553         - In JetStream2, this patch increases the number of times that tail duplication happens from a bit less than 24k to a bit more than 25k (hoisting constants makes blocks smaller).
554
555         When I tried measuring the total effect on JetStream2 I got a tiny and almost certainly non-significant progression.
556
557         * b3/B3Generate.cpp:
558         (JSC::B3::generateToAir):
559         * b3/B3MoveConstants.cpp:
560         * b3/B3PureCSE.cpp:
561         (JSC::B3::PureCSE::process):
562         * b3/B3PureCSE.h:
563         * b3/B3ReduceStrength.cpp:
564         * bytecode/GetByIdStatus.cpp:
565         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
566         * dfg/DFGCSEPhase.cpp:
567         * dfg/DFGOSRAvailabilityAnalysisPhase.h:
568         * dfg/DFGOSRExit.cpp:
569         (JSC::DFG::OSRExit::executeOSRExit):
570
571 2019-05-07  Robin Morisset  <rmorisset@apple.com>
572
573         All prototypes should call didBecomePrototype()
574         https://bugs.webkit.org/show_bug.cgi?id=196315
575
576         Reviewed by Saam Barati.
577
578         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
579
580         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
581         create structures with invalid prototypes.
582         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
583         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
584
585         * runtime/BigIntPrototype.cpp:
586         (JSC::BigIntPrototype::finishCreation):
587         * runtime/BooleanPrototype.cpp:
588         (JSC::BooleanPrototype::finishCreation):
589         * runtime/DatePrototype.cpp:
590         (JSC::DatePrototype::finishCreation):
591         * runtime/ErrorConstructor.cpp:
592         (JSC::ErrorConstructor::finishCreation):
593         * runtime/ErrorPrototype.cpp:
594         (JSC::ErrorPrototype::finishCreation):
595         * runtime/FunctionConstructor.cpp:
596         (JSC::FunctionConstructor::finishCreation):
597         * runtime/FunctionPrototype.cpp:
598         (JSC::FunctionPrototype::finishCreation):
599         * runtime/IntlCollatorPrototype.cpp:
600         (JSC::IntlCollatorPrototype::finishCreation):
601         * runtime/IntlDateTimeFormatPrototype.cpp:
602         (JSC::IntlDateTimeFormatPrototype::finishCreation):
603         * runtime/IntlNumberFormatPrototype.cpp:
604         (JSC::IntlNumberFormatPrototype::finishCreation):
605         * runtime/IntlPluralRulesPrototype.cpp:
606         (JSC::IntlPluralRulesPrototype::finishCreation):
607         * runtime/JSArrayBufferPrototype.cpp:
608         (JSC::JSArrayBufferPrototype::finishCreation):
609         * runtime/JSDataViewPrototype.cpp:
610         (JSC::JSDataViewPrototype::finishCreation):
611         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
612         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
613         * runtime/JSGlobalObject.cpp:
614         (JSC::createConsoleProperty):
615         * runtime/JSPromisePrototype.cpp:
616         (JSC::JSPromisePrototype::finishCreation):
617         * runtime/JSTypedArrayViewConstructor.cpp:
618         (JSC::JSTypedArrayViewConstructor::finishCreation):
619         * runtime/JSTypedArrayViewPrototype.cpp:
620         (JSC::JSTypedArrayViewPrototype::finishCreation):
621         * runtime/NumberPrototype.cpp:
622         (JSC::NumberPrototype::finishCreation):
623         * runtime/RegExpPrototype.cpp:
624         (JSC::RegExpPrototype::finishCreation):
625         * runtime/StringPrototype.cpp:
626         (JSC::StringPrototype::finishCreation):
627         * runtime/Structure.cpp:
628         (JSC::Structure::isValidPrototype):
629         (JSC::Structure::changePrototypeTransition):
630         * runtime/Structure.h:
631         * runtime/SymbolPrototype.cpp:
632         (JSC::SymbolPrototype::finishCreation):
633         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
634         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
635         * wasm/js/WebAssemblyInstancePrototype.cpp:
636         (JSC::WebAssemblyInstancePrototype::finishCreation):
637         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
638         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
639         * wasm/js/WebAssemblyMemoryPrototype.cpp:
640         (JSC::WebAssemblyMemoryPrototype::finishCreation):
641         * wasm/js/WebAssemblyModulePrototype.cpp:
642         (JSC::WebAssemblyModulePrototype::finishCreation):
643         * wasm/js/WebAssemblyPrototype.cpp:
644         (JSC::WebAssemblyPrototype::finishCreation):
645         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
646         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
647         * wasm/js/WebAssemblyTablePrototype.cpp:
648         (JSC::WebAssemblyTablePrototype::finishCreation):
649
650 2019-05-07  Robin Morisset  <rmorisset@apple.com>
651
652         WTF::BitVector should have an isEmpty() method
653         https://bugs.webkit.org/show_bug.cgi?id=197637
654
655         Reviewed by Keith Miller.
656
657         Just replaces some comparison of bitCount() to 0 by calls to isEmpty()
658
659         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
660
661 2019-05-07  Commit Queue  <commit-queue@webkit.org>
662
663         Unreviewed, rolling out r244978.
664         https://bugs.webkit.org/show_bug.cgi?id=197671
665
666         TemplateObject map should use start/end offsets (Requested by
667         yusukesuzuki on #webkit).
668
669         Reverted changeset:
670
671         "TemplateObject passed to template literal tags are not always
672         identical for the same source location."
673         https://bugs.webkit.org/show_bug.cgi?id=190756
674         https://trac.webkit.org/changeset/244978
675
676 2019-05-07  Tadeu Zagallo  <tzagallo@apple.com>
677
678         tryCachePutByID should not crash if target offset changes
679         https://bugs.webkit.org/show_bug.cgi?id=197311
680         <rdar://problem/48033612>
681
682         Reviewed by Filip Pizlo.
683
684         When tryCachePutID is called with a cacheable setter, if the target object where the setter was
685         found is still in the prototype chain and there's no poly protos in the chain, we use
686         generateConditionsForPrototypePropertyHit to validate that the target object remains the same.
687         It checks for the absence of the property in every object in the prototype chain from the base
688         down to the target object and checks that the property is still present in the target object. It
689         also bails if there are any uncacheable objects, proxies or dictionary objects in the prototype
690         chain. However, it does not consider two edge cases:
691         - It asserts that the property should still be at the same offset in the target object, but this
692         assertion does not hold if the setter deletes properties of the object and causes the structure
693         to be flattened after the deletion. Instead of asserting, we just use the updated offset.
694         - It does not check whether the new slot is also a setter, which leads to a crash in case it's not.
695
696         * jit/Repatch.cpp:
697         (JSC::tryCachePutByID):
698
699 2019-05-07  Saam Barati  <sbarati@apple.com>
700
701         Don't OSR enter into an FTL CodeBlock that has been jettisoned
702         https://bugs.webkit.org/show_bug.cgi?id=197531
703         <rdar://problem/50162379>
704
705         Reviewed by Yusuke Suzuki.
706
707         Sometimes we make silly mistakes. This is one of those times. It's invalid to OSR
708         enter into an FTL OSR entry code block that has been jettisoned already.
709
710         * dfg/DFGJITCode.cpp:
711         (JSC::DFG::JITCode::clearOSREntryBlockAndResetThresholds):
712         * dfg/DFGJITCode.h:
713         (JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
714         * dfg/DFGOSREntry.cpp:
715         (JSC::DFG::prepareOSREntry):
716         (JSC::DFG::prepareCatchOSREntry):
717         * dfg/DFGOperations.cpp:
718         * ftl/FTLOSREntry.cpp:
719         (JSC::FTL::prepareOSREntry):
720
721 2019-05-06  Keith Miller  <keith_miller@apple.com>
722
723         JSWrapperMap should check if existing prototype properties are wrappers when copying exported methods.
724         https://bugs.webkit.org/show_bug.cgi?id=197324
725         <rdar://problem/50253144>
726
727         Reviewed by Saam Barati.
728
729         The current implementation prevents using JSExport to shadow a
730         method from a super class. This was because we would only add a
731         method if the prototype didn't already claim to have the
732         property. Normally this would only happen if an Objective-C super
733         class already exported a ObjCCallbackFunction for the method,
734         however, if the user exports a property that is already on
735         Object.prototype the overriden method won't be exported.
736
737         This patch fixes the object prototype issue by checking if the
738         property on the prototype chain is an ObjCCallbackFunction, if
739         it's not then it adds an override.
740
741         * API/JSWrapperMap.mm:
742         (copyMethodsToObject):
743         * API/tests/testapi.mm:
744         (-[ToStringClass toString]):
745         (-[ToStringClass other]):
746         (-[ToStringSubclass toString]):
747         (-[ToStringSubclassNoProtocol toString]):
748         (testToString):
749         (testObjectiveCAPI):
750
751 2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
752
753         [JSC] We should check OOM for description string of Symbol
754         https://bugs.webkit.org/show_bug.cgi?id=197634
755
756         Reviewed by Keith Miller.
757
758         When resoling JSString for description of Symbol, we should check OOM error.
759         We also change JSValueMakeSymbol(..., nullptr) to returning a symbol value
760         without description, (1) to simplify the code and (2) give a way for JSC API
761         to create a symbol value without description.
762
763         * API/JSValueRef.cpp:
764         (JSValueMakeSymbol):
765         * API/tests/testapi.cpp:
766         (TestAPI::symbolsTypeof):
767         (TestAPI::symbolsDescription):
768         (testCAPIViaCpp):
769         * dfg/DFGOperations.cpp:
770         * runtime/Symbol.cpp:
771         (JSC::Symbol::createWithDescription):
772         * runtime/Symbol.h:
773         * runtime/SymbolConstructor.cpp:
774         (JSC::callSymbol):
775
776 2019-05-06  Keith Rollin  <krollin@apple.com>
777
778         Temporarily disable generate-xcfilelists
779         https://bugs.webkit.org/show_bug.cgi?id=197619
780         <rdar://problem/50507392>
781
782         Reviewed by Alex Christensen.
783
784         We need to perform a significant update to the generate-xcfilelist
785         scripts. This work involves coordinated work with another facility. If
786         the work does not occur in tandem, the build will be broken. To avoid
787         this, disable the invoking of the scripts during the transition. The
788         checking will be restored once the new scripts are in place.
789
790         * Scripts/check-xcfilelists.sh:
791
792 2019-05-06  Basuke Suzuki  <Basuke.Suzuki@sony.com>
793
794         [PlayStation] Fix build break since r244919
795         https://bugs.webkit.org/show_bug.cgi?id=197627
796
797         Reviewed by Ross Kirsling.
798
799         Bugfix for POSIX socket implementation and suppress warnings.
800
801         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
802         (Inspector::RemoteInspectorConnectionClient::didAccept):
803         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
804         (Inspector::Socket::getPort):
805
806 2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
807
808         TemplateObject passed to template literal tags are not always identical for the same source location.
809         https://bugs.webkit.org/show_bug.cgi?id=190756
810
811         Reviewed by Saam Barati.
812
813         Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
814         when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
815
816         1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
817         2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
818
819         In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
820         ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
821         But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
822         which maps source locations to cached site objects.
823
824         1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
825         2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
826         3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
827
828         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
829         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
830         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
831         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
832         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
833         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
834         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
835         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
836         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
837         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
838         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
839         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
840         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
841         * Scripts/wkbuiltins/builtins_templates.py:
842         * bytecode/CodeBlock.cpp:
843         (JSC::CodeBlock::finishCreation):
844         (JSC::CodeBlock::setConstantRegisters):
845         * bytecode/CodeBlock.h:
846         * bytecode/UnlinkedFunctionExecutable.cpp:
847         (JSC::UnlinkedFunctionExecutable::link):
848         * bytecode/UnlinkedFunctionExecutable.h:
849         * bytecompiler/BytecodeGenerator.cpp:
850         (JSC::BytecodeGenerator::addTemplateObjectConstant):
851         (JSC::BytecodeGenerator::emitGetTemplateObject):
852         * bytecompiler/BytecodeGenerator.h:
853         * runtime/CachedTypes.cpp:
854         (JSC::CachedTemplateObjectDescriptor::encode):
855         (JSC::CachedTemplateObjectDescriptor::decode const):
856         (JSC::CachedJSValue::encode):
857         (JSC::CachedJSValue::decode const):
858         * runtime/EvalExecutable.cpp:
859         (JSC::EvalExecutable::ensureTemplateObjectMap):
860         (JSC::EvalExecutable::visitChildren):
861         * runtime/EvalExecutable.h:
862         * runtime/FunctionExecutable.cpp:
863         (JSC::FunctionExecutable::finishCreation):
864         (JSC::FunctionExecutable::visitChildren):
865         (JSC::FunctionExecutable::fromGlobalCode):
866         (JSC::FunctionExecutable::ensureRareDataSlow):
867         (JSC::FunctionExecutable::ensureTemplateObjectMap):
868         * runtime/FunctionExecutable.h:
869         * runtime/JSModuleRecord.cpp:
870         (JSC::JSModuleRecord::instantiateDeclarations):
871         * runtime/JSTemplateObjectDescriptor.cpp:
872         (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
873         (JSC::JSTemplateObjectDescriptor::create):
874         * runtime/JSTemplateObjectDescriptor.h:
875         * runtime/ModuleProgramExecutable.cpp:
876         (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
877         (JSC::ModuleProgramExecutable::visitChildren):
878         * runtime/ModuleProgramExecutable.h:
879         * runtime/ProgramExecutable.cpp:
880         (JSC::ProgramExecutable::ensureTemplateObjectMap):
881         (JSC::ProgramExecutable::visitChildren):
882         * runtime/ProgramExecutable.h:
883         * runtime/ScriptExecutable.cpp:
884         (JSC::ScriptExecutable::topLevelExecutable):
885         (JSC::ScriptExecutable::createTemplateObject):
886         (JSC::ScriptExecutable::ensureTemplateObjectMap):
887         * runtime/ScriptExecutable.h:
888         * tools/JSDollarVM.cpp:
889         (JSC::functionCreateBuiltin):
890         (JSC::functionDeleteAllCodeWhenIdle):
891         (JSC::JSDollarVM::finishCreation):
892
893 2019-05-04  Tadeu Zagallo  <tzagallo@apple.com>
894
895         TypedArrays should not store properties that are canonical numeric indices
896         https://bugs.webkit.org/show_bug.cgi?id=197228
897         <rdar://problem/49557381>
898
899         Reviewed by Saam Barati.
900
901         According to the spec[1]:
902         - TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty if the index is a
903         CanonicalNumericIndexString, but invalid according to IntegerIndexedElementGet and similar
904         functions. I.e., there are a few properties that should not be set in a TypedArray, like NaN,
905         Infinity and -0.
906         - On DefineOwnProperty, the out-of-bounds check should be performed before validating the property
907         descriptor.
908         - On GetOwnProperty, the returned descriptor for numeric properties should have writable set to true.
909
910         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
911
912         * CMakeLists.txt:
913         * JavaScriptCore.xcodeproj/project.pbxproj:
914         * runtime/JSGenericTypedArrayViewInlines.h:
915         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
916         (JSC::JSGenericTypedArrayView<Adaptor>::put):
917         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
918         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
919         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
920         * runtime/PropertyName.h:
921         (JSC::isCanonicalNumericIndexString):
922
923 2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
924
925         [JSC] Need to emit SetLocal if we emit MovHint in DFGByteCodeParser
926         https://bugs.webkit.org/show_bug.cgi?id=197584
927
928         Reviewed by Saam Barati.
929
930         In r244864, we emit MovHint for adhocly created GetterCall/SetterCall frame locals in the callee side to make OSR availability analysis's pruning correct.
931         However, we just emit MovHint, and we do not emit SetLocal since we ensured that these locals are already flushed in the same place before. However, MovHint
932         and SetLocal are needed to be a pair in DFGByteCodeParser because we rely on this assumption in SSA conversion phase. SSA conversion phase always emit KillStack
933         just before MovHint's target location even if the MovHint's target is the same to the previously emitted MovHint and SetLocal.
934         This patch emits SetLocal too when emitting MovHint for GetterCall/SetterCall frame locals.
935
936         The example is like this.
937
938             a:  SomeValueNode
939              :  MovHint(@a, loc10)
940             b:  SetLocal(@a, loc10)
941                 ...
942             c:  MovHint(@a, loc10)
943
944         Then, this will be converted to the style in SSA conversion.
945
946             a:  SomeValueNode
947              :  KillStack(loc10)
948             b:  PutStack(@a, loc10)
949                 ...
950             c:  KillStack(loc10)
951
952         Then, @b will be removed later since @c kills it.
953
954         * dfg/DFGByteCodeParser.cpp:
955         (JSC::DFG::ByteCodeParser::inlineCall):
956         * heap/MarkedBlock.cpp:
957         (JSC::MarkedBlock::MarkedBlock):
958         (JSC::MarkedBlock::Handle::stopAllocating):
959         (JSC::MarkedBlock::Handle::resumeAllocating):
960         (JSC::MarkedBlock::aboutToMarkSlow):
961         (JSC::MarkedBlock::Handle::didConsumeFreeList):
962
963 2019-05-03  Devin Rousso  <drousso@apple.com>
964
965         Web Inspector: DOM: rename "low power" to "display composited"
966         https://bugs.webkit.org/show_bug.cgi?id=197296
967
968         Reviewed by Joseph Pecoraro.
969
970         Removed specific ChangeLog entries since it is almost entirely mechanical changes.
971
972         * inspector/protocol/DOM.json:
973
974 2019-05-03  Basuke Suzuki  <Basuke.Suzuki@sony.com>
975
976         [WinCairo] Implement and enable RemoteInspector Server.
977         https://bugs.webkit.org/show_bug.cgi?id=197432
978
979         Reviewed by Ross Kirsling.
980
981         Implement Windows implementation for Socket Backend of RemoteInspector and enable it on WinCairo
982         for experimental feature.
983
984         Also add listener interface for connection between RemoteInspector and RemoteInspectorServer
985         for flexible configuration.
986
987         * PlatformWin.cmake:
988         * inspector/remote/RemoteInspector.h:
989         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
990         (Inspector::RemoteInspectorConnectionClient::didAccept):
991         * inspector/remote/socket/RemoteInspectorServer.cpp:
992         (Inspector::RemoteInspectorServer::connect):
993         (Inspector::RemoteInspectorServer::listenForTargets):
994         (Inspector::RemoteInspectorServer::didAccept):
995         (Inspector::RemoteInspectorServer::dispatchMap):
996         (Inspector::RemoteInspectorServer::start):
997         (Inspector::RemoteInspectorServer::addServerConnection): Deleted.
998         * inspector/remote/socket/RemoteInspectorServer.h:
999         (Inspector::RemoteInspectorServer::RemoteInspectorServer):
1000         * inspector/remote/socket/RemoteInspectorSocket.cpp:
1001         (Inspector::RemoteInspector::RemoteInspector):
1002         (Inspector::RemoteInspector::dispatchMap):
1003         (Inspector::RemoteInspector::start):
1004         (Inspector::RemoteInspector::stopInternal):
1005         (Inspector::RemoteInspector::setServerPort):
1006         * inspector/remote/socket/RemoteInspectorSocket.h:
1007         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
1008         (Inspector::RemoteInspectorSocketEndpoint::listenInet):
1009         (Inspector::RemoteInspectorSocketEndpoint::getPort const):
1010         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
1011         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
1012         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
1013         (Inspector::Socket::init): Added.
1014         (Inspector::Socket::listen): Signature changed.
1015         (Inspector::Socket::getPort): Added.
1016         * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp: Added.
1017         (Inspector::Socket::init):
1018         (Inspector::Socket::Socket::Socket):
1019         (Inspector::Socket::Socket::~Socket):
1020         (Inspector::Socket::Socket::close):
1021         (Inspector::Socket::Socket::operator PlatformSocketType const):
1022         (Inspector::Socket::Socket::operator bool const):
1023         (Inspector::Socket::Socket::leak):
1024         (Inspector::Socket::Socket::create):
1025         (Inspector::Socket::setOpt):
1026         (Inspector::Socket::setOptEnabled):
1027         (Inspector::Socket::enableOpt):
1028         (Inspector::Socket::connectTo):
1029         (Inspector::Socket::bindAndListen):
1030         (Inspector::Socket::connect):
1031         (Inspector::Socket::listen):
1032         (Inspector::Socket::accept):
1033         (Inspector::Socket::createPair):
1034         (Inspector::Socket::setup):
1035         (Inspector::Socket::isValid):
1036         (Inspector::Socket::isListening):
1037         (Inspector::Socket::getPort):
1038         (Inspector::Socket::read):
1039         (Inspector::Socket::write):
1040         (Inspector::Socket::close):
1041         (Inspector::Socket::preparePolling):
1042         (Inspector::Socket::poll):
1043         (Inspector::Socket::isReadable):
1044         (Inspector::Socket::isWritable):
1045         (Inspector::Socket::markWaitingWritable):
1046         (Inspector::Socket::clearWaitingWritable):
1047
1048 2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
1049
1050         [JSC] Generator CodeBlock generation should be idempotent
1051         https://bugs.webkit.org/show_bug.cgi?id=197552
1052
1053         Reviewed by Keith Miller.
1054
1055         ES6 Generator saves and resumes the current execution state. Since ES6 generator can save the execution state at expression
1056         granularity (not statement granularity), the saved state involves locals. But if the underlying CodeBlock is jettisoned and
1057         recompiled with different code generation option (like, debugger, type profiler etc.), the generated instructions can be largely
1058         different and it does not have the same state previously used. If we resume the previously created generator with the newly
1059         generator function, resuming is messed up.
1060
1061             function* gen () { ... }
1062             var g = gen();
1063             g.next();
1064
1065             // CodeBlock is destroyed & Debugger is enabled.
1066
1067             g.next();
1068
1069         In this patch,
1070
1071         1. In generatorification, we use index Identifier (localN => Identifier("N")) instead of private symbols to generate the same
1072            instructions every time we regenerate the CodeBlock.
1073
1074         2. We decouple the options which can affect on the generated code (Debugger, TypeProfiler, ControlFlowProfiler) from the BytecodeGenerator,
1075            and pass them as a parameter, OptionSet<CodeGeneratorMode>.
1076
1077         3. Generator ScriptExecutable remembers the previous CodeGeneratorMode and reuses this parameter to regenerate CodeBlock. It means that,
1078            even if the debugger is enabled, previously created generators are not debuggable. But newly created generators are debuggable.
1079
1080         * bytecode/BytecodeGeneratorification.cpp:
1081         (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
1082         (JSC::BytecodeGeneratorification::run):
1083         * bytecode/CodeBlock.cpp:
1084         (JSC::CodeBlock::finishCreation):
1085         (JSC::CodeBlock::setConstantRegisters):
1086         * bytecode/UnlinkedCodeBlock.cpp:
1087         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1088         * bytecode/UnlinkedCodeBlock.h:
1089         (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes const):
1090         (JSC::UnlinkedCodeBlock::wasCompiledWithTypeProfilerOpcodes const):
1091         (JSC::UnlinkedCodeBlock::wasCompiledWithControlFlowProfilerOpcodes const):
1092         (JSC::UnlinkedCodeBlock::codeGenerationMode const):
1093         * bytecode/UnlinkedEvalCodeBlock.h:
1094         * bytecode/UnlinkedFunctionCodeBlock.h:
1095         * bytecode/UnlinkedFunctionExecutable.cpp:
1096         (JSC::generateUnlinkedFunctionCodeBlock):
1097         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
1098         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
1099         * bytecode/UnlinkedFunctionExecutable.h:
1100         * bytecode/UnlinkedGlobalCodeBlock.h:
1101         (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
1102         * bytecode/UnlinkedModuleProgramCodeBlock.h:
1103         * bytecode/UnlinkedProgramCodeBlock.h:
1104         * bytecompiler/BytecodeGenerator.cpp:
1105         (JSC::BytecodeGenerator::BytecodeGenerator):
1106         (JSC::BytecodeGenerator::emitTypeProfilerExpressionInfo):
1107         (JSC::BytecodeGenerator::emitProfileType):
1108         (JSC::BytecodeGenerator::emitProfileControlFlow):
1109         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
1110         (JSC::BytecodeGenerator::popLexicalScopeInternal):
1111         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
1112         (JSC::BytecodeGenerator::emitCall):
1113         (JSC::BytecodeGenerator::emitCallVarargs):
1114         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
1115         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
1116         (JSC::BytecodeGenerator::emitDebugHook):
1117         * bytecompiler/BytecodeGenerator.h:
1118         (JSC::BytecodeGenerator::generate):
1119         (JSC::BytecodeGenerator::shouldEmitDebugHooks const):
1120         (JSC::BytecodeGenerator::shouldEmitTypeProfilerHooks const):
1121         (JSC::BytecodeGenerator::shouldEmitControlFlowProfilerHooks const):
1122         * bytecompiler/NodesCodegen.cpp:
1123         (JSC::PrefixNode::emitResolve):
1124         (JSC::EmptyVarExpression::emitBytecode):
1125         (JSC::ReturnNode::emitBytecode):
1126         (JSC::FunctionNode::emitBytecode):
1127         * parser/ParserModes.h:
1128         (): Deleted.
1129         * parser/SourceCodeKey.h:
1130         (JSC::SourceCodeFlags::SourceCodeFlags):
1131         (JSC::SourceCodeKey::SourceCodeKey):
1132         * runtime/CachedTypes.cpp:
1133         (JSC::CachedCodeBlock::isClassContext const):
1134         (JSC::CachedCodeBlock::codeGenerationMode const):
1135         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1136         (JSC::CachedCodeBlock<CodeBlockType>::encode):
1137         (JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
1138         * runtime/CodeCache.cpp:
1139         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
1140         (JSC::CodeCache::getUnlinkedProgramCodeBlock):
1141         (JSC::CodeCache::getUnlinkedEvalCodeBlock):
1142         (JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
1143         (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
1144         (JSC::generateUnlinkedCodeBlockForFunctions):
1145         (JSC::sourceCodeKeyForSerializedBytecode):
1146         (JSC::sourceCodeKeyForSerializedProgram):
1147         (JSC::sourceCodeKeyForSerializedModule):
1148         (JSC::serializeBytecode):
1149         * runtime/CodeCache.h:
1150         (JSC::generateUnlinkedCodeBlockImpl):
1151         (JSC::generateUnlinkedCodeBlock):
1152         * runtime/Completion.cpp:
1153         (JSC::generateProgramBytecode):
1154         (JSC::generateModuleBytecode):
1155         * runtime/DirectEvalExecutable.cpp:
1156         (JSC::DirectEvalExecutable::create):
1157         * runtime/IndirectEvalExecutable.cpp:
1158         (JSC::IndirectEvalExecutable::create):
1159         * runtime/JSGlobalObject.h:
1160         (JSC::JSGlobalObject::defaultCodeGenerationMode const):
1161         * runtime/ModuleProgramExecutable.cpp:
1162         (JSC::ModuleProgramExecutable::create):
1163         * runtime/ProgramExecutable.cpp:
1164         (JSC::ProgramExecutable::initializeGlobalProperties):
1165         * runtime/ScriptExecutable.cpp:
1166         (JSC::ScriptExecutable::ScriptExecutable):
1167         (JSC::ScriptExecutable::newCodeBlockFor):
1168         * runtime/ScriptExecutable.h:
1169         * tools/JSDollarVM.cpp:
1170         (JSC::changeDebuggerModeWhenIdle):
1171         (JSC::functionEnableDebuggerModeWhenIdle):
1172         (JSC::functionDisableDebuggerModeWhenIdle):
1173
1174 2019-05-03  Devin Rousso  <drousso@apple.com>
1175
1176         Web Inspector: Record actions performed on WebGL2RenderingContext
1177         https://bugs.webkit.org/show_bug.cgi?id=176008
1178         <rdar://problem/34213884>
1179
1180         Reviewed by Joseph Pecoraro.
1181
1182         * inspector/protocol/Recording.json:
1183         * inspector/scripts/codegen/generator.py:
1184         Add `canvas-webgl2` as a `Type`.
1185
1186 2019-05-03  Commit Queue  <commit-queue@webkit.org>
1187
1188         Unreviewed, rolling out r244881.
1189         https://bugs.webkit.org/show_bug.cgi?id=197559
1190
1191         Breaks compilation of jsconly on linux, breaking compilation
1192         for jsc-i386-ews, jsc-mips-ews and jsc-armv7-ews (Requested by
1193         guijemont on #webkit).
1194
1195         Reverted changeset:
1196
1197         "[CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into
1198         WEBKIT_COPY_FILES"
1199         https://bugs.webkit.org/show_bug.cgi?id=197174
1200         https://trac.webkit.org/changeset/244881
1201
1202 2019-05-02  Don Olmstead  <don.olmstead@sony.com>
1203
1204         [CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into WEBKIT_COPY_FILES
1205         https://bugs.webkit.org/show_bug.cgi?id=197174
1206
1207         Reviewed by Alex Christensen.
1208
1209         Replace WEBKIT_MAKE_FORWARDING_HEADERS with WEBKIT_COPY_FILES and make dependencies
1210         for framework headers explicit.
1211
1212         * CMakeLists.txt:
1213
1214 2019-05-02  Michael Saboff  <msaboff@apple.com>
1215
1216         Unreviewed rollout of r244862.
1217
1218         * runtime/JSObject.cpp:
1219         (JSC::JSObject::getOwnPropertyDescriptor):
1220
1221 2019-05-01  Saam barati  <sbarati@apple.com>
1222
1223         Baseline JIT should do argument value profiling after checking for stack overflow
1224         https://bugs.webkit.org/show_bug.cgi?id=197052
1225         <rdar://problem/50009602>
1226
1227         Reviewed by Yusuke Suzuki.
1228
1229         Otherwise, we may do value profiling without running a write barrier, which
1230         is against the rules of how we do value profiling.
1231
1232         * jit/JIT.cpp:
1233         (JSC::JIT::compileWithoutLinking):
1234
1235 2019-05-01  Yusuke Suzuki  <ysuzuki@apple.com>
1236
1237         [JSC] Inlining Getter/Setter should care availability of ad-hocly constructed frame
1238         https://bugs.webkit.org/show_bug.cgi?id=197405
1239
1240         Reviewed by Saam Barati.
1241
1242         When inlining getter and setter calls, we setup a stack frame which does not appear in the bytecode.
1243         Because Inlining can switch on executable, we could have a graph like this.
1244
1245         BB#0
1246             ...
1247             30: GetSetter
1248             31: MovHint(loc10)
1249             32: SetLocal(loc10)
1250             33: MovHint(loc9)
1251             34: SetLocal(loc9)
1252             ...
1253             37: GetExecutable(@30)
1254             ...
1255             41: Switch(@37)
1256
1257         BB#2
1258             42: GetLocal(loc12, bc#7 of caller)
1259             ...
1260             --> callee: loc9 and loc10 are arguments of callee.
1261               ...
1262               <HERE, exit to callee, loc9 and loc10 are required in the bytecode>
1263
1264         When we prune OSR availability at the beginning of BB#2 (bc#7 in the caller), we prune loc9 and loc10's liveness because the caller does not actually have loc9 and loc10.
1265         However, when we begin executing the callee, we need OSR exit to be aware of where it can recover the arguments to the setter, loc9 and loc10.
1266
1267         This patch inserts MovHint at the beginning of callee for a getter / setter stack frame to make arguments (loc9 and loc10 in the above example) recoverable from OSR exit.
1268         We also move arity fixup DFG nodes from the caller to the callee, since moved arguments are not live in the caller too.
1269
1270         Interestingly, this fix also reveals the existing issue in LiveCatchVariablePreservationPhase. We emitted Flush for |this| of InlineCallFrame blindly if we saw InlineCallFrame
1271         inside a block which is covered by catch handler. But this is wrong because inlined function can finish its execution within the block, and |this| is completely unrelated to
1272         the catch handler if the catch handler is in the outer callee. We already collect all the live locals at the catch handler. And this locals must include arguments too if the
1273         catch handler is in inlined function. So, we should not emit Flush for each |this| of seen InlineCallFrame. This emitted Flush may connect unrelated locals in the catch handler
1274         to the locals that is only defined and used in the inlined function, and it leads to the results like DFG says the local is live while the bytecode says the local is dead.
1275         This results in reading and using garbage in OSR entry because DFG OSR entry needs to fill live DFG values from the stack.
1276
1277         * dfg/DFGByteCodeParser.cpp:
1278         (JSC::DFG::ByteCodeParser::inlineCall):
1279         (JSC::DFG::ByteCodeParser::handleGetById):
1280         (JSC::DFG::ByteCodeParser::handlePutById):
1281         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
1282         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
1283
1284 2019-05-01  Michael Saboff  <msaboff@apple.com>
1285
1286         ASSERTION FAILED: !m_needExceptionCheck with --validateExceptionChecks=1; ProxyObject.getOwnPropertySlotCommon/JSFunction.callerGetter
1287         https://bugs.webkit.org/show_bug.cgi?id=197485
1288
1289         Reviewed by Saam Barati.
1290
1291         Added an EXCEPTION_ASSERT after call to getOwnPropertySlot().
1292
1293         * runtime/JSObject.cpp:
1294         (JSC::JSObject::getOwnPropertyDescriptor):
1295
1296 2019-05-01  Ross Kirsling  <ross.kirsling@sony.com>
1297
1298         RemoteInspector::updateAutomaticInspectionCandidate should have a default implementation.
1299         https://bugs.webkit.org/show_bug.cgi?id=197439
1300
1301         Reviewed by Devin Rousso.
1302
1303         On non-Cocoa platforms, automatic inspection is not currently implemented,
1304         so updateAutomaticInspectionCandidate falls back to the logic of updateTarget.
1305         This logic already existed in three places, so refactor it into a common private method
1306         and allow our websocket-based RWI implementation to make use of it too.
1307
1308         * inspector/remote/RemoteInspector.cpp:
1309         (Inspector::RemoteInspector::updateTarget):
1310         (Inspector::RemoteInspector::updateTargetMap):
1311         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1312         * inspector/remote/RemoteInspector.h:
1313         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
1314         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1315         * inspector/remote/glib/RemoteInspectorGlib.cpp:
1316         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
1317         * inspector/remote/socket/RemoteInspectorSocket.cpp:
1318         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
1319
1320 2019-05-01  Darin Adler  <darin@apple.com>
1321
1322         WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
1323         https://bugs.webkit.org/show_bug.cgi?id=195535
1324
1325         Reviewed by Alexey Proskuryakov.
1326
1327         * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
1328
1329         * API/JSStringRef.cpp:
1330         (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
1331         (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
1332         Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
1333         since that is the default. Also updated for changes to CompletionResult.
1334
1335         * runtime/JSGlobalObjectFunctions.cpp:
1336         (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
1337         and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
1338         U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
1339         equivalents, since these macros from ICU are correct and efficient.
1340
1341         * wasm/WasmParser.h:
1342         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
1343         convertUTF8ToUTF16.
1344
1345 2019-05-01  Shawn Roberts  <sroberts@apple.com>
1346
1347         Unreviewed, rolling out r244821.
1348
1349         Causing
1350
1351         Reverted changeset:
1352
1353         "WebKit has too much of its own UTF-8 code and should rely
1354         more on ICU's UTF-8 support"
1355         https://bugs.webkit.org/show_bug.cgi?id=195535
1356         https://trac.webkit.org/changeset/244821
1357
1358 2019-04-29  Darin Adler  <darin@apple.com>
1359
1360         WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
1361         https://bugs.webkit.org/show_bug.cgi?id=195535
1362
1363         Reviewed by Alexey Proskuryakov.
1364
1365         * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
1366
1367         * API/JSStringRef.cpp:
1368         (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
1369         (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
1370         Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
1371         since that is the default. Also updated for changes to CompletionResult.
1372
1373         * runtime/JSGlobalObjectFunctions.cpp:
1374         (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
1375         and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
1376         U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
1377         equivalents, since these macros from ICU are correct and efficient.
1378
1379         * wasm/WasmParser.h:
1380         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
1381         convertUTF8ToUTF16.
1382
1383 2019-04-30  Commit Queue  <commit-queue@webkit.org>
1384
1385         Unreviewed, rolling out r244806.
1386         https://bugs.webkit.org/show_bug.cgi?id=197446
1387
1388         Causing Test262 and JSC test failures on multiple builds
1389         (Requested by ShawnRoberts on #webkit).
1390
1391         Reverted changeset:
1392
1393         "TypeArrays should not store properties that are canonical
1394         numeric indices"
1395         https://bugs.webkit.org/show_bug.cgi?id=197228
1396         https://trac.webkit.org/changeset/244806
1397
1398 2019-04-30  Saam barati  <sbarati@apple.com>
1399
1400         CodeBlock::m_instructionCount is wrong
1401         https://bugs.webkit.org/show_bug.cgi?id=197304
1402
1403         Reviewed by Yusuke Suzuki.
1404
1405         What we were calling instructionCount() was wrong, as evidenced by
1406         us using it incorrectly both in the sampling profiler and when we
1407         dumped bytecode for a given CodeBlock. Prior to the bytecode rewrite,
1408         instructionCount() was probably valid to do bounds checks against.
1409         However, this is no longer the case. This patch renames what we called
1410         instructionCount() to bytecodeCost(). It is now only used to make decisions
1411         about inlining and tier up heuristics. I've also named options related to
1412         this appropriately.
1413         
1414         This patch also introduces instructionsSize(). The result of this method
1415         is valid to do bounds checks against.
1416
1417         * bytecode/CodeBlock.cpp:
1418         (JSC::CodeBlock::dumpAssumingJITType const):
1419         (JSC::CodeBlock::CodeBlock):
1420         (JSC::CodeBlock::finishCreation):
1421         (JSC::CodeBlock::optimizationThresholdScalingFactor):
1422         (JSC::CodeBlock::predictedMachineCodeSize):
1423         * bytecode/CodeBlock.h:
1424         (JSC::CodeBlock::instructionsSize const):
1425         (JSC::CodeBlock::bytecodeCost const):
1426         (JSC::CodeBlock::instructionCount const): Deleted.
1427         * dfg/DFGByteCodeParser.cpp:
1428         (JSC::DFG::ByteCodeParser::inliningCost):
1429         (JSC::DFG::ByteCodeParser::getInliningBalance):
1430         * dfg/DFGCapabilities.cpp:
1431         (JSC::DFG::mightCompileEval):
1432         (JSC::DFG::mightCompileProgram):
1433         (JSC::DFG::mightCompileFunctionForCall):
1434         (JSC::DFG::mightCompileFunctionForConstruct):
1435         (JSC::DFG::mightInlineFunctionForCall):
1436         (JSC::DFG::mightInlineFunctionForClosureCall):
1437         (JSC::DFG::mightInlineFunctionForConstruct):
1438         * dfg/DFGCapabilities.h:
1439         (JSC::DFG::isSmallEnoughToInlineCodeInto):
1440         * dfg/DFGDisassembler.cpp:
1441         (JSC::DFG::Disassembler::dumpHeader):
1442         * dfg/DFGDriver.cpp:
1443         (JSC::DFG::compileImpl):
1444         * dfg/DFGPlan.cpp:
1445         (JSC::DFG::Plan::compileInThread):
1446         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1447         (JSC::DFG::TierUpCheckInjectionPhase::run):
1448         * ftl/FTLCapabilities.cpp:
1449         (JSC::FTL::canCompile):
1450         * ftl/FTLCompile.cpp:
1451         (JSC::FTL::compile):
1452         * ftl/FTLLink.cpp:
1453         (JSC::FTL::link):
1454         * jit/JIT.cpp:
1455         (JSC::JIT::link):
1456         * jit/JITDisassembler.cpp:
1457         (JSC::JITDisassembler::dumpHeader):
1458         * llint/LLIntSlowPaths.cpp:
1459         (JSC::LLInt::shouldJIT):
1460         * profiler/ProfilerBytecodes.cpp:
1461         (JSC::Profiler::Bytecodes::Bytecodes):
1462         * runtime/Options.h:
1463         * runtime/SamplingProfiler.cpp:
1464         (JSC::tryGetBytecodeIndex):
1465         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1466
1467 2019-04-30  Tadeu Zagallo  <tzagallo@apple.com>
1468
1469         TypeArrays should not store properties that are canonical numeric indices
1470         https://bugs.webkit.org/show_bug.cgi?id=197228
1471         <rdar://problem/49557381>
1472
1473         Reviewed by Darin Adler.
1474
1475         According to the spec[1], TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty
1476         if the index is a CanonicalNumericIndexString, but invalid according toIntegerIndexedElementGet
1477         and similar functions. I.e., there are a few properties that should not be set in a TypedArray,
1478         like NaN, Infinity and -0.
1479
1480         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
1481
1482         * CMakeLists.txt:
1483         * JavaScriptCore.xcodeproj/project.pbxproj:
1484         * runtime/JSGenericTypedArrayViewInlines.h:
1485         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
1486         (JSC::JSGenericTypedArrayView<Adaptor>::put):
1487         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
1488         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
1489         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
1490         * runtime/JSTypedArrays.cpp:
1491         * runtime/PropertyName.h:
1492         (JSC::canonicalNumericIndexString):
1493
1494 2019-04-30  Brian Burg  <bburg@apple.com>
1495
1496         Web Automation: use a more informative key to indicate automation availability
1497         https://bugs.webkit.org/show_bug.cgi?id=197377
1498         <rdar://problem/50258069>
1499
1500         Reviewed by Devin Rousso.
1501
1502         The existing WIRAutomationEnabledKey does not encode uncertainty.
1503         Add a new key that provides an 'Unknown' state, and prefer to use it.
1504
1505         Since an application's initial listing is sent from a background dispatch queue
1506         on Cocoa platforms, this can race with main thread initialization that sets up
1507         RemoteInspector::Client. Therefore, the initial listing may not properly represent
1508         the client's capabilites because the client is not yet available. Allowing for
1509         an "Unknown" state that is later upgraded to Available or Not Available makes it
1510         possible to work around this potential race.
1511
1512         * inspector/remote/RemoteInspectorConstants.h:
1513         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
1514         (Inspector::RemoteInspector::pushListingsNow):
1515
1516 2019-04-30  Keith Miller  <keith_miller@apple.com>
1517
1518         Fix failing ARM64E wasm tests
1519         https://bugs.webkit.org/show_bug.cgi?id=197420
1520
1521         Reviewed by Saam Barati.
1522
1523         This patch fixes a bug in the slow path of our JS->Wasm IC bridge
1524         where we wouldn't untag the link register before tail calling.
1525
1526         Additionally, this patch fixes a broken assert when using setting
1527         Options::useTailCalls=false.
1528
1529         * bytecompiler/BytecodeGenerator.cpp:
1530         (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
1531         * wasm/js/WebAssemblyFunction.cpp:
1532         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1533
1534 2019-04-29  Saam Barati  <sbarati@apple.com>
1535
1536         Make JITType an enum class
1537         https://bugs.webkit.org/show_bug.cgi?id=197394
1538
1539         Reviewed by Yusuke Suzuki.
1540
1541         This makes the code more easily searchable.
1542
1543         * bytecode/CallLinkStatus.cpp:
1544         (JSC::CallLinkStatus::computeFor):
1545         * bytecode/CodeBlock.cpp:
1546         (JSC::CodeBlock::dumpAssumingJITType const):
1547         (JSC::CodeBlock::specialOSREntryBlockOrNull):
1548         (JSC::timeToLive):
1549         (JSC::CodeBlock::propagateTransitions):
1550         (JSC::CodeBlock::baselineAlternative):
1551         (JSC::CodeBlock::baselineVersion):
1552         (JSC::CodeBlock::hasOptimizedReplacement):
1553         (JSC::CodeBlock::noticeIncomingCall):
1554         (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
1555         (JSC::CodeBlock::tallyFrequentExitSites):
1556         (JSC::CodeBlock::frameRegisterCount):
1557         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
1558         * bytecode/CodeBlock.h:
1559         (JSC::CodeBlock::jitType const):
1560         (JSC::CodeBlock::hasBaselineJITProfiling const):
1561         * bytecode/CodeBlockWithJITType.h:
1562         (JSC::CodeBlockWithJITType::CodeBlockWithJITType):
1563         * bytecode/DeferredSourceDump.cpp:
1564         (JSC::DeferredSourceDump::DeferredSourceDump):
1565         * bytecode/DeferredSourceDump.h:
1566         * bytecode/ExitingJITType.h:
1567         (JSC::exitingJITTypeFor):
1568         * bytecode/InlineCallFrame.h:
1569         (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
1570         * dfg/DFGByteCodeParser.cpp:
1571         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1572         * dfg/DFGDisassembler.cpp:
1573         (JSC::DFG::Disassembler::dumpHeader):
1574         * dfg/DFGDriver.cpp:
1575         (JSC::DFG::compileImpl):
1576         * dfg/DFGGraph.cpp:
1577         (JSC::DFG::Graph::dump):
1578         * dfg/DFGJITCode.cpp:
1579         (JSC::DFG::JITCode::JITCode):
1580         (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
1581         (JSC::DFG::JITCode::optimizeNextInvocation):
1582         (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
1583         (JSC::DFG::JITCode::optimizeAfterWarmUp):
1584         (JSC::DFG::JITCode::optimizeSoon):
1585         (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
1586         (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
1587         * dfg/DFGJITFinalizer.cpp:
1588         (JSC::DFG::JITFinalizer::finalize):
1589         (JSC::DFG::JITFinalizer::finalizeFunction):
1590         * dfg/DFGOSREntry.cpp:
1591         (JSC::DFG::prepareOSREntry):
1592         (JSC::DFG::prepareCatchOSREntry):
1593         * dfg/DFGOSRExit.cpp:
1594         (JSC::DFG::OSRExit::executeOSRExit):
1595         (JSC::DFG::reifyInlinedCallFrames):
1596         (JSC::DFG::OSRExit::compileOSRExit):
1597         * dfg/DFGOSRExitCompilerCommon.cpp:
1598         (JSC::DFG::handleExitCounts):
1599         (JSC::DFG::reifyInlinedCallFrames):
1600         (JSC::DFG::adjustAndJumpToTarget):
1601         * dfg/DFGOSRExitCompilerCommon.h:
1602         (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
1603         * dfg/DFGOperations.cpp:
1604         * dfg/DFGThunks.cpp:
1605         (JSC::DFG::osrExitGenerationThunkGenerator):
1606         * dfg/DFGVariableEventStream.cpp:
1607         (JSC::DFG::VariableEventStream::reconstruct const):
1608         * ftl/FTLCompile.cpp:
1609         (JSC::FTL::compile):
1610         * ftl/FTLJITCode.cpp:
1611         (JSC::FTL::JITCode::JITCode):
1612         * ftl/FTLJITFinalizer.cpp:
1613         (JSC::FTL::JITFinalizer::finalizeCommon):
1614         * ftl/FTLLink.cpp:
1615         (JSC::FTL::link):
1616         * ftl/FTLOSRExitCompiler.cpp:
1617         (JSC::FTL::compileFTLOSRExit):
1618         * ftl/FTLThunks.cpp:
1619         (JSC::FTL::genericGenerationThunkGenerator):
1620         * interpreter/CallFrame.cpp:
1621         (JSC::CallFrame::callSiteBitsAreBytecodeOffset const):
1622         (JSC::CallFrame::callSiteBitsAreCodeOriginIndex const):
1623         * interpreter/StackVisitor.cpp:
1624         (JSC::StackVisitor::Frame::dump const):
1625         * jit/AssemblyHelpers.h:
1626         (JSC::AssemblyHelpers::AssemblyHelpers):
1627         * jit/JIT.cpp:
1628         (JSC::JIT::link):
1629         * jit/JITCode.cpp:
1630         (JSC::JITCode::typeName):
1631         (WTF::printInternal):
1632         * jit/JITCode.h:
1633         (JSC::JITCode::bottomTierJIT):
1634         (JSC::JITCode::topTierJIT):
1635         (JSC::JITCode::nextTierJIT):
1636         (JSC::JITCode::isExecutableScript):
1637         (JSC::JITCode::couldBeInterpreted):
1638         (JSC::JITCode::isJIT):
1639         (JSC::JITCode::isOptimizingJIT):
1640         (JSC::JITCode::isBaselineCode):
1641         (JSC::JITCode::jitTypeFor):
1642         * jit/JITDisassembler.cpp:
1643         (JSC::JITDisassembler::dumpHeader):
1644         * jit/JITOperations.cpp:
1645         * jit/JITThunks.cpp:
1646         (JSC::JITThunks::hostFunctionStub):
1647         * jit/JITToDFGDeferredCompilationCallback.cpp:
1648         (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1649         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
1650         * jit/JITWorklist.cpp:
1651         (JSC::JITWorklist::compileLater):
1652         (JSC::JITWorklist::compileNow):
1653         * jit/Repatch.cpp:
1654         (JSC::readPutICCallTarget):
1655         (JSC::ftlThunkAwareRepatchCall):
1656         * llint/LLIntEntrypoint.cpp:
1657         (JSC::LLInt::setFunctionEntrypoint):
1658         (JSC::LLInt::setEvalEntrypoint):
1659         (JSC::LLInt::setProgramEntrypoint):
1660         (JSC::LLInt::setModuleProgramEntrypoint):
1661         * llint/LLIntSlowPaths.cpp:
1662         (JSC::LLInt::jitCompileAndSetHeuristics):
1663         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1664         * runtime/SamplingProfiler.cpp:
1665         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1666         * runtime/SamplingProfiler.h:
1667         * runtime/VM.cpp:
1668         (JSC::jitCodeForCallTrampoline):
1669         (JSC::jitCodeForConstructTrampoline):
1670         * tools/CodeProfile.cpp:
1671         (JSC::CodeProfile::sample):
1672         * tools/JSDollarVM.cpp:
1673         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
1674         (JSC::CallerFrameJITTypeFunctor::jitType):
1675         (JSC::functionLLintTrue):
1676         (JSC::functionJITTrue):
1677
1678 2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
1679
1680         Unreivewed, fix FTL implementation of r244760
1681         https://bugs.webkit.org/show_bug.cgi?id=197362
1682
1683         Reviewed by Saam Barati.
1684
1685         Looked with Saam. ValueFromBlock from double case block was overridden by NaN thing now.
1686
1687         * ftl/FTLLowerDFGToB3.cpp:
1688         (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
1689
1690 2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
1691
1692         normalizeMapKey should normalize NaN to one PureNaN bit pattern to make MapHash same
1693         https://bugs.webkit.org/show_bug.cgi?id=197362
1694
1695         Reviewed by Saam Barati.
1696
1697         Our Map/Set's hash algorithm relies on the bit pattern of JSValue. So our Map/Set has
1698         normalization of the key, which normalizes Int32 / Double etc. But we did not normalize
1699         pure NaNs into one canonicalized pure NaN. So we end up having multiple different pure NaNs
1700         in one Map/Set. This patch normalizes NaN into one jsNaN(), which uses PNaN for the representation.
1701
1702         * dfg/DFGSpeculativeJIT.cpp:
1703         (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
1704         * ftl/FTLLowerDFGToB3.cpp:
1705         (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
1706         * runtime/HashMapImpl.h:
1707         (JSC::normalizeMapKey):
1708
1709 2019-04-29  Alex Christensen  <achristensen@webkit.org>
1710
1711         <rdar://problem/50299396> Fix internal High Sierra build
1712         https://bugs.webkit.org/show_bug.cgi?id=197388
1713
1714         * Configurations/Base.xcconfig:
1715
1716 2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
1717
1718         JITStubRoutineSet wastes 180KB of HashTable capacity on can.com
1719         https://bugs.webkit.org/show_bug.cgi?id=186732
1720
1721         Reviewed by Saam Barati.
1722
1723         Our current mechanism of JITStubRoutineSet consumes more memory than needed. Basically we have HashMap<uintptr_t, StubRoutine*> and register
1724         each executable address by 16 byte to this entry. So if your StubRoutine has 128bytes, it just adds 8 entries to this hash table.
1725         In Gmail, we see a ~2MB table size.
1726
1727         Instead, this patch uses Vector<pair<uintptr_t, StubRoutine*>> and performs binary search onto this sorted vector. Before conservative
1728         scanning, we sort this vector. And doing binary search with the sorted vector to find executing stub routines from the conservative roots.
1729         This vector includes uintptr_t startAddress to make binary searching fast.
1730
1731         Large amount of conservative scan should be filtered by range check, so I think binary search here is OK, but we can decide based on what the
1732         performance bots say.
1733
1734         * heap/Heap.cpp:
1735         (JSC::Heap::addCoreConstraints):
1736         * heap/JITStubRoutineSet.cpp:
1737         (JSC::JITStubRoutineSet::~JITStubRoutineSet):
1738         (JSC::JITStubRoutineSet::add):
1739         (JSC::JITStubRoutineSet::prepareForConservativeScan):
1740         (JSC::JITStubRoutineSet::clearMarks):
1741         (JSC::JITStubRoutineSet::markSlow):
1742         (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
1743         (JSC::JITStubRoutineSet::traceMarkedStubRoutines):
1744         * heap/JITStubRoutineSet.h:
1745         (JSC::JITStubRoutineSet::mark):
1746         (JSC::JITStubRoutineSet::prepareForConservativeScan):
1747         (JSC::JITStubRoutineSet::size const): Deleted.
1748         (JSC::JITStubRoutineSet::at const): Deleted.
1749
1750 2019-04-29  Basuke Suzuki  <Basuke.Suzuki@sony.com>
1751
1752         [Win] Add flag to enable version information stamping and disable by default.
1753         https://bugs.webkit.org/show_bug.cgi?id=197249
1754         <rdar://problem/50224412>
1755
1756         Reviewed by Ross Kirsling.
1757
1758         This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
1759         Then enable it by default on AppleWin.
1760
1761         * CMakeLists.txt:
1762
1763 2019-04-26  Keith Rollin  <krollin@apple.com>
1764
1765         Enable new build rule for post-processing headers when using XCBuild
1766         https://bugs.webkit.org/show_bug.cgi?id=197340
1767         <rdar://problem/50226685>
1768
1769         Reviewed by Brent Fulgham.
1770
1771         In Bug 197116, we conditionally disabled the old method for
1772         post-processing header files when we are using the new XCBuild build
1773         system. This check-in conditionally enables the new post-processing
1774         facility. Note that the old system is disabled and the new system
1775         enabled only when the USE_NEW_BUILD_SYSTEM environment variable is set
1776         to YES.
1777
1778         * Configurations/JavaScriptCore.xcconfig:
1779
1780 2019-04-26  Jessie Berlin  <jberlin@webkit.org>
1781
1782         Add new mac target numbers
1783         https://bugs.webkit.org/show_bug.cgi?id=197313
1784
1785         Reviewed by Alex Christensen.
1786
1787         * Configurations/Version.xcconfig:
1788         * Configurations/WebKitTargetConditionals.xcconfig:
1789
1790 2019-04-26  Commit Queue  <commit-queue@webkit.org>
1791
1792         Unreviewed, rolling out r244708.
1793         https://bugs.webkit.org/show_bug.cgi?id=197334
1794
1795         "Broke the debug build" (Requested by rmorisset on #webkit).
1796
1797         Reverted changeset:
1798
1799         "All prototypes should call didBecomePrototype()"
1800         https://bugs.webkit.org/show_bug.cgi?id=196315
1801         https://trac.webkit.org/changeset/244708
1802
1803 2019-04-26  Don Olmstead  <don.olmstead@sony.com>
1804
1805         [CMake] Add WEBKIT_EXECUTABLE macro
1806         https://bugs.webkit.org/show_bug.cgi?id=197206
1807
1808         Reviewed by Konstantin Tokarev.
1809
1810         Migrate to WEBKIT_EXECUTABLE for the jsc and test targets.
1811
1812         * b3/air/testair.cpp:
1813         * b3/testb3.cpp:
1814         * dfg/testdfg.cpp:
1815         * shell/CMakeLists.txt:
1816         * shell/PlatformGTK.cmake:
1817         * shell/PlatformJSCOnly.cmake: Removed.
1818         * shell/PlatformMac.cmake:
1819         * shell/PlatformPlayStation.cmake:
1820         * shell/PlatformWPE.cmake:
1821         * shell/PlatformWin.cmake:
1822
1823 2019-04-25  Yusuke Suzuki  <ysuzuki@apple.com>
1824
1825         [JSC] linkPolymorphicCall now does GC
1826         https://bugs.webkit.org/show_bug.cgi?id=197306
1827
1828         Reviewed by Saam Barati.
1829
1830         Previously, we assumed that linkPolymorphicCall does not perform allocations. So we put CallVariant into a Vector<>.
1831         But now, WebAssemblyFunction's entrypoint generation can allocate JSToWasmICCallee and cause GC. Since CallLinkInfo
1832         does not hold these cells, they can be collected, and we will see dead cells in the middle of linkPolymorphicCall.
1833         We should defer GC for a while in linkPolymorphicCall. We use DeferGCForAWhile instead of DeferGC because the
1834         caller "operationLinkPolymorphicCall" assumes that this function does not cause GC.
1835
1836         * jit/Repatch.cpp:
1837         (JSC::linkPolymorphicCall):
1838
1839 2019-04-26  Robin Morisset  <rmorisset@apple.com>
1840
1841         All prototypes should call didBecomePrototype()
1842         https://bugs.webkit.org/show_bug.cgi?id=196315
1843
1844         Reviewed by Saam Barati.
1845
1846         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
1847
1848         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
1849         create structures with invalid prototypes.
1850         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
1851         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
1852
1853         * runtime/BigIntPrototype.cpp:
1854         (JSC::BigIntPrototype::finishCreation):
1855         * runtime/BooleanPrototype.cpp:
1856         (JSC::BooleanPrototype::finishCreation):
1857         * runtime/DatePrototype.cpp:
1858         (JSC::DatePrototype::finishCreation):
1859         * runtime/ErrorConstructor.cpp:
1860         (JSC::ErrorConstructor::finishCreation):
1861         * runtime/ErrorPrototype.cpp:
1862         (JSC::ErrorPrototype::finishCreation):
1863         * runtime/FunctionConstructor.cpp:
1864         (JSC::FunctionConstructor::finishCreation):
1865         * runtime/FunctionPrototype.cpp:
1866         (JSC::FunctionPrototype::finishCreation):
1867         * runtime/IntlCollatorPrototype.cpp:
1868         (JSC::IntlCollatorPrototype::finishCreation):
1869         * runtime/IntlDateTimeFormatPrototype.cpp:
1870         (JSC::IntlDateTimeFormatPrototype::finishCreation):
1871         * runtime/IntlNumberFormatPrototype.cpp:
1872         (JSC::IntlNumberFormatPrototype::finishCreation):
1873         * runtime/IntlPluralRulesPrototype.cpp:
1874         (JSC::IntlPluralRulesPrototype::finishCreation):
1875         * runtime/JSArrayBufferPrototype.cpp:
1876         (JSC::JSArrayBufferPrototype::finishCreation):
1877         * runtime/JSDataViewPrototype.cpp:
1878         (JSC::JSDataViewPrototype::finishCreation):
1879         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
1880         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
1881         * runtime/JSGlobalObject.cpp:
1882         (JSC::createConsoleProperty):
1883         * runtime/JSPromisePrototype.cpp:
1884         (JSC::JSPromisePrototype::finishCreation):
1885         * runtime/JSTypedArrayViewConstructor.cpp:
1886         (JSC::JSTypedArrayViewConstructor::finishCreation):
1887         * runtime/JSTypedArrayViewPrototype.cpp:
1888         (JSC::JSTypedArrayViewPrototype::finishCreation):
1889         * runtime/NumberPrototype.cpp:
1890         (JSC::NumberPrototype::finishCreation):
1891         * runtime/RegExpPrototype.cpp:
1892         (JSC::RegExpPrototype::finishCreation):
1893         * runtime/StringPrototype.cpp:
1894         (JSC::StringPrototype::finishCreation):
1895         * runtime/Structure.cpp:
1896         (JSC::Structure::isValidPrototype):
1897         (JSC::Structure::changePrototypeTransition):
1898         * runtime/Structure.h:
1899         * runtime/SymbolPrototype.cpp:
1900         (JSC::SymbolPrototype::finishCreation):
1901         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
1902         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
1903         * wasm/js/WebAssemblyInstancePrototype.cpp:
1904         (JSC::WebAssemblyInstancePrototype::finishCreation):
1905         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
1906         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
1907         * wasm/js/WebAssemblyMemoryPrototype.cpp:
1908         (JSC::WebAssemblyMemoryPrototype::finishCreation):
1909         * wasm/js/WebAssemblyModulePrototype.cpp:
1910         (JSC::WebAssemblyModulePrototype::finishCreation):
1911         * wasm/js/WebAssemblyPrototype.cpp:
1912         (JSC::WebAssemblyPrototype::finishCreation):
1913         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
1914         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
1915         * wasm/js/WebAssemblyTablePrototype.cpp:
1916         (JSC::WebAssemblyTablePrototype::finishCreation):
1917
1918 2019-04-26  Don Olmstead  <don.olmstead@sony.com>
1919
1920         Add WTF::findIgnoringASCIICaseWithoutLength to replace strcasestr
1921         https://bugs.webkit.org/show_bug.cgi?id=197291
1922
1923         Reviewed by Konstantin Tokarev.
1924
1925         Replace uses of strcasestr with WTF::findIgnoringASCIICaseWithoutLength.
1926
1927         * API/tests/testapi.cpp:
1928         * assembler/testmasm.cpp:
1929         * b3/air/testair.cpp:
1930         * b3/testb3.cpp:
1931         * dfg/testdfg.cpp:
1932         * dynbench.cpp:
1933
1934 2019-04-25  Fujii Hironori  <Hironori.Fujii@sony.com>
1935
1936         Unreviewed, rolling out r244669.
1937
1938         Windows ports can't clean build.
1939
1940         Reverted changeset:
1941
1942         "[Win] Add flag to enable version information stamping and
1943         disable by default."
1944         https://bugs.webkit.org/show_bug.cgi?id=197249
1945         https://trac.webkit.org/changeset/244669
1946
1947 2019-04-25  Basuke Suzuki  <Basuke.Suzuki@sony.com>
1948
1949         [Win] Add flag to enable version information stamping and disable by default.
1950         https://bugs.webkit.org/show_bug.cgi?id=197249
1951
1952         Reviewed by Ross Kirsling.
1953
1954         This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
1955         Then enable it by default on AppleWin.
1956
1957         * CMakeLists.txt:
1958
1959 2019-04-25  Timothy Hatcher  <timothy@apple.com>
1960
1961         Disable date and time inputs on iOSMac.
1962         https://bugs.webkit.org/show_bug.cgi?id=197287
1963         rdar://problem/46794376
1964
1965         Reviewed by Wenson Hsieh.
1966
1967         * Configurations/FeatureDefines.xcconfig:
1968
1969 2019-04-25  Alex Christensen  <achristensen@webkit.org>
1970
1971         Fix more builds after r244653
1972         https://bugs.webkit.org/show_bug.cgi?id=197131
1973
1974         * b3/B3Value.h:
1975         There is an older system with libc++ headers that don't have std::conjunction.  Just use constexpr and && instead for the one use of it in WebKit.
1976
1977 2019-04-25  Basuke Suzuki  <Basuke.Suzuki@sony.com>
1978
1979         [RemoteInspector] Fix connection and target identifier types.
1980         https://bugs.webkit.org/show_bug.cgi?id=197243
1981
1982         Reviewed by Ross Kirsling.
1983
1984         Give dedicated type for RemoteControllableTarget's identifier as Inspector::TargetID.
1985
1986         Also rename ClientID type used in Socket backend to ConnectionID because this is the identifier
1987         socket endpoint assign to the newly created connection. The size was changed to uint32_t.
1988         Enough size for managing connections.
1989
1990         * inspector/remote/RemoteConnectionToTarget.cpp:
1991         (Inspector::RemoteConnectionToTarget::setup):
1992         (Inspector::RemoteConnectionToTarget::close):
1993         (Inspector::RemoteConnectionToTarget::targetIdentifier const):
1994         * inspector/remote/RemoteConnectionToTarget.h:
1995         * inspector/remote/RemoteControllableTarget.h:
1996         * inspector/remote/RemoteInspector.cpp:
1997         (Inspector::RemoteInspector::nextAvailableTargetIdentifier):
1998         (Inspector::RemoteInspector::registerTarget):
1999         (Inspector::RemoteInspector::unregisterTarget):
2000         (Inspector::RemoteInspector::updateTarget):
2001         (Inspector::RemoteInspector::setupFailed):
2002         (Inspector::RemoteInspector::setupCompleted):
2003         (Inspector::RemoteInspector::waitingForAutomaticInspection):
2004         (Inspector::RemoteInspector::updateTargetListing):
2005         * inspector/remote/RemoteInspector.h:
2006         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
2007         (Inspector::RemoteConnectionToTarget::targetIdentifier const):
2008         (Inspector::RemoteConnectionToTarget::setup):
2009         (Inspector::RemoteConnectionToTarget::close):
2010         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
2011         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
2012         (Inspector::RemoteInspector::sendMessageToRemote):
2013         (Inspector::RemoteInspector::receivedSetupMessage):
2014         (Inspector::RemoteInspector::receivedDataMessage):
2015         (Inspector::RemoteInspector::receivedDidCloseMessage):
2016         (Inspector::RemoteInspector::receivedIndicateMessage):
2017         (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
2018         * inspector/remote/glib/RemoteInspectorGlib.cpp:
2019         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
2020         (Inspector::RemoteInspector::sendMessageToRemote):
2021         (Inspector::RemoteInspector::receivedSetupMessage):
2022         (Inspector::RemoteInspector::receivedDataMessage):
2023         (Inspector::RemoteInspector::receivedCloseMessage):
2024         (Inspector::RemoteInspector::setup):
2025         (Inspector::RemoteInspector::sendMessageToTarget):
2026         * inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
2027         (Inspector::RemoteInspectorConnectionClient::didReceiveWebInspectorEvent):
2028         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
2029         (Inspector::RemoteInspectorConnectionClient::didAccept):
2030         * inspector/remote/socket/RemoteInspectorMessageParser.cpp:
2031         (Inspector::MessageParser::MessageParser):
2032         (Inspector::MessageParser::parse):
2033         * inspector/remote/socket/RemoteInspectorMessageParser.h:
2034         (Inspector::MessageParser::setDidParseMessageListener):
2035         * inspector/remote/socket/RemoteInspectorServer.cpp:
2036         (Inspector::RemoteInspectorServer::didAccept):
2037         (Inspector::RemoteInspectorServer::didClose):
2038         (Inspector::RemoteInspectorServer::dispatchMap):
2039         (Inspector::RemoteInspectorServer::sendWebInspectorEvent):
2040         (Inspector::RemoteInspectorServer::sendCloseEvent):
2041         (Inspector::RemoteInspectorServer::connectionClosed):
2042         * inspector/remote/socket/RemoteInspectorServer.h:
2043         * inspector/remote/socket/RemoteInspectorSocket.cpp:
2044         (Inspector::RemoteInspector::didClose):
2045         (Inspector::RemoteInspector::sendMessageToRemote):
2046         (Inspector::RemoteInspector::setup):
2047         (Inspector::RemoteInspector::sendMessageToTarget):
2048         * inspector/remote/socket/RemoteInspectorSocket.h:
2049         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
2050         (Inspector::RemoteInspectorSocketEndpoint::connectInet):
2051         (Inspector::RemoteInspectorSocketEndpoint::isListening):
2052         (Inspector::RemoteInspectorSocketEndpoint::workerThread):
2053         (Inspector::RemoteInspectorSocketEndpoint::createClient):
2054         (Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
2055         (Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
2056         (Inspector::RemoteInspectorSocketEndpoint::send):
2057         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
2058         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
2059
2060 2019-04-25  Alex Christensen  <achristensen@webkit.org>
2061
2062         Start using C++17
2063         https://bugs.webkit.org/show_bug.cgi?id=197131
2064
2065         Reviewed by Darin Alder.
2066
2067         * Configurations/Base.xcconfig:
2068
2069 2019-04-25  Alex Christensen  <achristensen@webkit.org>
2070
2071         Remove DeprecatedOptional
2072         https://bugs.webkit.org/show_bug.cgi?id=197161
2073
2074         Reviewed by Darin Adler.
2075
2076         We need to keep a symbol exported from JavaScriptCore for binary compatibility with iOS12.
2077         We need this symbol to be in a file that doesn't include anything because libcxx's implementation of
2078         std::optional is actually std::__1::optional, which has a different mangled name.  This change will
2079         prevent protocol errors from being reported if you are running the iOS12 simulator with a custom build of WebKit
2080         and using the web inspector with it, but it's necessary to allow us to start using C++17 in WebKit.
2081
2082         * JavaScriptCore.xcodeproj/project.pbxproj:
2083         * inspector/InspectorBackendDispatcher.cpp:
2084         * inspector/InspectorBackendDispatcher.h:
2085         * inspector/InspectorBackendDispatcherCompatibility.cpp: Added.
2086         (Inspector::BackendDispatcher::reportProtocolError):
2087         * inspector/InspectorBackendDispatcherCompatibility.h: Added.
2088
2089 2019-04-24  Saam Barati  <sbarati@apple.com>
2090
2091         Add SPI callbacks for before and after module execution
2092         https://bugs.webkit.org/show_bug.cgi?id=197244
2093         <rdar://problem/50180511>
2094
2095         Reviewed by Yusuke Suzuki.
2096
2097         This is helpful for clients that want to profile execution of modules
2098         in some way. E.g, if they want to time module execution time.
2099
2100         * API/JSAPIGlobalObject.h:
2101         * API/JSAPIGlobalObject.mm:
2102         (JSC::JSAPIGlobalObject::moduleLoaderEvaluate):
2103         * API/JSContextPrivate.h:
2104         * API/tests/testapi.mm:
2105         (+[JSContextFetchDelegate contextWithBlockForFetch:]):
2106         (-[JSContextFetchDelegate willEvaluateModule:]):
2107         (-[JSContextFetchDelegate didEvaluateModule:]):
2108         (testFetch):
2109         (testFetchWithTwoCycle):
2110         (testFetchWithThreeCycle):
2111         (testLoaderResolvesAbsoluteScriptURL):
2112         (testLoaderRejectsNilScriptURL):
2113         * runtime/JSModuleLoader.cpp:
2114         (JSC::JSModuleLoader::evaluate):
2115         (JSC::JSModuleLoader::evaluateNonVirtual):
2116         * runtime/JSModuleLoader.h:
2117
2118 2019-04-23  Yusuke Suzuki  <ysuzuki@apple.com>
2119
2120         [JSC] Shrink DFG::MinifiedNode
2121         https://bugs.webkit.org/show_bug.cgi?id=197224
2122
2123         Reviewed by Filip Pizlo.
2124
2125         Since it is kept alive with compiled DFG code, we should shrink it to save memory.
2126         If it is effective, we should consider minimizing these OSR exit data more aggressively.
2127
2128         * dfg/DFGMinifiedNode.h:
2129
2130 2019-04-23  Saam Barati  <sbarati@apple.com>
2131
2132         LICM incorrectly assumes it'll never insert a node which provably OSR exits
2133         https://bugs.webkit.org/show_bug.cgi?id=196721
2134         <rdar://problem/49556479> 
2135
2136         Reviewed by Filip Pizlo.
2137
2138         Previously, we assumed LICM could never hoist code that caused us
2139         to provably OSR exit. This is a bad assumption, as we may very well
2140         hoist such code. Obviously hoisting such code is not ideal. We shouldn't
2141         hoist something we provably know will OSR exit. However, this is super rare,
2142         and the phase is written in such a way where it's easier to gracefully
2143         handle this case than to prevent us from hoisting such code.
2144         
2145         If we wanted to ensure we never hoisted code that would provably exit, we'd
2146         have to teach the phase to know when it inserted code that provably exits. I
2147         saw two ways to do that:
2148         1: Save and restore the AI state before actually hoisting.
2149         2: Write an analysis that can determine if such a node would exit.
2150         
2151         (1) is bad because it costs in memory and compile time. (2) will inevitably
2152         have bugs as running into this condition is rare.
2153         
2154         So instead of (1) or (2), I opted to have LICM gracefully handle when
2155         it causes a provable exit. When we encounter this, we mark all blocks
2156         in the loop as !cfaHasVisited and !cfaDidFinish.
2157
2158         * dfg/DFGLICMPhase.cpp:
2159         (JSC::DFG::LICMPhase::attemptHoist):
2160
2161 2019-04-23  Yusuke Suzuki  <ysuzuki@apple.com>
2162
2163         [JSC] Use node index as DFG::MinifiedID
2164         https://bugs.webkit.org/show_bug.cgi?id=197186
2165
2166         Reviewed by Saam Barati.
2167
2168         DFG Nodes can be identified with index if the graph is given. We should use unsigned index as a DFG::MinifiedID's underlying
2169         source instead of Node* to reduce the size of VariableEvent from 16 to 12. Vector<VariableEvent> is the main data in DFG's OSR
2170         tracking. It is kept after DFG compilation is done to make OSR work. We saw that this is allocated with large size in GMail.
2171
2172         * JavaScriptCore.xcodeproj/project.pbxproj:
2173         * bytecode/DataFormat.h:
2174         * bytecode/ValueRecovery.h:
2175         * dfg/DFGGenerationInfo.h:
2176         * dfg/DFGMinifiedID.h:
2177         (JSC::DFG::MinifiedID::MinifiedID):
2178         (JSC::DFG::MinifiedID::operator! const):
2179         (JSC::DFG::MinifiedID::operator== const):
2180         (JSC::DFG::MinifiedID::operator!= const):
2181         (JSC::DFG::MinifiedID::operator< const):
2182         (JSC::DFG::MinifiedID::operator> const):
2183         (JSC::DFG::MinifiedID::operator<= const):
2184         (JSC::DFG::MinifiedID::operator>= const):
2185         (JSC::DFG::MinifiedID::hash const):
2186         (JSC::DFG::MinifiedID::dump const):
2187         (JSC::DFG::MinifiedID::isHashTableDeletedValue const):
2188         (JSC::DFG::MinifiedID::fromBits):
2189         (JSC::DFG::MinifiedID::bits const):
2190         (JSC::DFG::MinifiedID::invalidIndex):
2191         (JSC::DFG::MinifiedID::otherInvalidIndex):
2192         (JSC::DFG::MinifiedID::node const): Deleted.
2193         (JSC::DFG::MinifiedID::invalidID): Deleted.
2194         (JSC::DFG::MinifiedID::otherInvalidID): Deleted.
2195         * dfg/DFGMinifiedIDInlines.h: Copied from Source/JavaScriptCore/dfg/DFGMinifiedNode.cpp.
2196         (JSC::DFG::MinifiedID::MinifiedID):
2197         * dfg/DFGMinifiedNode.cpp:
2198         * dfg/DFGValueSource.h:
2199         (JSC::DFG::ValueSource::ValueSource):
2200         * dfg/DFGVariableEvent.h:
2201         (JSC::DFG::VariableEvent::dataFormat const):
2202
2203 2019-04-23  Keith Rollin  <krollin@apple.com>
2204
2205         Add Xcode version check for Header post-processing scripts
2206         https://bugs.webkit.org/show_bug.cgi?id=197116
2207         <rdar://problem/50058968>
2208
2209         Reviewed by Brent Fulgham.
2210
2211         There are several places in our Xcode projects that post-process
2212         header files after they've been exported. Because of XCBuild, we're
2213         moving to a model where the post-processing is performed at the same
2214         time the header files are exported, rather than as a distinct
2215         post-processing step. This patch disables the distinct step when the
2216         inline processing is available.
2217
2218         In practice, this means prefixing appropriate post-processing Custom
2219         Build phases with:
2220
2221         if [ "${XCODE_VERSION_MAJOR}" -ge "1100" -a "${USE_NEW_BUILD_SYSTEM}" = "YES" ]; then
2222             # In this configuration, post-processing is performed at the same time as copying in the postprocess-header-rule script, so there's no need for this separate step.
2223             exit 0
2224         fi
2225
2226         * JavaScriptCore.xcodeproj/project.pbxproj:
2227
2228 2019-04-23  Commit Queue  <commit-queue@webkit.org>
2229
2230         Unreviewed, rolling out r244558.
2231         https://bugs.webkit.org/show_bug.cgi?id=197219
2232
2233         Causing crashes on iOS Sim Release and Debug (Requested by
2234         ShawnRoberts on #webkit).
2235
2236         Reverted changeset:
2237
2238         "Remove DeprecatedOptional"
2239         https://bugs.webkit.org/show_bug.cgi?id=197161
2240         https://trac.webkit.org/changeset/244558
2241
2242 2019-04-23  Devin Rousso  <drousso@apple.com>
2243
2244         Web Inspector: Uncaught Exception: null is not an object (evaluating 'this.ownerDocument.frameIdentifier')
2245         https://bugs.webkit.org/show_bug.cgi?id=196420
2246         <rdar://problem/49444205>
2247
2248         Reviewed by Timothy Hatcher.
2249
2250         * inspector/protocol/DOM.json:
2251         Modify the existing `frameId` to represent the owner frame of the node, rather than the
2252         frame it holds (in the case of an `<iframe>`).
2253
2254 2019-04-23  Alex Christensen  <achristensen@webkit.org>
2255
2256         Remove DeprecatedOptional
2257         https://bugs.webkit.org/show_bug.cgi?id=197161
2258
2259         Reviewed by Darin Adler.
2260
2261         * inspector/InspectorBackendDispatcher.cpp:
2262         * inspector/InspectorBackendDispatcher.h:
2263
2264 2019-04-22  Yusuke Suzuki  <ysuzuki@apple.com>
2265
2266         [JSC] Use volatile load to populate backing page in MarkedBlock::Footer instead of using holdLock
2267         https://bugs.webkit.org/show_bug.cgi?id=197152
2268
2269         Reviewed by Saam Barati.
2270
2271         Emit volatile load instead of using holdLock to populate backing page in MarkedBlock::Footer.
2272
2273         * heap/BlockDirectory.cpp:
2274         (JSC::BlockDirectory::isPagedOut):
2275         * heap/MarkedBlock.h:
2276         (JSC::MarkedBlock::populatePage const):
2277
2278 2019-04-22  Yusuke Suzuki  <ysuzuki@apple.com>
2279
2280         [JSC] useJIT should subsume useRegExpJIT
2281         https://bugs.webkit.org/show_bug.cgi?id=197153
2282
2283         Reviewed by Alex Christensen.
2284
2285         useJIT should subsume useRegExpJIT. We should immediately disable JIT feature if useJIT = false,
2286         even if useRegExpJIT is true.
2287
2288         * dfg/DFGCapabilities.cpp:
2289         (JSC::DFG::isSupported):
2290         * runtime/Options.cpp:
2291         (JSC::recomputeDependentOptions):
2292         * runtime/RegExp.cpp:
2293         (JSC::RegExp::compile):
2294         (JSC::RegExp::compileMatchOnly):
2295         * runtime/VM.cpp:
2296         (JSC::enableAssembler):
2297         (JSC::VM::canUseRegExpJIT): Deleted.
2298         * runtime/VM.h:
2299
2300 2019-04-22  Basuke Suzuki  <basuke.suzuki@sony.com>
2301
2302         [PlayStation] Restructuring Remote Inspector classes to support multiple platform.
2303         https://bugs.webkit.org/show_bug.cgi?id=197030
2304
2305         Reviewed by Don Olmstead.
2306
2307         Restructuring the PlayStation's RemoteInspector backend which uses native socket for the communication to be ready for WinCairo.
2308
2309         What we did is basically:
2310         - Renamed `remote/playstation/` to `remote/socket/`. This directory is now platform independent implementation of socket backend. 
2311         - Renamed `RemoteInspectorSocket` class to `RemoteInspectorSocketEndpoint`. This class is platform independent and core of the backend.
2312         - Merged `RemoteInspectorSocket{Client|Server}` classes into `RemoteInspectorSocketEndpoint` class because the differences are little.
2313         - Defined a new interface functions in `Inspector::Socket` (new) namespace.
2314         - Moved POSIX socket implementation into `posix\RemoteInspectorSocketPOSIX.{h|cpp}`.
2315
2316         * PlatformPlayStation.cmake:
2317         * inspector/remote/RemoteInspector.h:
2318         * inspector/remote/playstation/RemoteInspectorSocketClient.h: Merged into RemoteInspectorSocketEndpoint.
2319         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
2320         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Removed.
2321         * inspector/remote/playstation/RemoteInspectorSocketServer.h: Merged into RemoteInspectorSocketEndpoint.
2322         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
2323         * inspector/remote/socket/RemoteInspectorConnectionClient.cpp: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClientPlayStation.cpp.
2324         * inspector/remote/socket/RemoteInspectorConnectionClient.h: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClient.h.
2325         (Inspector::RemoteInspectorConnectionClient::didAccept):
2326         * inspector/remote/socket/RemoteInspectorMessageParser.cpp: Renamed from inspector\remote\playstation\RemoteInspectorMessageParserPlayStation.cpp.
2327         * inspector/remote/socket/RemoteInspectorMessageParser.h: Renamed from inspector\remote\playstation\RemoteInspectorMessageParser.h.
2328         * inspector/remote/socket/RemoteInspectorServer.cpp: Renamed from inspector\remote\playstation\RemoteInspectorServerPlayStation.cpp.
2329         (Inspector::RemoteInspectorServer::didAccept):
2330         (Inspector::RemoteInspectorServer::start):
2331         * inspector/remote/socket/RemoteInspectorServer.h: Renamed from inspector\remote\playstation\RemoteInspectorServer.h.
2332         * inspector/remote/socket/RemoteInspectorSocket.cpp: Renamed from inspector\remote\playstation\RemoteInspectorPlayStation.cpp.
2333         (Inspector::RemoteInspector::start):
2334         * inspector/remote/socket/RemoteInspectorSocket.h: Copied from inspector\remote\playstation\RemoteInspectorSocket.h.
2335         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp: Added.
2336         (Inspector::RemoteInspectorSocketEndpoint::RemoteInspectorSocketEndpoint):
2337         (Inspector::RemoteInspectorSocketEndpoint::~RemoteInspectorSocketEndpoint):
2338         (Inspector::RemoteInspectorSocketEndpoint::wakeupWorkerThread):
2339         (Inspector::RemoteInspectorSocketEndpoint::connectInet):
2340         (Inspector::RemoteInspectorSocketEndpoint::listenInet):
2341         (Inspector::RemoteInspectorSocketEndpoint::isListening):
2342         (Inspector::RemoteInspectorSocketEndpoint::workerThread):
2343         (Inspector::RemoteInspectorSocketEndpoint::createClient):
2344         (Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
2345         (Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
2346         (Inspector::RemoteInspectorSocketEndpoint::send):
2347         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
2348         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h: Renamed from inspector\remote\playstation\RemoteInspectorSocket.h.
2349         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp: Added.
2350         (Inspector::Socket::connect):
2351         (Inspector::Socket::listen):
2352         (Inspector::Socket::accept):
2353         (Inspector::Socket::createPair):
2354         (Inspector::Socket::setup):
2355         (Inspector::Socket::isValid):
2356         (Inspector::Socket::isListening):
2357         (Inspector::Socket::read):
2358         (Inspector::Socket::write):
2359         (Inspector::Socket::close):
2360         (Inspector::Socket::preparePolling):
2361         (Inspector::Socket::poll):
2362         (Inspector::Socket::isReadable):
2363         (Inspector::Socket::isWritable):
2364         (Inspector::Socket::markWaitingWritable):
2365         (Inspector::Socket::clearWaitingWritable):
2366
2367 2019-04-20  Yusuke Suzuki  <ysuzuki@apple.com>
2368
2369         Unreviewed, suppress warnings in non Darwin environments
2370
2371         * jit/ExecutableAllocator.cpp:
2372         (JSC::dumpJITMemory):
2373
2374 2019-04-19  Saam Barati  <sbarati@apple.com>
2375
2376         AbstractValue can represent more than int52
2377         https://bugs.webkit.org/show_bug.cgi?id=197118
2378         <rdar://problem/49969960>
2379
2380         Reviewed by Michael Saboff.
2381
2382         Let's analyze this control flow diamond:
2383         
2384         #0
2385         branch #1, #2
2386         
2387         #1:
2388         PutStack(JSValue, loc42)
2389         Jump #3
2390         
2391         #2:
2392         PutStack(Int52, loc42)
2393         Jump #3
2394         
2395         #3:
2396         ...
2397         
2398         Our abstract value for loc42 at the head of #3 will contain an abstract
2399         value that us the union of Int52 with other things. Obviously in the
2400         above program, a GetStack for loc42 would be inavlid, since it might
2401         be loading either JSValue or Int52. However, the abstract interpreter
2402         just tracks what the value could be, and it could be Int52 or JSValue.
2403         
2404         When I did the Int52 refactoring, I expected such things to never happen,
2405         but it turns out it does. We should just allow for this instead of asserting
2406         against it since it's valid IR to do the above.
2407
2408         * bytecode/SpeculatedType.cpp:
2409         (JSC::dumpSpeculation):
2410         * dfg/DFGAbstractValue.cpp:
2411         (JSC::DFG::AbstractValue::checkConsistency const):
2412         * dfg/DFGAbstractValue.h:
2413         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
2414
2415 2019-04-19  Tadeu Zagallo  <tzagallo@apple.com>
2416
2417         Add option to dump JIT memory
2418         https://bugs.webkit.org/show_bug.cgi?id=197062
2419         <rdar://problem/49744332>
2420
2421         Reviewed by Saam Barati.
2422
2423         Dump all writes into JIT memory to the specified file. The format is:
2424         - 64-bit destination address for the write
2425         - 64-bit size of the content written
2426         - Copy of the data that was written to JIT memory
2427
2428         * assembler/LinkBuffer.cpp:
2429         (JSC::LinkBuffer::copyCompactAndLinkCode):
2430         * jit/ExecutableAllocator.cpp:
2431         (JSC::dumpJITMemory):
2432         * jit/ExecutableAllocator.h:
2433         (JSC::performJITMemcpy):
2434         * runtime/Options.h:
2435
2436 2019-04-19  Keith Rollin  <krollin@apple.com>
2437
2438         Add postprocess-header-rule scripts
2439         https://bugs.webkit.org/show_bug.cgi?id=197072
2440         <rdar://problem/50027299>
2441
2442         Reviewed by Brent Fulgham.
2443
2444         Several projects have post-processing build phases where exported
2445         headers are tweaked after they've been copied. This post-processing is
2446         performed via scripts called postprocess-headers.sh. For reasons
2447         related to XCBuild, we are now transitioning to a build process where
2448         the post-processing is performed at the same time as the
2449         exporting/copying. To support this process, add similar scripts named
2450         postprocess-header-rule, which are geared towards processing a single
2451         file at a time rather than all exported files at once. Also add a
2452         build rule that makes use of these scripts. These scripts and build
2453         rules are not used at the moment; they will come into use in an
2454         imminent patch.
2455
2456         Note that I've named these postprocess-header-rule rather than
2457         postprocess-header-rule.sh. Scripts in Tools/Scripts do not have
2458         suffixes indicating how the tool is implemented. Scripts in
2459         per-project Scripts folders appear to be mixed regarding the use of
2460         suffixes. I'm opting here to follow the Tools/Scripts convention, with
2461         the expectation that over time we completely standardize on that.
2462
2463         * JavaScriptCore.xcodeproj/project.pbxproj:
2464         * Scripts/postprocess-header-rule: Added.
2465
2466 2019-04-18  Saam barati  <sbarati@apple.com>
2467
2468         Remove useConcurrentBarriers option
2469         https://bugs.webkit.org/show_bug.cgi?id=197066
2470
2471         Reviewed by Michael Saboff.
2472
2473         This isn't a helpful option as it will lead us to crash when using the
2474         concurrent GC.
2475
2476         * dfg/DFGStoreBarrierClusteringPhase.cpp:
2477         * dfg/DFGStoreBarrierInsertionPhase.cpp:
2478         * jit/AssemblyHelpers.h:
2479         (JSC::AssemblyHelpers::barrierStoreLoadFence):
2480         * runtime/Options.h:
2481
2482 2019-04-17  Saam Barati  <sbarati@apple.com>
2483
2484         Remove deprecated JSScript SPI
2485         https://bugs.webkit.org/show_bug.cgi?id=194909
2486         <rdar://problem/48283499>
2487
2488         Reviewed by Keith Miller.
2489
2490         * API/JSAPIGlobalObject.mm:
2491         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
2492         * API/JSScript.h:
2493         * API/JSScript.mm:
2494         (+[JSScript scriptWithSource:inVirtualMachine:]): Deleted.
2495         (fillBufferWithContentsOfFile): Deleted.
2496         (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
2497         (+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
2498         (-[JSScript setSourceURL:]): Deleted.
2499         * API/JSScriptInternal.h:
2500         * API/tests/testapi.mm:
2501         (testFetch):
2502         (testFetchWithTwoCycle):
2503         (testFetchWithThreeCycle):
2504         (testLoaderResolvesAbsoluteScriptURL):
2505         (testImportModuleTwice):
2506         (-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
2507
2508 2019-04-17  Keith Rollin  <krollin@apple.com>
2509
2510         Remove JSCBuiltins.cpp from Copy Headers phase
2511         https://bugs.webkit.org/show_bug.cgi?id=196981
2512         <rdar://problem/49952133>
2513
2514         Reviewed by Alex Christensen.
2515
2516         JSCBuiltins.cpp is not a header and so doesn't need to be in the Copy
2517         Headers phase. Checking its history, it seems to have been added
2518         accidentally at the same time that JSCBuiltins.h was added.
2519
2520         * JavaScriptCore.xcodeproj/project.pbxproj:
2521
2522 2019-04-16  Stephan Szabo  <stephan.szabo@sony.com>
2523
2524         [PlayStation] Update port for system library changes
2525         https://bugs.webkit.org/show_bug.cgi?id=196978
2526
2527         Reviewed by Ross Kirsling.
2528
2529         * shell/playstation/Initializer.cpp:
2530         Add reference to new posix compatibility library.
2531
2532 2019-04-16  Robin Morisset  <rmorisset@apple.com>
2533
2534         [WTF] holdLock should be marked WARN_UNUSED_RETURN
2535         https://bugs.webkit.org/show_bug.cgi?id=196922
2536
2537         Reviewed by Keith Miller.
2538
2539         There was one case where holdLock was used and the result ignored.
2540         From a comment that was deleted in https://bugs.webkit.org/attachment.cgi?id=328438&action=prettypatch, I believe that it is on purpose.
2541         So I brought back a variant of the comment, and made the ignoring of the return explicit.
2542
2543         * heap/BlockDirectory.cpp:
2544         (JSC::BlockDirectory::isPagedOut):
2545
2546 2019-04-16  Caitlin Potter  <caitp@igalia.com>
2547
2548         [JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
2549         https://bugs.webkit.org/show_bug.cgi?id=176810
2550
2551         Reviewed by Saam Barati.
2552
2553         This adds conditional logic following the invariant checks, to perform
2554         filtering in common uses of getOwnPropertyNames.
2555
2556         While this would ideally only be done in JSPropertyNameEnumerator, adding
2557         the filtering to ProxyObject::performGetOwnPropertyNames maintains the
2558         invariant that the EnumerationMode is properly followed.
2559
2560         This was originally rolled out in r244020, as DontEnum filtering code
2561         in ObjectConstructor.cpp's ownPropertyKeys() had not been removed. It's
2562         now redundant due to being handled in ProxyObject::getOwnPropertyNames().
2563
2564         * runtime/PropertyNameArray.h:
2565         (JSC::PropertyNameArray::reset):
2566         * runtime/ProxyObject.cpp:
2567         (JSC::ProxyObject::performGetOwnPropertyNames):
2568
2569 2019-04-15  Saam barati  <sbarati@apple.com>
2570
2571         Modify how we do SetArgument when we inline varargs calls
2572         https://bugs.webkit.org/show_bug.cgi?id=196712
2573         <rdar://problem/49605012>
2574
2575         Reviewed by Michael Saboff.
2576
2577         When we inline varargs calls, we guarantee that the number of arguments that
2578         go on the stack are somewhere between the "mandatoryMinimum" and the "limit - 1".
2579         However, we can't statically guarantee that the arguments between these two
2580         ranges was filled out by Load/ForwardVarargs. This is because in the general
2581         case we don't know the argument count statically.
2582         
2583         However, we used to always emit SetArgumentDefinitely up to "limit - 1" for
2584         all arguments, even when some arguments aren't guaranteed to be in a valid
2585         state. Emitting these SetArgumentDefinitely were helpful because they let us
2586         handle variable liveness and OSR exit metadata. However, when we converted
2587         to SSA, we ended up emitting a GetStack for each such SetArgumentDefinitely.
2588         
2589         This is wrong, as we can't guarantee such SetArgumentDefinitely nodes are
2590         actually looking at a range of the stack that are guaranteed to be initialized.
2591         This patch introduces a new form of SetArgument node: SetArgumentMaybe. In terms
2592         of OSR exit metadata and variable liveness tracking, it behaves like SetArgumentDefinitely.
2593         
2594         However, it differs in a couple key ways:
2595         1. In ThreadedCPS, GetLocal(@SetArgumentMaybe) is invalid IR, as this implies
2596         you might be loading uninitialized stack. (This same rule applies when you do
2597         the full data flow reachability analysis over CPS Phis.) If someone logically
2598         wanted to emit code like this, the correct node to emit would be GetArgument,
2599         not GetLocal. For similar reasons, PhantomLocal(@SetArgumentMaybe) is also
2600         invalid IR.
2601         2. To track liveness, Flush(@SetArgumentMaybe) is valid, and is the main user
2602         of SetArgumentMaybe.
2603         3. In SSA conversion, we don't lower SetArgumentMaybe to GetStack, as there
2604         should be no data flow user of SetArgumentMaybe.
2605         
2606         SetArgumentDefinitely guarantees that the stack slot is initialized.
2607         SetArgumentMaybe makes no such guarantee.
2608
2609         * dfg/DFGAbstractInterpreterInlines.h:
2610         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2611         * dfg/DFGByteCodeParser.cpp:
2612         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
2613         * dfg/DFGCPSRethreadingPhase.cpp:
2614         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
2615         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2616         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
2617         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
2618         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
2619         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
2620         * dfg/DFGClobberize.h:
2621         (JSC::DFG::clobberize):
2622         * dfg/DFGCommon.h:
2623         * dfg/DFGDoesGC.cpp:
2624         (JSC::DFG::doesGC):
2625         * dfg/DFGFixupPhase.cpp:
2626         (JSC::DFG::FixupPhase::fixupNode):
2627         * dfg/DFGInPlaceAbstractState.cpp:
2628         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
2629         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2630         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
2631         * dfg/DFGMaximalFlushInsertionPhase.cpp:
2632         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
2633         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
2634         * dfg/DFGMayExit.cpp:
2635         * dfg/DFGNode.cpp:
2636         (JSC::DFG::Node::hasVariableAccessData):
2637         * dfg/DFGNodeType.h:
2638         * dfg/DFGPhantomInsertionPhase.cpp:
2639         * dfg/DFGPredictionPropagationPhase.cpp:
2640         * dfg/DFGSSAConversionPhase.cpp:
2641         (JSC::DFG::SSAConversionPhase::run):
2642         * dfg/DFGSafeToExecute.h:
2643         (JSC::DFG::safeToExecute):
2644         * dfg/DFGSpeculativeJIT32_64.cpp:
2645         (JSC::DFG::SpeculativeJIT::compile):
2646         * dfg/DFGSpeculativeJIT64.cpp:
2647         (JSC::DFG::SpeculativeJIT::compile):
2648         * dfg/DFGValidate.cpp:
2649         * ftl/FTLCapabilities.cpp:
2650         (JSC::FTL::canCompile):
2651
2652 2019-04-15  Commit Queue  <commit-queue@webkit.org>
2653
2654         Unreviewed, rolling out r243672.
2655         https://bugs.webkit.org/show_bug.cgi?id=196952
2656
2657         [JSValue release] should be thread-safe (Requested by
2658         yusukesuzuki on #webkit).
2659
2660         Reverted changeset:
2661
2662         "[JSC] JSWrapperMap should not use Objective-C Weak map
2663         (NSMapTable with NSPointerFunctionsWeakMemory) for
2664         m_cachedObjCWrappers"
2665         https://bugs.webkit.org/show_bug.cgi?id=196392
2666         https://trac.webkit.org/changeset/243672
2667
2668 2019-04-15  Saam barati  <sbarati@apple.com>
2669
2670         SafeToExecute for GetByOffset/GetGetterByOffset/PutByOffset is using the wrong child for the base
2671         https://bugs.webkit.org/show_bug.cgi?id=196945
2672         <rdar://problem/49802750>
2673
2674         Reviewed by Filip Pizlo.
2675
2676         * dfg/DFGSafeToExecute.h:
2677         (JSC::DFG::safeToExecute):
2678
2679 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2680
2681         DFG should be able to constant fold Object.create() with a constant prototype operand
2682         https://bugs.webkit.org/show_bug.cgi?id=196886
2683
2684         Reviewed by Yusuke Suzuki.
2685
2686
2687         It is a fairly simple and limited patch, as it only works when the DFG can prove the exact object used as prototype.
2688         But when it applies it can be a significant win:
2689                                                         Baseline                   Optim                                       
2690         object-create-constant-prototype              3.6082+-0.0979     ^      1.6947+-0.0756        ^ definitely 2.1292x faster
2691         object-create-null                           11.4492+-0.2510     ?     11.5030+-0.2402        ?
2692         object-create-unknown-object-prototype       15.6067+-0.1851     ?     15.7500+-0.2322        ?
2693         object-create-untyped-prototype               8.8873+-0.1240     ?      8.9806+-0.1202        ? might be 1.0105x slower
2694         <geometric>                                   8.6967+-0.1208     ^      7.2408+-0.1367        ^ definitely 1.2011x faster
2695
2696         The only subtlety is that we need to to access the StructureCache concurrently from the compiler thread (see https://bugs.webkit.org/show_bug.cgi?id=186199)
2697         I solved this with a simple lock, taken when the compiler thread tries to read it, and when the main thread tries to modify it.
2698         I expect it to be extremely low contention, but will watch the bots just in case.
2699         The lock is taken neither when the main thread is only reading the cache (it has no-one to race with), nor when the GC purges it of dead entries (it does not free anything while a compiler thread is in the middle of a phase).
2700
2701         * dfg/DFGAbstractInterpreterInlines.h:
2702         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2703         * dfg/DFGConstantFoldingPhase.cpp:
2704         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2705         * runtime/StructureCache.cpp:
2706         (JSC::StructureCache::createEmptyStructure):
2707         (JSC::StructureCache::tryEmptyObjectStructureForPrototypeFromCompilerThread):
2708         * runtime/StructureCache.h:
2709
2710 2019-04-15  Devin Rousso  <drousso@apple.com>
2711
2712         Web Inspector: fake value descriptors for promises add a catch handler, preventing "rejectionhandled" events from being fired
2713         https://bugs.webkit.org/show_bug.cgi?id=196484
2714         <rdar://problem/49114725>
2715
2716         Reviewed by Joseph Pecoraro.
2717
2718         Only add a catch handler when the promise is reachable via a native getter and is known to
2719         have rejected. A non-rejected promise doesn't need a catch handler, and any promise that
2720         isn't reachable via a getter won't actually be reached, as `InjectedScript` doesn't call any
2721         functions, instead only getting the function object itself.
2722
2723         * inspector/InjectedScriptSource.js:
2724         (InjectedScript.prototype._propertyDescriptors.createFakeValueDescriptor):
2725
2726         * inspector/JSInjectedScriptHost.h:
2727         * inspector/JSInjectedScriptHost.cpp:
2728         (Inspector::JSInjectedScriptHost::isPromiseRejectedWithNativeGetterTypeError): Added.
2729         * inspector/JSInjectedScriptHostPrototype.cpp:
2730         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
2731         (Inspector::jsInjectedScriptHostPrototypeFunctionIsPromiseRejectedWithNativeGetterTypeError): Added.
2732
2733         * runtime/ErrorInstance.h:
2734         (JSC::ErrorInstance::setNativeGetterTypeError): Added.
2735         (JSC::ErrorInstance::isNativeGetterTypeError const): Added.
2736
2737         * runtime/Error.h:
2738         (JSC::throwVMGetterTypeError): Added.
2739         * runtime/Error.cpp:
2740         (JSC::createGetterTypeError): Added.
2741         (JSC::throwGetterTypeError): Added.
2742         (JSC::throwDOMAttributeGetterTypeError):
2743
2744 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2745
2746         B3::Value should have different kinds of adjacency lists
2747         https://bugs.webkit.org/show_bug.cgi?id=196091
2748
2749         Reviewed by Filip Pizlo.
2750
2751         The key idea of this optimization is to replace the Vector<Value*, 3> m_children in B3::Value (40 bytes on 64-bits platform) by one of the following:
2752         - Nothing (0 bytes)
2753         - 1 Value* (8 bytes)
2754         - 2 Value* (16 bytes)
2755         - 3 Value* (24 bytes)
2756         - A Vector<Value*, 3>
2757         after the end of the Value object, depending on the kind of the Value.
2758         So for example, when allocating an Add, we would allocate an extra 16 bytes into which to store 2 Values.
2759         This would halve the memory consumption of Const64/Const32/Nop/Identity and a bunch more kinds of values, and reduce by a more moderate amount the memory consumption of the rest of non-varargs values (e.g. Add would go from 72 to 48 bytes).
2760
2761         A few implementation points:
2762         - Even if there is no children, we must remember to allocate at least enough space for replaceWithIdentity to work later. It needs sizeof(Value) (for the object itself) + sizeof(Value*) (for the pointer to its child)
2763         - We must make sure to destroy the vector whenever we destroy a Value which is VarArgs
2764         - We must remember how many elements there are in the case where we did not allocate a Vector. We cannot do it purely by relying on the kind, both for speed reasons and because Return can have either 0 or 1 argument in B3
2765           Thankfully, we have an extra byte of padding to use in the middle of B3::Value
2766         - In order to support clone(), we must have a separate version of allocate, which extracts the opcode from the to-be-cloned object instead of from the call to the constructor
2767         - Speaking of which, we need a special templated function opcodeFromConstructor, because some of the constructors of subclasses of Value don't take an explicit Opcode as argument, typically because they match a single one.
2768         - To maximize performance, we provide specialized versions of child/lastChild/numChildren/children in the subclasses of Value, skipping checks when the actual type of the Value is already known.
2769           This is done through the B3_SPECIALIZE_VALUE_FOR_... defined at the bottom of B3Value.h
2770         - In the constructors of Value, we convert all extra children arguments to Value* eagerly. It is not required for correctness (they will be converted when put into a Vector<Value*> or a Value* in the end), but it helps limit an explosion in the number of template instantiations.
2771         - I moved DeepValueDump::dump from the .h to the .cpp, as there is no good reason to inline it, and recompiling JSC is already slow enough
2772
2773         * JavaScriptCore.xcodeproj/project.pbxproj:
2774         * b3/B3ArgumentRegValue.cpp:
2775         (JSC::B3::ArgumentRegValue::cloneImpl const): Deleted.
2776         * b3/B3ArgumentRegValue.h:
2777         * b3/B3AtomicValue.cpp:
2778         (JSC::B3::AtomicValue::AtomicValue):
2779         (JSC::B3::AtomicValue::cloneImpl const): Deleted.
2780         * b3/B3AtomicValue.h:
2781         * b3/B3BasicBlock.h:
2782         * b3/B3BasicBlockInlines.h:
2783         (JSC::B3::BasicBlock::appendNewNonTerminal): Deleted.
2784         * b3/B3CCallValue.cpp:
2785         (JSC::B3::CCallValue::appendArgs):
2786         (JSC::B3::CCallValue::cloneImpl const): Deleted.
2787         * b3/B3CCallValue.h:
2788         * b3/B3CheckValue.cpp:
2789         (JSC::B3::CheckValue::cloneImpl const): Deleted.
2790         * b3/B3CheckValue.h:
2791         * b3/B3Const32Value.cpp:
2792         (JSC::B3::Const32Value::cloneImpl const): Deleted.
2793         * b3/B3Const32Value.h:
2794         * b3/B3Const64Value.cpp:
2795         (JSC::B3::Const64Value::cloneImpl const): Deleted.
2796         * b3/B3Const64Value.h:
2797         * b3/B3ConstDoubleValue.cpp:
2798         (JSC::B3::ConstDoubleValue::cloneImpl const): Deleted.
2799         * b3/B3ConstDoubleValue.h:
2800         * b3/B3ConstFloatValue.cpp:
2801         (JSC::B3::ConstFloatValue::cloneImpl const): Deleted.
2802         * b3/B3ConstFloatValue.h:
2803         * b3/B3ConstPtrValue.h:
2804         (JSC::B3::ConstPtrValue::opcodeFromConstructor):
2805         * b3/B3FenceValue.cpp:
2806         (JSC::B3::FenceValue::FenceValue):
2807         (JSC::B3::FenceValue::cloneImpl const): Deleted.
2808         * b3/B3FenceValue.h:
2809         * b3/B3MemoryValue.cpp:
2810         (JSC::B3::MemoryValue::MemoryValue):
2811         (JSC::B3::MemoryValue::cloneImpl const): Deleted.
2812         * b3/B3MemoryValue.h:
2813         * b3/B3MoveConstants.cpp:
2814         * b3/B3PatchpointValue.cpp:
2815         (JSC::B3::PatchpointValue::cloneImpl const): Deleted.
2816         * b3/B3PatchpointValue.h:
2817         (JSC::B3::PatchpointValue::opcodeFromConstructor):
2818         * b3/B3Procedure.cpp:
2819         * b3/B3Procedure.h:
2820         * b3/B3ProcedureInlines.h:
2821         (JSC::B3::Procedure::add):
2822         * b3/B3SlotBaseValue.cpp:
2823         (JSC::B3::SlotBaseValue::cloneImpl const): Deleted.
2824         * b3/B3SlotBaseValue.h:
2825         * b3/B3StackmapSpecial.cpp:
2826         (JSC::B3::StackmapSpecial::forEachArgImpl):
2827         (JSC::B3::StackmapSpecial::isValidImpl):
2828         * b3/B3StackmapValue.cpp:
2829         (JSC::B3::StackmapValue::append):
2830         (JSC::B3::StackmapValue::StackmapValue):
2831         * b3/B3StackmapValue.h:
2832         * b3/B3SwitchValue.cpp:
2833         (JSC::B3::SwitchValue::SwitchValue):
2834         (JSC::B3::SwitchValue::cloneImpl const): Deleted.
2835         * b3/B3SwitchValue.h:
2836         (JSC::B3::SwitchValue::opcodeFromConstructor):
2837         * b3/B3UpsilonValue.cpp:
2838         (JSC::B3::UpsilonValue::cloneImpl const): Deleted.
2839         * b3/B3UpsilonValue.h:
2840         * b3/B3Value.cpp:
2841         (JSC::B3::DeepValueDump::dump const):
2842         (JSC::B3::Value::~Value):
2843         (JSC::B3::Value::replaceWithIdentity):
2844         (JSC::B3::Value::replaceWithNopIgnoringType):
2845         (JSC::B3::Value::replaceWithPhi):
2846         (JSC::B3::Value::replaceWithJump):
2847         (JSC::B3::Value::replaceWithOops):
2848         (JSC::B3::Value::replaceWith):
2849         (JSC::B3::Value::invertedCompare const):
2850         (JSC::B3::Value::returnsBool const):
2851         (JSC::B3::Value::cloneImpl const): Deleted.
2852         * b3/B3Value.h:
2853         (JSC::B3::DeepValueDump::dump const): Deleted.
2854         * b3/B3ValueInlines.h:
2855         (JSC::B3::Value::adjacencyListOffset const):
2856         (JSC::B3::Value::cloneImpl const):
2857         * b3/B3VariableValue.cpp:
2858         (JSC::B3::VariableValue::VariableValue):
2859         (JSC::B3::VariableValue::cloneImpl const): Deleted.
2860         * b3/B3VariableValue.h:
2861         * b3/B3WasmAddressValue.cpp:
2862         (JSC::B3::WasmAddressValue::WasmAddressValue):
2863         (JSC::B3::WasmAddressValue::cloneImpl const): Deleted.
2864         * b3/B3WasmAddressValue.h:
2865         * b3/B3WasmBoundsCheckValue.cpp:
2866         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
2867         (JSC::B3::WasmBoundsCheckValue::cloneImpl const): Deleted.
2868         * b3/B3WasmBoundsCheckValue.h:
2869         (JSC::B3::WasmBoundsCheckValue::accepts):
2870         (JSC::B3::WasmBoundsCheckValue::opcodeFromConstructor):
2871         * b3/testb3.cpp:
2872         (JSC::B3::testCallFunctionWithHellaArguments):
2873         (JSC::B3::testCallFunctionWithHellaArguments2):
2874         (JSC::B3::testCallFunctionWithHellaArguments3):
2875         (JSC::B3::testCallFunctionWithHellaDoubleArguments):
2876         (JSC::B3::testCallFunctionWithHellaFloatArguments):
2877         * ftl/FTLOutput.h:
2878         (JSC::FTL::Output::call):
2879
2880 2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>
2881
2882         Bytecode cache should not encode the SourceProvider for UnlinkedFunctionExecutable's classSource
2883         https://bugs.webkit.org/show_bug.cgi?id=196878
2884
2885         Reviewed by Saam Barati.
2886
2887         Every time we encode an (Unlinked)SourceCode, we encode its SourceProvider,
2888         including the full source if it's a StringSourceProvider. This wasn't an issue,
2889         since the SourceCode contains a RefPtr to the SourceProvider, and the Encoder
2890         would avoid encoding the provider multiple times. With the addition of the
2891         incremental cache, each UnlinkedFunctionCodeBlock is encoded in isolation, which
2892         means we can no longer deduplicate it and the full program text was being encoded
2893         multiple times in the cache.
2894         As a work around, this patch adds a custom cached type for encoding the SourceCode
2895         without its provider, and later injects the SourceProvider through the Decoder.
2896
2897         * parser/SourceCode.h:
2898         * parser/UnlinkedSourceCode.h:
2899         (JSC::UnlinkedSourceCode::provider const):
2900         * runtime/CachedTypes.cpp:
2901         (JSC::Decoder::Decoder):
2902         (JSC::Decoder::create):
2903         (JSC::Decoder::provider const):
2904         (JSC::CachedSourceCodeWithoutProvider::encode):
2905         (JSC::CachedSourceCodeWithoutProvider::decode const):
2906         (JSC::decodeCodeBlockImpl):
2907         * runtime/CachedTypes.h:
2908
2909 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2910
2911         MarkedSpace.cpp is not in the Xcode workspace
2912         https://bugs.webkit.org/show_bug.cgi?id=196928
2913
2914         Reviewed by Saam Barati.
2915
2916         * JavaScriptCore.xcodeproj/project.pbxproj:
2917
2918 2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>
2919
2920         Incremental bytecode cache should not append function updates when loaded from memory
2921         https://bugs.webkit.org/show_bug.cgi?id=196865
2922
2923         Reviewed by Filip Pizlo.
2924
2925         Function updates hold the assumption that a function can only be executed/cached
2926         after its containing code block has already been cached. This assumptions does
2927         not hold if the UnlinkedCodeBlock is loaded from memory by the CodeCache, since
2928         we might have two independent SourceProviders executing different paths of the
2929         code and causing the same UnlinkedCodeBlock to be modified in memory.
2930         Use a RefPtr instead of Ref for m_cachedBytecode in ShellSourceProvider to distinguish
2931         between a new, empty cache and a cache that was not loaded and therefore cannot be updated.
2932
2933         * jsc.cpp:
2934         (ShellSourceProvider::ShellSourceProvider):
2935
2936 2019-04-15  Saam barati  <sbarati@apple.com>
2937
2938         mergeOSREntryValue is wrong when the incoming value does not match up with the flush format
2939         https://bugs.webkit.org/show_bug.cgi?id=196918
2940
2941         Reviewed by Yusuke Suzuki.
2942
2943         r244238 lead to some debug failures because we were calling checkConsistency()
2944         before doing fixTypeForRepresentation when merging in must handle values in
2945         CFA. This patch fixes that.
2946         
2947         However, as I was reading over mergeOSREntryValue, I realized it was wrong. It
2948         was possible it could merge in a value/type outside of the variable's flushed type.
2949         Once the flush format types are locked in, we can't introduce a type out of
2950         that range. This probably never lead to any crashes as our profiling injection
2951         and speculation decision code is solid. However, what we were doing is clearly
2952         wrong, and something a fuzzer could have found if we fuzzed the must handle
2953         values inside prediction injection. We should do that fuzzing:
2954         https://bugs.webkit.org/show_bug.cgi?id=196924
2955
2956         * dfg/DFGAbstractValue.cpp:
2957         (JSC::DFG::AbstractValue::mergeOSREntryValue):
2958         * dfg/DFGAbstractValue.h:
2959         * dfg/DFGCFAPhase.cpp:
2960         (JSC::DFG::CFAPhase::injectOSR):
2961
2962 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2963
2964         Several structures and enums in the Yarr interpreter can be shrunk
2965         https://bugs.webkit.org/show_bug.cgi?id=196923
2966
2967         Reviewed by Saam Barati.
2968
2969         YarrOp: 88 -> 80
2970         RegularExpression: 40 -> 32
2971         ByteTerm: 56 -> 48
2972         PatternTerm: 56 -> 48
2973
2974         * yarr/RegularExpression.cpp:
2975         * yarr/YarrInterpreter.h:
2976         * yarr/YarrJIT.cpp:
2977         (JSC::Yarr::YarrGenerator::YarrOp::YarrOp):
2978         * yarr/YarrParser.h:
2979         * yarr/YarrPattern.h:
2980
2981 2019-04-15  Devin Rousso  <drousso@apple.com>
2982
2983         Web Inspector: REGRESSION(r244172): crash when trying to add extra domain while inspecting JSContext
2984         https://bugs.webkit.org/show_bug.cgi?id=196925
2985         <rdar://problem/49873994>
2986
2987         Reviewed by Joseph Pecoraro.
2988
2989         Move the logic for creating the `InspectorAgent` and `InspectorDebuggerAgent` into separate
2990         functions so that callers can be guaranteed to have a valid instance of the agent.
2991
2992         * inspector/JSGlobalObjectInspectorController.h:
2993         * inspector/JSGlobalObjectInspectorController.cpp:
2994         (Inspector::JSGlobalObjectInspectorController::connectFrontend):
2995         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
2996         (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
2997         (Inspector::JSGlobalObjectInspectorController::ensureInspectorAgent): Added.
2998         (Inspector::JSGlobalObjectInspectorController::ensureDebuggerAgent): Added.
2999         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
3000
3001 2019-04-14  Don Olmstead  <don.olmstead@sony.com>
3002
3003         [CMake] JavaScriptCore derived sources should only be referenced inside JavaScriptCore
3004         https://bugs.webkit.org/show_bug.cgi?id=196742
3005
3006         Reviewed by Konstantin Tokarev.
3007
3008         Migrate to using JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOURCES_JAVASCRIPTCORE_DIR
3009         to support moving the JavaScriptCore derived sources outside of a shared directory.
3010
3011         Also use JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOUCES_DIR.
3012
3013         * CMakeLists.txt:
3014
3015 2019-04-13  Tadeu Zagallo  <tzagallo@apple.com>
3016
3017         CodeCache should check that the UnlinkedCodeBlock was successfully created before caching it
3018         https://bugs.webkit.org/show_bug.cgi?id=196880
3019
3020         Reviewed by Yusuke Suzuki.
3021
3022         CodeCache should not tell the SourceProvider to cache the bytecode if it failed
3023         to create the UnlinkedCodeBlock.
3024
3025         * runtime/CodeCache.cpp:
3026         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
3027
3028 2019-04-12  Saam barati  <sbarati@apple.com>
3029
3030         r244079 logically broke shouldSpeculateInt52
3031         https://bugs.webkit.org/show_bug.cgi?id=196884
3032
3033         Reviewed by Yusuke Suzuki.
3034
3035         In r244079, I changed shouldSpeculateInt52 to only return true
3036         when the prediction is isAnyInt52Speculation(). However, it was
3037         wrong to not to include SpecInt32 in this for two reasons:
3038
3039         1. We diligently write code that first checks if we should speculate Int32.
3040         For example:
3041         if (shouldSpeculateInt32()) ... 
3042         else if (shouldSpeculateInt52()) ...
3043
3044         It would be wrong not to fall back to Int52 if we're dealing with the union of
3045         Int32 and Int52.
3046
3047         It would be a performance mistake to not include Int32 here because
3048         data flow can easily tell us that we have variables that are the union
3049         of Int32 and Int52 values. It's better to speculate Int52 than Double
3050         in that situation.
3051
3052         2. We also write code where we ask if the inputs can be Int52, e.g, if
3053         we know via profiling that an Add overflows, we may not emit an Int32 add.
3054         However, we only emit such an add if both inputs can be Int52, and Int32
3055         can trivially become Int52.
3056
3057        This patch recovers the 0.5-1% regression r244079 caused on JetStream 2.
3058
3059         * bytecode/SpeculatedType.h:
3060         (JSC::isInt32SpeculationForArithmetic):
3061         (JSC::isInt32OrBooleanSpeculationForArithmetic):
3062         (JSC::isInt32OrInt52Speculation):
3063         * dfg/DFGFixupPhase.cpp:
3064         (JSC::DFG::FixupPhase::observeUseKindOnNode):
3065         * dfg/DFGNode.h:
3066         (JSC::DFG::Node::shouldSpeculateInt52):
3067         * dfg/DFGPredictionPropagationPhase.cpp:
3068         * dfg/DFGVariableAccessData.cpp:
3069         (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
3070
3071 2019-04-12  Saam barati  <sbarati@apple.com>
3072
3073         Unreviewed. Build fix after r244233.
3074
3075         * assembler/CPU.cpp:
3076
3077 2019-04-12  Saam barati  <sbarati@apple.com>
3078
3079         Sometimes we need to user fewer CPUs in our threading calculations
3080         https://bugs.webkit.org/show_bug.cgi?id=196794
3081         <rdar://problem/49389497>
3082
3083         Reviewed by Yusuke Suzuki.
3084
3085         * JavaScriptCore.xcodeproj/project.pbxproj:
3086         * Sources.txt:
3087         * assembler/CPU.cpp: Added.
3088         (JSC::isKernTCSMAvailable):
3089         (JSC::enableKernTCSM):
3090         (JSC::kernTCSMAwareNumberOfProcessorCores):
3091         * assembler/CPU.h:
3092         (JSC::isKernTCSMAvailable):
3093         (JSC::enableKernTCSM):
3094         (JSC::kernTCSMAwareNumberOfProcessorCores):
3095         * heap/MachineStackMarker.h:
3096         (JSC::MachineThreads::addCurrentThread):
3097         * runtime/JSLock.cpp:
3098         (JSC::JSLock::didAcquireLock):
3099         * runtime/Options.cpp:
3100         (JSC::computeNumberOfWorkerThreads):
3101         (JSC::computePriorityDeltaOfWorkerThreads):
3102         * wasm/WasmWorklist.cpp:
3103         (JSC::Wasm::Worklist::Worklist):
3104
3105 2019-04-12  Robin Morisset  <rmorisset@apple.com>
3106
3107         Use padding at end of ArrayBuffer
3108         https://bugs.webkit.org/show_bug.cgi?id=196823
3109
3110         Reviewed by Filip Pizlo.
3111
3112         * runtime/ArrayBuffer.h:
3113
3114 2019-04-11  Yusuke Suzuki  <ysuzuki@apple.com>
3115
3116         [JSC] op_has_indexed_property should not assume subscript part is Uint32
3117         https://bugs.webkit.org/show_bug.cgi?id=196850
3118
3119         Reviewed by Saam Barati.
3120
3121         op_has_indexed_property assumed that subscript part is always Uint32. However, this is just a load from non-constant RegisterID,
3122         DFG can store it in double format and can perform OSR exit. op_has_indexed_property should not assume that.
3123         In this patch, instead, we check it with isAnyInt and get uint32_t from AnyInt.
3124
3125         * jit/JITOpcodes.cpp:
3126         (JSC::JIT::emit_op_has_indexed_property):
3127         * jit/JITOpcodes32_64.cpp:
3128         (JSC::JIT::emit_op_has_indexed_property):
3129         * jit/JITOperations.cpp:
3130         * runtime/CommonSlowPaths.cpp:
3131         (JSC::SLOW_PATH_DECL):
3132
3133 2019-04-11  Saam barati  <sbarati@apple.com>
3134
3135         Remove invalid assertion in operationInstanceOfCustom
3136         https://bugs.webkit.org/show_bug.cgi?id=196842
3137         <rdar://problem/49725493>
3138
3139         Reviewed by Michael Saboff.
3140
3141         In the generated JIT code, we go to the slow path when the incoming function
3142         isn't the Node's CodeOrigin's functionProtoHasInstanceSymbolFunction. However,
3143         in the JIT operation, we were asserting against exec->lexicalGlobalObject()'s
3144         functionProtoHasInstanceSymbolFunction. That assertion might be wrong when
3145         inlining across global objects as exec->lexicalGlobalObject() uses the machine
3146         frame for procuring the global object. There is no harm when this assertion fails
3147         as we just execute the slow path. This patch removes the assertion. (However, this
3148         does shed light on the deficiency in our exec->lexicalGlobalObject() function with
3149         respect to inlining. However, this isn't new -- we've known about this for a while.)
3150
3151         * jit/JITOperations.cpp:
3152
3153 2019-04-11  Michael Saboff  <msaboff@apple.com>
3154
3155         Improve the Inline Cache Stats code
3156         https://bugs.webkit.org/show_bug.cgi?id=196836
3157
3158         Reviewed by Saam Barati.
3159
3160         Needed to handle the case where the Identifier could be null, for example with InstanceOfAddAccessCase
3161         and InstanceOfReplaceWithJump.
3162
3163         Added the ability to log the location of a GetBy and PutBy property as either on self or up the
3164         protocol chain.
3165
3166         * jit/ICStats.cpp:
3167         (JSC::ICEvent::operator< const):
3168         (JSC::ICEvent::dump const):
3169         * jit/ICStats.h:
3170         (JSC::ICEvent::ICEvent):
3171         (JSC::ICEvent::hash const):
3172         * jit/JITOperations.cpp:
3173         * jit/Repatch.cpp:
3174         (JSC::tryCacheGetByID):
3175         (JSC::tryCachePutByID):
3176         (JSC::tryCacheInByID):
3177
3178 2019-04-11  Devin Rousso  <drousso@apple.com>
3179
3180         Web Inspector: Timelines: can't reliably stop/start a recording
3181         https://bugs.webkit.org/show_bug.cgi?id=196778
3182         <rdar://problem/47606798>
3183
3184         Reviewed by Timothy Hatcher.
3185
3186         * inspector/protocol/ScriptProfiler.json:
3187         * inspector/protocol/Timeline.json:
3188         It is possible to determine when programmatic capturing starts/stops in the frontend based
3189         on the state when the backend causes the state to change, such as if the state is "inactive"
3190         when the frontend is told that the backend has started capturing.
3191
3192         * inspector/protocol/CPUProfiler.json:
3193         * inspector/protocol/Memory.json:
3194         Send an end timestamp to match other instruments.
3195
3196         * inspector/JSGlobalObjectConsoleClient.cpp:
3197         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
3198         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
3199
3200         * inspector/agents/InspectorScriptProfilerAgent.h:
3201         * inspector/agents/InspectorScriptProfilerAgent.cpp:
3202         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
3203         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
3204         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
3205
3206 2019-04-11  Saam barati  <sbarati@apple.com>
3207
3208         Rename SetArgument to SetArgumentDefinitely
3209         https://bugs.webkit.org/show_bug.cgi?id=196828
3210
3211         Reviewed by Yusuke Suzuki.
3212
3213         This is in preparation for https://bugs.webkit.org/show_bug.cgi?id=196712
3214         where we will introduce a node named SetArgumentMaybe. Doing this refactoring
3215         first will make reviewing that other patch easier.
3216
3217         * dfg/DFGAbstractInterpreterInlines.h:
3218         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3219         * dfg/DFGByteCodeParser.cpp:
3220         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
3221         (JSC::DFG::ByteCodeParser::parseBlock):
3222         * dfg/DFGCPSRethreadingPhase.cpp:
3223         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
3224         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
3225         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
3226         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
3227         (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
3228         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
3229         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
3230         * dfg/DFGClobberize.h:
3231         (JSC::DFG::clobberize):
3232         * dfg/DFGCommon.h:
3233         * dfg/DFGDoesGC.cpp:
3234         (JSC::DFG::doesGC):
3235         * dfg/DFGFixupPhase.cpp:
3236         (JSC::DFG::FixupPhase::fixupNode):
3237         * dfg/DFGGraph.cpp:
3238         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
3239         * dfg/DFGGraph.h:
3240         * dfg/DFGInPlaceAbstractState.cpp:
3241         (JSC::DFG::InPlaceAbstractState::initialize):
3242         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
3243         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
3244         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
3245         * dfg/DFGMaximalFlushInsertionPhase.cpp:
3246         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
3247         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
3248         * dfg/DFGMayExit.cpp:
3249         * dfg/DFGNode.cpp:
3250         (JSC::DFG::Node::hasVariableAccessData):
3251         * dfg/DFGNode.h:
3252         (JSC::DFG::Node::convertPhantomToPhantomLocal):
3253         * dfg/DFGNodeType.h:
3254         * dfg/DFGOSREntrypointCreationPhase.cpp:
3255         (JSC::DFG::OSREntrypointCreationPhase::run):
3256         * dfg/DFGPhantomInsertionPhase.cpp:
3257         * dfg/DFGPredictionPropagationPhase.cpp:
3258         * dfg/DFGSSAConversionPhase.cpp:
3259         (JSC::DFG::SSAConversionPhase::run):
3260         * dfg/DFGSafeToExecute.h:
3261         (JSC::DFG::safeToExecute):
3262         * dfg/DFGSpeculativeJIT.cpp:
3263         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
3264         * dfg/DFGSpeculativeJIT32_64.cpp:
3265         (JSC::DFG::SpeculativeJIT::compile):
3266         * dfg/DFGSpeculativeJIT64.cpp:
3267         (JSC::DFG::SpeculativeJIT::compile):
3268         * dfg/DFGTypeCheckHoistingPhase.cpp:
3269         (JSC::DFG::TypeCheckHoistingPhase::run):
3270         * dfg/DFGValidate.cpp:
3271         * ftl/FTLCapabilities.cpp:
3272         (JSC::FTL::canCompile):
3273
3274 2019-04-11  Truitt Savell  <tsavell@apple.com>
3275
3276         Unreviewed, rolling out r244158.
3277
3278         Casued 8 inspector/timeline/ test failures.
3279
3280         Reverted changeset:
3281
3282         "Web Inspector: Timelines: can't reliably stop/start a
3283         recording"
3284         https://bugs.webkit.org/show_bug.cgi?id=196778
3285         https://trac.webkit.org/changeset/244158
3286
3287 2019-04-10  Saam Barati  <sbarati@apple.com>
3288
3289         AbstractValue::validateOSREntryValue is wrong for Int52 constants
3290         https://bugs.webkit.org/show_bug.cgi?id=196801
3291         <rdar://problem/49771122>
3292
3293         Reviewed by Yusuke Suzuki.
3294
3295         validateOSREntryValue should not care about the format of the incoming
3296         value for Int52s. This patch normalizes the format of m_value and
3297         the incoming value when comparing them.
3298
3299         * dfg/DFGAbstractValue.h:
3300         (JSC::DFG::AbstractValue::validateOSREntryValue const):
3301
3302 2019-04-10  Saam Barati  <sbarati@apple.com>
3303
3304         ArithSub over Int52 has shouldCheckOverflow as always true
3305         https://bugs.webkit.org/show_bug.cgi?id=196796
3306
3307         Reviewed by Yusuke Suzuki.
3308
3309         AI was checking for ArithSub over Int52 if !shouldCheckOverflow. However,
3310         shouldCheckOverflow is always true, so !shouldCheckOverflow is always
3311         false. We shouldn't check something we assert against.
3312
3313         * dfg/DFGAbstractInterpreterInlines.h:
3314         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3315
3316 2019-04-10  Basuke Suzuki  <basuke.suzuki@sony.com>
3317
3318         [PlayStation] Specify byte order clearly on Remote Inspector Protocol
3319         https://bugs.webkit.org/show_bug.cgi?id=196790
3320
3321         Reviewed by Ross Kirsling.
3322
3323         Original implementation lacks byte order specification. Network byte order is the
3324         good candidate if there's no strong reason to choose other.
3325         Currently no client exists for PlayStation remote inspector protocol, so we can
3326         change the byte order without care.
3327
3328         * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp:
3329         (Inspector::MessageParser::createMessage):
3330         (Inspector::MessageParser::parse):
3331
3332 2019-04-10  Devin Rousso  <drousso@apple.com>
3333
3334        Web Inspector: Inspector: lazily create the agent
3335        https://bugs.webkit.org/show_bug.cgi?id=195971
3336        <rdar://problem/49039645>
3337
3338        Reviewed by Joseph Pecoraro.
3339
3340        * inspector/JSGlobalObjectInspectorController.cpp:
3341        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
3342        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
3343        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
3344        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
3345
3346        * inspector/agents/InspectorAgent.h:
3347        * inspector/agents/InspectorAgent.cpp:
3348
3349 2019-04-10  Saam Barati  <sbarati@apple.com>
3350
3351         Work around an arm64_32 LLVM miscompile bug
3352         https://bugs.webkit.org/show_bug.cgi?id=196788
3353
3354         Reviewed by Yusuke Suzuki.
3355
3356         * runtime/CachedTypes.cpp:
3357
3358 2019-04-10  Devin Rousso  <drousso@apple.com>
3359
3360         Web Inspector: Timelines: can't reliably stop/start a recording
3361         https://bugs.webkit.org/show_bug.cgi?id=196778
3362         <rdar://problem/47606798>
3363
3364         Reviewed by Timothy Hatcher.
3365
3366         * inspector/protocol/ScriptProfiler.json:
3367         * inspector/protocol/Timeline.json:
3368         It is possible to determine when programmatic capturing starts/stops in the frontend based
3369         on the state when the backend causes the state to change, such as if the state is "inactive"
3370         when the frontend is told that the backend has started capturing.
3371
3372         * inspector/protocol/CPUProfiler.json:
3373         * inspector/protocol/Memory.json:
3374         Send an end timestamp to match other instruments.
3375
3376         * inspector/JSGlobalObjectConsoleClient.cpp:
3377         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
3378         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
3379
3380         * inspector/agents/InspectorScriptProfilerAgent.h:
3381         * inspector/agents/InspectorScriptProfilerAgent.cpp:
3382         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
3383         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
3384         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
3385
3386 2019-04-10  Tadeu Zagallo  <tzagallo@apple.com>
3387
3388         Unreviewed, fix watch build after r244143
3389         https://bugs.webkit.org/show_bug.cgi?id=195000
3390
3391         The result of `lseek` should be `off_t` rather than `int`.
3392
3393         * jsc.cpp:
3394
3395 2019-04-10  Tadeu Zagallo  <tzagallo@apple.com>
3396
3397         Add support for incremental bytecode cache updates
3398         https://bugs.webkit.org/show_bug.cgi?id=195000
3399
3400         Reviewed by Filip Pizlo.
3401
3402         Add support for incremental updates to the bytecode cache. The cache
3403         is constructed as follows:
3404         - When the cache is empty, the initial payload can be added to the BytecodeCache
3405         by calling BytecodeCache::addGlobalUpdate. This represents the encoded
3406         top-level UnlinkedCodeBlock.
3407         - Afterwards, updates can be added by calling BytecodeCache::addFunctionUpdate.
3408         The update is applied by appending the encoded UnlinkedFunctionCodeBlock
3409         to the existing cache and updating the CachedFunctionExecutableMetadata
3410         and the offset of the new CachedFunctionCodeBlock in the owner CachedFunctionExecutable.
3411
3412         * API/JSScript.mm:
3413         (-[JSScript readCache]):
3414         (-[JSScript isUsingBytecodeCache]):
3415         (-[JSScript init]):
3416         (-[JSScript cachedBytecode]):
3417         (-[JSScript writeCache:]):
3418         * API/JSScriptInternal.h:
3419         * API/JSScriptSourceProvider.h:
3420         * API/JSScriptSourceProvider.mm:
3421         (JSScriptSourceProvider::cachedBytecode const):
3422         * CMakeLists.txt:
3423         * JavaScriptCore.xcodeproj/project.pbxproj:
3424         * Sources.txt:
3425         * bytecode/UnlinkedFunctionExecutable.cpp:
3426         (JSC::generateUnlinkedFunctionCodeBlock):
3427         * jsc.cpp:
3428         (ShellSourceProvider::~ShellSourceProvider):
3429         (ShellSourceProvider::cachePath const):
3430         (ShellSourceProvider::loadBytecode const):
3431         (ShellSourceProvider::ShellSourceProvider):
3432         (ShellSourceProvider::cacheEnabled):
3433         * parser/SourceProvider.h:
3434         (JSC::SourceProvider::cachedBytecode const):
3435         (JSC::SourceProvider::updateCache const):
3436         (JSC::SourceProvider::commitCachedBytecode const):
3437         * runtime/CachePayload.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
3438         (JSC::CachePayload::makeMappedPayload):
3439         (JSC::CachePayload::makeMallocPayload):
3440         (JSC::CachePayload::makeEmptyPayload):
3441         (JSC::CachePayload::CachePayload):
3442         (JSC::CachePayload::~CachePayload):
3443         (JSC::CachePayload::operator=):
3444         (JSC::CachePayload::freeData):
3445         * runtime/CachePayload.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
3446         (JSC::CachePayload::data const):
3447         (JSC::CachePayload::size const):
3448         (JSC::CachePayload::CachePayload):
3449         * runtime/CacheUpdate.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
3450         (JSC::CacheUpdate::CacheUpdate):
3451         (JSC::CacheUpdate::operator=):
3452         (JSC::CacheUpdate::isGlobal const):
3453         (JSC::CacheUpdate::asGlobal const):
3454         (JSC::CacheUpdate::asFunction const):
3455         * runtime/CacheUpdate.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
3456         * runtime/CachedBytecode.cpp: Added.
3457         (JSC::CachedBytecode::addGlobalUpdate):
3458         (JSC::CachedBytecode::addFunctionUpdate):
3459         (JSC::CachedBytecode::copyLeafExecutables):
3460         (JSC::CachedBytecode::commitUpdates const):
3461         * runtime/CachedBytecode.h: Added.
3462         (JSC::CachedBytecode::create):
3463         (JSC::CachedBytecode::leafExecutables):
3464         (JSC::CachedBytecode::data const):
3465         (JSC::CachedBytecode::size const):
3466         (JSC::CachedBytecode::hasUpdates const):
3467         (JSC::CachedBytecode::sizeForUpdate const):
3468         (JSC::CachedBytecode::CachedBytecode):
3469         * runtime/CachedTypes.cpp:
3470         (JSC::Encoder::addLeafExecutable):
3471         (JSC::Encoder::release):
3472         (JSC::Decoder::Decoder):
3473         (JSC::Decoder::create):
3474         (JSC::Decoder::size const):
3475         (JSC::Decoder::offsetOf):
3476         (JSC::Decoder::ptrForOffsetFromBase):
3477         (JSC::Decoder::addLeafExecutable):
3478         (JSC::VariableLengthObject::VariableLengthObject):
3479         (JSC::VariableLengthObject::buffer const):
3480         (JSC::CachedPtrOffsets::offsetOffset):
3481         (JSC::CachedWriteBarrierOffsets::ptrOffset):
3482         (JSC::CachedFunctionExecutable::features const):
3483         (JSC::CachedFunctionExecutable::hasCapturedVariables const):
3484         (JSC::CachedFunctionExecutableOffsets::codeBlockForCallOffset):
3485         (JSC::CachedFunctionExecutableOffsets::codeBlockForConstructOffset):
3486         (JSC::CachedFunctionExecutableOffsets::metadataOffset):
3487         (JSC::CachedFunctionExecutable::encode):
3488         (JSC::CachedFunctionExecutable::decode const):
3489         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
3490         (JSC::encodeCodeBlock):
3491         (JSC::encodeFunctionCodeBlock):
3492         (JSC::decodeCodeBlockImpl):
3493         (JSC::isCachedBytecodeStillValid):
3494         * runtime/CachedTypes.h:
3495         (JSC::VariableLengthObjectBase::VariableLengthObjectBase):
3496         (JSC::decodeCodeBlock):
3497         * runtime/CodeCache.cpp:
3498         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
3499         (JSC::CodeCache::updateCache):
3500         (JSC::CodeCache::write):
3501         (JSC::writeCodeBlock):
3502         (JSC::serializeBytecode):
3503         * runtime/CodeCache.h:
3504         (JSC::SourceCodeValue::SourceCodeValue):
3505         (JSC::CodeCacheMap::findCacheAndUpdateAge):
3506         (JSC::CodeCacheMap::fetchFromDiskImpl):
3507         * runtime/Completion.cpp:
3508         (JSC::generateProgramBytecode):
3509         (JSC::generateModuleBytecode):
3510         * runtime/Completion.h:
3511         * runtime/LeafExecutable.cpp: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
3512         (JSC::LeafExecutable::operator+ const):
3513         * runtime/LeafExecutable.h: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
3514         (JSC::LeafExecutable::LeafExecutable):
3515         (JSC::LeafExecutable::base const):
3516
3517 2019-04-10  Michael Catanzaro  <mcatanzaro@igalia.com>
3518
3519         Unreviewed, rolling out r243989.
3520
3521         Broke i686 builds
3522
3523         Reverted changeset:
3524
3525         "[CMake] Detect SSE2 at compile time"
3526         https://bugs.webkit.org/show_bug.cgi?id=196488
3527         https://trac.webkit.org/changeset/243989
3528
3529 2019-04-10  Robin Morisset  <rmorisset@apple.com>
3530
3531         We should clear m_needsOverflowCheck when hitting an exception in defineProperties in ObjectConstructor.cpp
3532         https://bugs.webkit.org/show_bug.cgi?id=196746
3533
3534         Reviewed by Yusuke Suzuki..
3535
3536         It should be safe as in that case we are not completing the operation, and so not going to have any buffer overflow.
3537
3538         * runtime/ObjectConstructor.cpp:
3539         (JSC::defineProperties):
3540
3541 2019-04-10  Antoine Quint  <graouts@apple.com>
3542
3543         Enable Pointer Events on watchOS
3544         https://bugs.webkit.org/show_bug.cgi?id=196771
3545         <rdar://problem/49040909>
3546
3547         Reviewed by Dean Jackson.
3548
3549         * Configurations/FeatureDefines.xcconfig:
3550
3551 2019-04-09  Keith Rollin  <krollin@apple.com>
3552
3553         Unreviewed build maintenance -- update .xcfilelists.
3554
3555         * DerivedSources-input.xcfilelist:
3556
3557 2019-04-09  Ross Kirsling  <ross.kirsling@sony.com>
3558
3559         JSC should build successfully even with -DENABLE_UNIFIED_BUILDS=OFF
3560         https://bugs.webkit.org/show_bug.cgi?id=193073
3561
3562         Reviewed by Keith Miller.
3563
3564         * bytecompiler/BytecodeGenerator.cpp:
3565         (JSC::BytecodeGenerator::emitEqualityOpImpl):
3566         (JSC::BytecodeGenerator::emitEqualityOp): Deleted.
3567         * bytecompiler/BytecodeGenerator.h:
3568         (JSC::BytecodeGenerator::emitEqualityOp):
3569         Factor out the logic that uses the template parameter and keep it in the header.
3570
3571         * jit/JITPropertyAccess.cpp:
3572         List off the template specializations needed by JITOperations.cpp.
3573         This is unfortunate but at least there are only two (x2) by definition?
3574         Trying to do away with this incurs a severe domino effect...
3575
3576         * API/JSValueRef.cpp:
3577         * b3/B3OptimizeAssociativeExpressionTrees.cpp:
3578         * b3/air/AirHandleCalleeSaves.cpp:
3579         * builtins/BuiltinNames.cpp:
3580         * bytecode/AccessCase.cpp:
3581         * bytecode/BytecodeIntrinsicRegistry.cpp:
3582         * bytecode/BytecodeIntrinsicRegistry.h:
3583         * bytecode/BytecodeRewriter.cpp:
3584         * bytecode/BytecodeUseDef.h:
3585         * bytecode/CodeBlock.cpp:
3586         * bytecode/InstanceOfAccessCase.cpp:
3587         * bytecode/MetadataTable.cpp:
3588         * bytecode/PolyProtoAccessChain.cpp:
3589         * bytecode/StructureSet.cpp:
3590         * bytecompiler/NodesCodegen.cpp:
3591         * dfg/DFGCFAPhase.cpp:
3592         * dfg/DFGPureValue.cpp:
3593         * heap/GCSegmentedArray.h:
3594         * heap/HeapInlines.h:
3595         * heap/IsoSubspace.cpp:
3596         * heap/LocalAllocator.cpp:
3597         * heap/LocalAllocator.h:
3598         * heap/LocalAllocatorInlines.h:
3599         * heap/MarkingConstraintSolver.cpp:
3600         * inspector/ScriptArguments.cpp:
3601         (Inspector::ScriptArguments::isEqual const):
3602         * inspector/ScriptCallStackFactory.cpp:
3603         * interpreter/CallFrame.h:
3604         * interpreter/Interpreter.cpp:
3605         * interpreter/StackVisitor.cpp:
3606         * llint/LLIntEntrypoint.cpp:
3607         * runtime/ArrayIteratorPrototype.cpp:
3608         * runtime/BigIntPrototype.cpp:
3609         * runtime/CachedTypes.cpp:
3610         * runtime/ErrorType.cpp:
3611         * runtime/IndexingType.cpp:
3612         * runtime/JSCellInlines.h:
3613         * runtime/JSImmutableButterfly.h:
3614         * runtime/Operations.h:
3615         * runtime/RegExpCachedResult.cpp:
3616         * runtime/RegExpConstructor.cpp:
3617         * runtime/RegExpGlobalData.cpp:
3618         * runtime/StackFrame.h:
3619         * wasm/WasmSignature.cpp:
3620         * wasm/js/JSToWasm.cpp:
3621         * wasm/js/JSToWasmICCallee.cpp:
3622         * wasm/js/WebAssemblyFunction.h:
3623         Fix includes / forward declarations (and a couple of nearby clang warnings).
3624
3625 2019-04-09  Don Olmstead  <don.olmstead@sony.com>
3626
3627         [CMake] Apple builds should use ICU_INCLUDE_DIRS
3628         https://bugs.webkit.org/show_bug.cgi?id=196720
3629
3630         Reviewed by Konstantin Tokarev.
3631
3632         * PlatformMac.cmake:
3633
3634 2019-04-09  Saam barati  <sbarati@apple.com>
3635
3636         Clean up Int52 code and some bugs in it
3637         https://bugs.webkit.org/show_bug.cgi?id=196639
3638         <rdar://problem/49515757>
3639
3640         Reviewed by Yusuke Suzuki.
3641
3642         This patch fixes bugs in our Int52 code. The primary change in this patch is
3643         adopting a segregated type lattice for Int52. Previously, for Int52 values,
3644         we represented them with SpecInt32Only and SpecInt52Only. For an Int52,
3645         SpecInt32Only meant that the value is in int32 range. And SpecInt52Only meant
3646         that the is outside of the int32 range.
3647         
3648         However, this got confusing because we reused SpecInt32Only both for JSValue
3649         representations and Int52 representations. This actually lead to some bugs.
3650         
3651         1. It's possible that roundtripping through Int52 representation would say
3652         it produces the wrong type. For example, consider this program and how we
3653         used to annotate types in AI:
3654         a: JSConstant(10.0) => m_type is SpecAnyIntAsDouble
3655         b: Int52Rep(@a) => m_type is SpecInt52Only
3656         c: ValueRep(@b) => m_type is SpecAnyIntAsDouble
3657         
3658         In AI, for the above program, we'd say that @c produces SpecAnyIntAsDouble.
3659         However, the execution semantics are such that it'd actually produce a boxed
3660         Int32. This patch fixes the bug where we'd say that Int52Rep over SpecAnyIntAsDouble
3661         would produce SpecInt52Only. This is clearly wrong, as SpecAnyIntAsDouble can
3662         mean an int value in either int32 or int52 range.
3663         
3664         2. AsbstractValue::validateTypeAcceptingBoxedInt52 was wrong in how it
3665         accepted Int52 values. It was wrong in two different ways:
3666         a: If the AbstractValue's type was SpecInt52Only, and the incoming value
3667         was a boxed double, but represented a value in int32 range, the incoming
3668         value would incorrectly validate as being acceptable. However, we should
3669         have rejected this value.
3670         b: If the AbstractValue's type was SpecInt32Only, and the incoming value
3671         was an Int32 boxed in a double, this would not validate, even though
3672         it should have validated.
3673         
3674         Solving 2 was easiest if we segregated out the Int52 type into its own
3675         lattice. This patch makes a new Int52 lattice, which is composed of
3676         SpecInt32AsInt52 and SpecNonInt32AsInt52.
3677         
3678         The conversion rules are now really simple.
3679         
3680         Int52 rep => JSValue rep
3681         SpecInt32AsInt52 => SpecInt32Only
3682         SpecNonInt32AsInt52 => SpecAnyIntAsDouble
3683         
3684         JSValue rep => Int52 rep
3685         SpecInt32Only => SpecInt32AsInt52
3686         SpecAnyIntAsDouble => SpecInt52Any
3687         
3688         With these rules, the program in (1) will now correctly report that @c
3689         returns SpecInt32Only | SpecAnyIntAsDouble.
3690
3691         * bytecode/SpeculatedType.cpp:
3692         (JSC::dumpSpeculation):
3693         (JSC::speculationToAbbreviatedString):
3694         (JSC::int52AwareSpeculationFromValue):
3695         (JSC::leastUpperBoundOfStrictlyEquivalentSpeculations):
3696         (JSC::speculationFromString):
3697         * bytecode/SpeculatedType.h:
3698         (JSC::isInt32SpeculationForArithmetic):
3699         (JSC::isInt32OrBooleanSpeculationForArithmetic):
3700         (JSC::isAnyInt52Speculation):
3701         (JSC::isIntAnyFormat):
3702         (JSC::isInt52Speculation): Deleted.
3703         (JSC::isAnyIntSpeculation): Deleted.
3704         * dfg/DFGAbstractInterpreterInlines.h:
3705         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3706         * dfg/DFGAbstractValue.cpp:
3707         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
3708         (JSC::DFG::AbstractValue::checkConsistency const):
3709         * dfg/DFGAbstractValue.h:
3710         (JSC::DFG::AbstractValue::isInt52Any const):
3711         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
3712         * dfg/DFGFixupPhase.cpp:
3713         (JSC::DFG::FixupPhase::fixupArithMul):
3714         (JSC::DFG::FixupPhase::fixupNode):
3715         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
3716         (JSC::DFG::FixupPhase::fixupToThis):
3717         (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
3718         (JSC::DFG::FixupPhase::observeUseKindOnNode):
3719         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
3720         (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
3721         (JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
3722         (JSC::DFG::FixupPhase::fixupChecksInBlock):
3723         * dfg/DFGGraph.h:
3724         (JSC::DFG::Graph::addShouldSpeculateInt52):
3725         (JSC::DFG::Graph::binaryArithShouldSpeculateInt52):
3726         (JSC::DFG::Graph::unaryArithShouldSpeculateInt52):
3727         (JSC::DFG::Graph::addShouldSpeculateAnyInt): Deleted.
3728         (JSC::DFG::Graph::binaryArithShouldSpeculateAnyInt): Deleted.
3729         (JSC::DFG::Graph::unaryArithShouldSpeculateAnyInt): Deleted.
3730         * dfg/DFGNode.h:
3731         (JSC::DFG::Node::shouldSpeculateInt52):
3732         (JSC::DFG::Node::shouldSpeculateAnyInt): Deleted.
3733         * dfg/DFGPredictionPropagationPhase.cpp:
3734         * dfg/DFGSpeculativeJIT.cpp:
3735         (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
3736         (JSC::DFG::SpeculativeJIT::compileArithAdd):
3737         (JSC::DFG::SpeculativeJIT::compileArithSub):
3738         (JSC::DFG::SpeculativeJIT::compileArithNegate):
3739         * dfg/DFGSpeculativeJIT64.cpp:
3740         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
3741         (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
3742         * dfg/DFGUseKind.h:
3743         (JSC::DFG::typeFilterFor):
3744         * dfg/DFGVariableAccessData.cpp:
3745         (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat):
3746         (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
3747         * ftl/FTLLowerDFGToB3.cpp:
3748         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
3749         (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
3750         (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
3751
3752 2019-04-09  Tadeu Zagallo  <tzagallo@apple.com>
3753
3754         ASSERTION FAILED: !scope.exception() || !hasProperty in JSObject::get
3755         https://bugs.webkit.org/show_bug.cgi?id=196708
3756         <rdar://problem/49556803>
3757
3758         Reviewed by Yusuke Suzuki.
3759
3760         `operationPutToScope` needs to return early if an exception is thrown while
3761         checking if `hasProperty`.
3762
3763         * jit/JITOperations.cpp:
3764
3765 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
3766
3767         [JSC] DFG should respect node's strict flag
3768         https://bugs.webkit.org/show_bug.cgi?id=196617
3769
3770         Reviewed by Saam Barati.
3771
3772         We accidentally use codeBlock->isStrictMode() directly in DFG and FTL. But this is wrong since this CodeBlock is the top level DFG/FTL CodeBlock,
3773         and this code does not respect the isStrictMode flag for the inlined CodeBlocks. In this patch, we start using isStrictModeFor(CodeOrigin) consistently
3774         in DFG and FTL to get the right isStrictMode flag for the DFG node.
3775         And we also split compilePutDynamicVar into compilePutDynamicVarStrict and compilePutDynamicVarNonStrict since (1) it is cleaner than accessing inlined
3776         callframe in the operation function, and (2) it is aligned to the other functions like operationPutByValDirectNonStrict etc.
3777         This bug is discovered by RandomizingFuzzerAgent by expanding the DFG coverage.
3778
3779         * dfg/DFGAbstractInterpreterInlines.h:
3780         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3781         * dfg/DFGConstantFoldingPhase.cpp:
3782         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3783         * dfg/DFGFixupPhase.cpp:
3784         (JSC::DFG::FixupPhase::fixupToThis):
3785         * dfg/DFGOperations.cpp:
3786         * dfg/DFGOperations.h:
3787         * dfg/DFGPredictionPropagationPhase.cpp:
3788         * dfg/DFGSpeculativeJIT.cpp:
3789         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
3790         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
3791         (JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
3792         (JSC::DFG::SpeculativeJIT::compileToThis):
3793         * dfg/DFGSpeculativeJIT32_64.cpp:
3794         (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
3795         (JSC::DFG::SpeculativeJIT::compile):
3796         * dfg/DFGSpeculativeJIT64.cpp:
3797         (JSC::DFG::SpeculativeJIT::compile):
3798         * ftl/FTLLowerDFGToB3.cpp:
3799         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
3800         (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
3801
3802 2019-04-08  Don Olmstead  <don.olmstead@sony.com>
3803
3804         [CMake][WinCairo] Separate copied headers into different directories
3805         https://bugs.webkit.org/show_bug.cgi?id=196655
3806
3807         Reviewed by Michael Catanzaro.
3808
3809         * CMakeLists.txt:
3810         * shell/PlatformWin.cmake:
3811
3812 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
3813
3814         [JSC] isRope jump in StringSlice should not jump over register allocations
3815         https://bugs.webkit.org/show_bug.cgi?id=196716
3816
3817         Reviewed by Saam Barati.
3818
3819         Jumping over the register allocation code in DFG (like the following) is wrong.
3820
3821             auto jump = m_jit.branchXXX();
3822             {
3823                 GPRTemporary reg(this);
3824                 GPRReg regGPR = reg.gpr();
3825                 ...
3826             }
3827             jump.link(&m_jit);
3828
3829         When GPRTemporary::gpr allocates a new register, it can flush the previous register value into the stack and make the register usable.
3830         Jumping over this register allocation code skips the flushing code, and makes the DFG's stack and register content tracking inconsistent:
3831         DFG thinks that the content is flushed and stored in particular stack slot even while this flushing code is skipped.
3832         In this patch, we perform register allocations before jumping to the slow path based on `isRope` condition in StringSlice.
3833
3834         * dfg/DFGSpeculativeJIT.cpp:
3835         (JSC::DFG::SpeculativeJIT::compileStringSlice):
3836
3837 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
3838
3839         [JSC] to_index_string should not assume incoming value is Uint32
3840         https://bugs.webkit.org/show_bug.cgi?id=196713
3841
3842         Reviewed by Saam Barati.
3843
3844         The slow path of to_index_string assumes that incoming value is Uint32. But we should not have
3845         this assumption since DFG may decide we should have it double format. This patch removes this
3846         assumption, and instead, we should assume that incoming value is AnyInt and the range of this
3847         is within Uint32.
3848
3849         * runtime/CommonSlowPaths.cpp:
3850         (JSC::SLOW_PATH_DECL):
3851
3852 2019-04-08  Justin Fan  <justin_fan@apple.com>
3853