[Mac] Allow customizing H264 encoder
[WebKit.git] / Source / JavaScriptCore / ChangeLog
1 2017-04-19  Youenn Fablet  <youenn@apple.com>
2
3         [Mac] Allow customizing H264 encoder
4         https://bugs.webkit.org/show_bug.cgi?id=170829
5
6         Reviewed by Alex Christensen.
7
8         * Configurations/FeatureDefines.xcconfig:
9
10 2017-04-19  Michael Saboff  <msaboff@apple.com>
11
12         Tune GC related JSC options for iOS
13         https://bugs.webkit.org/show_bug.cgi?id=171019
14
15         Reviewed by Mark Lam.
16
17         Always set these GC options on iOS.
18
19         * runtime/Options.cpp:
20         (JSC::overrideDefaults):
21
22 2017-04-19  JF Bastien  <jfbastien@apple.com>
23
24         WebAssembly: fast memory cleanups
25         https://bugs.webkit.org/show_bug.cgi?id=170909
26
27         Reviewed by Saam Barati.
28
29         * b3/B3LowerToAir.cpp: correct comment, and make wasm-independent
30         (JSC::B3::Air::LowerToAir::lower):
31         * b3/B3Procedure.h:
32         * b3/B3Validate.cpp:
33         * b3/B3Value.cpp:
34         (JSC::B3::Value::effects):
35         * b3/B3WasmBoundsCheckValue.cpp: have the creator pass in a
36         maximum, so we don't have to know so much about wasm here
37         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
38         (JSC::B3::WasmBoundsCheckValue::cloneImpl):
39         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
40         * b3/B3WasmBoundsCheckValue.h:
41         (JSC::B3::WasmBoundsCheckValue::boundsType):
42         (JSC::B3::WasmBoundsCheckValue::bounds):
43         * b3/air/AirCode.h:
44         * b3/air/AirCustom.h:
45         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
46         * b3/testb3.cpp:
47         (JSC::B3::testWasmBoundsCheck):
48         * wasm/WasmB3IRGenerator.cpp:
49         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
50         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
51         (JSC::Wasm::createJSToWasmWrapper): remove dead code
52         * wasm/WasmMemory.cpp: don't GC if no memory could possibly be free'd
53         (JSC::Wasm::Memory::initializePreallocations): verbose-only code,
54         and copy-pasta bug
55
56 2017-04-19  Mark Lam  <mark.lam@apple.com>
57
58         B3StackmapSpecial should handle when stackmap values are not recoverable from a Def'ed arg.
59         https://bugs.webkit.org/show_bug.cgi?id=170973
60         <rdar://problem/30318657>
61
62         Reviewed by Filip Pizlo.
63
64         In the event of an arithmetic overflow on a binary sub instruction (where the
65         result register is same as one of the operand registers), the CheckSub FTL
66         operation will try to recover the original value in the clobbered result register.
67
68         This recover is done by adding the other operand value to the result register.
69         However, this recovery method only works if the width of the original value in
70         the result register is less or equal to the width of the expected result.  If the
71         width of the original operand value (e.g. a JSInt32) is wider than the result
72         (e.g. a machine Int32), then the sub operation would have zero extended the
73         result and cleared the upper 32-bits of the result register.  Recovery by adding
74         back the other operand will not restore the JSValue tag in the upper word.
75
76         This poses a problem if the stackmap value for the operand relies on that same
77         clobbered register.
78
79         The fix is to detect this potential scenario (i.e. width of the Def's arg < width
80         of a stackmap value).  If this condition is detected, we'll declare the stackmap
81         value to be LateColdUse to ensure that the register allocator gives it a
82         different register if needed so that it's not dependent on the clobbered register.
83
84         * b3/B3CheckSpecial.cpp:
85         (JSC::B3::CheckSpecial::forEachArg):
86         * b3/B3PatchpointSpecial.cpp:
87         (JSC::B3::PatchpointSpecial::forEachArg):
88         * b3/B3StackmapSpecial.cpp:
89         (JSC::B3::StackmapSpecial::forEachArgImpl):
90         * b3/B3StackmapSpecial.h:
91
92 2017-04-19  JF Bastien  <jfbastien@apple.com>
93
94         Unreviewed, rolling out r215520.
95
96         Broke Debian 8
97
98         Reverted changeset:
99
100         "[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts"
101         https://bugs.webkit.org/show_bug.cgi?id=169458
102         http://trac.webkit.org/changeset/215520
103
104 2017-04-19  JF Bastien  <jfbastien@apple.com>
105
106         WebAssembly: limit slow memories
107         https://bugs.webkit.org/show_bug.cgi?id=170825
108
109         Reviewed by Saam Barati.
110
111         We limits the number of fast memories, partly because ASLR. The
112         code then falls back to slow memories. It first tries to virtually
113         allocated any declared maximum (and in there, physically the
114         initial), and if that fails it tries to physically allocate the
115         initial without any extra.
116
117         This can still be used to cause a bunch of virtual
118         allocation. This patch imposes soft limit on slow memories as
119         well. The total virtual maximum for slow memories is set at the
120         same (theoretical) value as that for fast memories.
121
122         Anything exceeding that limit causes allocation/grow to fail.
123
124         * wasm/WasmMemory.cpp:
125
126 2017-04-19  JF Bastien  <jfbastien@apple.com>
127
128         Cannot compile JavaScriptCore/runtime/VMTraps.cpp on FreeBSD because std::pair has a non-trivial copy constructor
129         https://bugs.webkit.org/show_bug.cgi?id=170875
130
131         Reviewed by Mark Lam.
132
133         WTF::ExpectedDetail::ConstexprBase doesn't have a user-defined
134         copy constructor, and its implicitly-defined copy constructor is
135         deleted because the default std::pair implementation on FreeBSD
136         has a non-trivial copy constructor. /usr/include/c++/v1/__config
137         says _LIBCPP_TRIVIAL_PAIR_COPY_CTOR is disabled in order to keep
138         ABI compatibility:
139         https://svnweb.freebsd.org/changeset/base/261801.
140
141         That's a huge bummer, and I'm not a fan of broken stdlibs, but in
142         this case it's pretty nice to have a custom named type anyways and
143         costs nothing.
144
145         * runtime/VMTraps.cpp:
146         (JSC::findActiveVMAndStackBounds):
147         (JSC::handleSigusr1):
148         (JSC::handleSigtrap):
149
150 2017-04-19  Andy VanWagoner  <thetalecrafter@gmail.com>
151
152         [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
153         https://bugs.webkit.org/show_bug.cgi?id=169458
154
155         Reviewed by JF Bastien.
156
157         Use udat_formatForFields to iterate through the parts of a formatted date string.
158
159         * icu/unicode/udat.h: Update to 55.1.
160         * icu/unicode/ufieldpositer.h: Added from 55.1.
161         * runtime/IntlDateTimeFormat.cpp:
162         (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
163         (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
164         * runtime/IntlDateTimeFormat.h:
165         * runtime/IntlDateTimeFormatPrototype.cpp:
166         (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
167
168 2017-04-19  JF Bastien  <jfbastien@apple.com>
169
170         WebAssembly: don't expose any WebAssembly JS object if JIT is off
171         https://bugs.webkit.org/show_bug.cgi?id=170782
172
173         Reviewed by Saam Barati.
174
175         It's unexpected that we expose the global WebAssembly object if no
176         JIT is present because it can't be used to compile or
177         instantiate. Other APIs such as Memory should also be Inaccessible
178         in those circumstances.
179
180         Also ensure that we don't pre-allocate fast memories if
181         WebAssembly won't be used, and don't mark our intention to use a
182         fast TLS slot for WebAssembly.
183
184         * runtime/Options.cpp:
185         (JSC::recomputeDependentOptions):
186
187 2017-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
188
189         r211670 broke double to int conversion.
190         https://bugs.webkit.org/show_bug.cgi?id=170961
191
192         Reviewed by Mark Lam.
193
194         In this patch, we take a template parameter way.
195         While it reduces duplicate code, it effectively produces
196         optimized code for operationToInt32SensibleSlow,
197         and fixes kraken pbkdf2 regression on Linux.
198
199         And this patch also fixes undefined behavior by changing
200         int32_t to uint32_t. If exp is 31, missingOne is 1 << 31,
201         INT32_MIN. Thus missingOne - 1 will cause int32_t overflow,
202         and it is an undefined behavior.
203
204         * runtime/MathCommon.cpp:
205         (JSC::operationToInt32SensibleSlow):
206         * runtime/MathCommon.h:
207         (JSC::toInt32Internal):
208         (JSC::toInt32):
209
210 2017-04-18  Mark Lam  <mark.lam@apple.com>
211
212         r211670 broke double to int conversion.
213         https://bugs.webkit.org/show_bug.cgi?id=170961
214         <rdar://problem/31687696>
215
216         Reviewed by Yusuke Suzuki.
217
218         This is because operationToInt32SensibleSlow() assumes that left shifts of greater
219         than 31 bits on an 31-bit value will produce a 0.  However, the spec says that
220         "if the value of the right operand is negative or is greater or equal to the
221         number of bits in the promoted left operand, the behavior is undefined."
222         See http://en.cppreference.com/w/cpp/language/operator_arithmetic#Bitwise_shift_operators.
223
224         This patch fixes this by restoring the check to prevent a shift of greater than
225         31 bits.  It also consolidates the optimization in operationToInt32SensibleSlow()
226         back into toInt32() so that we don't have 2 copies of the same code with only a
227         slight variation.
228
229         JSC benchmarks shows that performance is neutral with this patch.
230
231         * dfg/DFGSpeculativeJIT.cpp:
232         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
233         * ftl/FTLLowerDFGToB3.cpp:
234         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
235         * runtime/MathCommon.cpp:
236         (JSC::operationToInt32SensibleSlow): Deleted.
237         * runtime/MathCommon.h:
238         (JSC::toInt32):
239
240 2017-04-18  Oleksandr Skachkov  <gskachkov@gmail.com>
241
242         [ES6]. Implement Annex B.3.3 function hoisting rules for eval
243         https://bugs.webkit.org/show_bug.cgi?id=163208
244
245         Reviewed by Saam Barati.
246
247         Current patch implements Annex B.3.3 that is related to 
248         hoisting of function declaration in eval. 
249         https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
250         Function declaration in eval should create variable with 
251         function name in function scope where eval is invoked 
252         or bind to variable if it declared outside of the eval. 
253         If variable is created it can be removed by 'delete a;' command. 
254         If eval is invoke in block scope that contains let/const 
255         variable with the same name as function declaration 
256         we do not bind. This patch leads to the following behavior: 
257         '''
258         function foo() {
259            {
260              print(boo); // undefined
261              eval('{ function boo() {}}');
262              print(boo); // function boo() {}
263            }
264            print(boo); // function boo() {}
265         }
266
267         function foobar() {
268           { 
269             let boo = 10;
270             print(boo); // 10;
271             eval('{ function boo() {}}');
272             print(boo); // 10;
273           }
274           print(boo) // 10
275         }
276
277         function bar() {
278            {
279               var boo = 10;
280               print(boo); // 10
281               eval('{ function boo() {} }'); 
282               print(boo); // function boo() {}
283            }
284            print(boo); // function boo() {}
285         }       
286         
287         function bas() {
288             {
289                  let boo = 10;
290                  eval(' { function boo() {} } ');
291                  print(boo); // 10
292             }
293             print(boo); //Reference Error
294         }
295         '''
296
297         Current implementation relies on already implemented 
298         'hoist function in sloppy mode' feature, with small changes.
299         In short it works in following way: during hoisting of function 
300         with name S in eval, we are looking for first scope that 
301         contains space for variable with name S and if this scope 
302         has var type we bind function there
303
304         To implement this feature was added bytecode ops:
305         op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
306         or return undefined if variable can't be binded there.
307
308         There is a corner case, hoist function in eval within catch block,
309         that is not covered by this patch, and will be fixed in 
310         https://bugs.webkit.org/show_bug.cgi?id=168184
311
312         * bytecode/BytecodeDumper.cpp:
313         (JSC::BytecodeDumper<Block>::dumpBytecode):
314         * bytecode/BytecodeList.json:
315         * bytecode/BytecodeUseDef.h:
316         (JSC::computeUsesForBytecodeOffset):
317         (JSC::computeDefsForBytecodeOffset):
318         * bytecode/CodeBlock.cpp:
319         (JSC::CodeBlock::finalizeLLIntInlineCaches):
320         * bytecode/EvalCodeBlock.h:
321         (JSC::EvalCodeBlock::functionHoistingCandidate):
322         (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
323         * bytecode/UnlinkedEvalCodeBlock.h:
324         * bytecompiler/BytecodeGenerator.cpp:
325         (JSC::BytecodeGenerator::BytecodeGenerator):
326         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
327         (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
328         * bytecompiler/BytecodeGenerator.h:
329         * dfg/DFGAbstractInterpreterInlines.h:
330         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
331         * dfg/DFGByteCodeParser.cpp:
332         (JSC::DFG::ByteCodeParser::parseBlock):
333         * dfg/DFGCapabilities.cpp:
334         (JSC::DFG::capabilityLevel):
335         * dfg/DFGClobberize.h:
336         (JSC::DFG::clobberize):
337         * dfg/DFGDoesGC.cpp:
338         (JSC::DFG::doesGC):
339         * dfg/DFGFixupPhase.cpp:
340         (JSC::DFG::FixupPhase::fixupNode):
341         * dfg/DFGNode.h:
342         (JSC::DFG::Node::hasIdentifier):
343         * dfg/DFGNodeType.h:
344         * dfg/DFGOperations.cpp:
345         * dfg/DFGOperations.h:
346         * dfg/DFGPredictionPropagationPhase.cpp:
347         * dfg/DFGSafeToExecute.h:
348         (JSC::DFG::safeToExecute):
349         * dfg/DFGSpeculativeJIT.cpp:
350         (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
351         * dfg/DFGSpeculativeJIT.h:
352         (JSC::DFG::SpeculativeJIT::callOperation):
353         * dfg/DFGSpeculativeJIT32_64.cpp:
354         (JSC::DFG::SpeculativeJIT::compile):
355         * dfg/DFGSpeculativeJIT64.cpp:
356         (JSC::DFG::SpeculativeJIT::compile):
357         * ftl/FTLCapabilities.cpp:
358         (JSC::FTL::canCompile):
359         * ftl/FTLLowerDFGToB3.cpp:
360         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
361         (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
362         * interpreter/Interpreter.cpp:
363         (JSC::Interpreter::execute):
364         * jit/JIT.cpp:
365         (JSC::JIT::privateCompileMainPass):
366         * jit/JIT.h:
367         * jit/JITOperations.h:
368         * jit/JITPropertyAccess.cpp:
369         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
370         * jit/JITPropertyAccess32_64.cpp:
371         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
372         * llint/LowLevelInterpreter.asm:
373         * parser/Parser.cpp:
374         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
375         * parser/Parser.h:
376         (JSC::Scope::getSloppyModeHoistedFunctions):
377         (JSC::Parser::declareFunction):
378         * runtime/CommonSlowPaths.cpp:
379         (JSC::SLOW_PATH_DECL):
380         * runtime/CommonSlowPaths.h:
381         * runtime/EvalExecutable.h:
382         (JSC::EvalExecutable::numFunctionHoistingCandidates):
383         (JSC::EvalExecutable::numTopLevelFunctionDecls):
384         (JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
385         * runtime/JSScope.cpp:
386         (JSC::JSScope::resolve):
387         (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
388         * runtime/JSScope.h:
389
390 2017-04-18  Saam Barati  <sbarati@apple.com>
391
392         Follow up to address Mark's comments after r215453
393
394         Rubber stamped by Mark Lam.
395
396         This patch chooses better names for things, adhering to Mark's suggestions
397         in https://bugs.webkit.org/show_bug.cgi?id=139847
398
399         * bytecompiler/NodesCodegen.cpp:
400         (JSC::CallFunctionCallDotNode::emitBytecode):
401         (JSC::ApplyFunctionCallDotNode::emitBytecode):
402         * parser/NodeConstructors.h:
403         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
404         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
405         * parser/Nodes.h:
406         * parser/Parser.cpp:
407         (JSC::recordCallOrApplyDepth):
408         (JSC::Parser<LexerType>::parseMemberExpression):
409         * parser/Parser.h:
410         (JSC::Parser::CallOrApplyDepthScope::CallOrApplyDepthScope):
411         (JSC::Parser::CallOrApplyDepthScope::distanceToInnermostChild):
412         (JSC::Parser::CallOrApplyDepthScope::~CallOrApplyDepthScope):
413         (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth): Deleted.
414         (JSC::Parser::CallOrApplyDepth::maxChildDepth): Deleted.
415         (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth): Deleted.
416
417 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
418
419         [DFG] Convert ValueAdd(Int32, String) => MakeRope(ToString(Int32), String)
420         https://bugs.webkit.org/show_bug.cgi?id=170943
421
422         Reviewed by Geoffrey Garen.
423
424         This patch converts ValueAdd(Int32, String) to MakeRope(ToString(Int32), String).
425         This has 2 great features.
426
427         1. MakeRope(ToString(Int32), String) is less clobbering.
428
429         While ValueAdd ends up calling functions, VM knows much about MakeRope(ToString(Int32), String)
430         and VM knows it is less clobbering. It encourages LICM and other operations that is conservatively
431         executed because of ValueAdd's clobbering.
432
433         2. Simply, MakeRope(ToString(Int32), String) is faster than ValueAdd.
434
435         While ValueAdd ends up calling a generic function, our ToString(Int32) calls well-optimized toString
436         operation. And later, MakeRope can fall into the fast path that just takes a string from a free list.
437         It is simply faster than ValueAdd.
438
439         We ensure that this patch shows performance improvement in attached benchmarks.
440
441                                                         baseline                  patched
442
443             number-to-string-with-add-empty         16.2763+-3.3930     ^     10.3142+-1.0967        ^ definitely 1.5780x faster
444             number-to-string-with-add-in-loop      168.7621+-10.9738    ^     15.5307+-3.3179        ^ definitely 10.8664x faster
445             number-to-string-with-add               18.8557+-4.8292           11.6901+-2.5650          might be 1.6130x faster
446
447         In SixSpeed,
448
449                                                baseline                  patched
450
451             template_string_tag.es5       200.1027+-20.6871    ^     25.7925+-11.4052       ^ definitely 7.7582x faster
452             template_string_tag.es6       331.3913+-12.1750    ^    286.6958+-26.0441       ^ definitely 1.1559x faster
453             for-of-array.es5              412.4344+-23.2517    ^    272.8707+-47.2118       ^ definitely 1.5115x faster
454             for-of-array.es6              504.0082+-65.5045    ^    300.3277+-12.8193       ^ definitely 1.6782x faster
455
456         * dfg/DFGFixupPhase.cpp:
457         (JSC::DFG::FixupPhase::fixupNode):
458         (JSC::DFG::FixupPhase::createToString):
459         * dfg/DFGPredictionPropagationPhase.cpp:
460
461 2017-04-18  Michael Saboff  <msaboff@apple.com>
462
463         REGRESSION(215272): microbenchmark/seal-and-do-work and microbenchmark/freeze-and-do-work are 27x slower
464         https://bugs.webkit.org/show_bug.cgi?id=170881
465
466         Reviewed by Saam Barati.
467
468         * runtime/ObjectConstructor.cpp:
469         (JSC::objectConstructorSeal):
470         (JSC::objectConstructorFreeze):
471         Restored fast paths for final objects that don't have indexed properties.
472
473 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
474
475         [DFG] Use Phantom for base instead of getter when inlining intrinsic getter
476         https://bugs.webkit.org/show_bug.cgi?id=170947
477
478         Reviewed by Saam Barati.
479
480         getter does not need to be live after OSR Exit.
481
482         * dfg/DFGByteCodeParser.cpp:
483         (JSC::DFG::ByteCodeParser::handleGetById):
484
485 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
486
487         Unreviewed, follow-up patch after r215459
488         https://bugs.webkit.org/show_bug.cgi?id=170940
489
490         Reviewed by Filip Pizlo.
491
492         CheckCell can cause OSRExit. Thus Phantom should be placed after CheckCell.
493
494         * dfg/DFGByteCodeParser.cpp:
495         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
496         (JSC::DFG::ByteCodeParser::handleGetById):
497
498 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
499
500         [DFG] Drop unknown use of CheckCell's child2 to work ObjectAllocationSinking for Array iterator object
501         https://bugs.webkit.org/show_bug.cgi?id=170940
502
503         Reviewed by Filip Pizlo.
504
505         The second argument of CheckCell is not used in meaningful way. It is just *use* the node.
506         The problem is that it effectively *use* the child2 in ObjectAllocationSinking phase, and
507         prevent us from eliminating object allocations. Actually, it materializes Array iterator
508         when inlining `next()`. Instead, we should use Phantom in such a case.
509
510         It improves destructuring.es6 in SixSpeed 2.5x.
511
512         destructuring.es6      308.5184+-25.3490    ^    119.5680+-15.0520       ^ definitely 2.5803x faster
513
514         Note that SixSpeed tested in arewefastyet executes all the tests in one process while our SixSpeed
515         tests each one in isolated way.
516
517         * dfg/DFGByteCodeParser.cpp:
518         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
519         (JSC::DFG::ByteCodeParser::handleGetById):
520
521 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
522
523         [JSC][GTK] glib RunLoop does not accept negative start interval
524         https://bugs.webkit.org/show_bug.cgi?id=170775
525
526         Reviewed by Saam Barati.
527
528         * heap/GCActivityCallback.cpp:
529         (JSC::GCActivityCallback::scheduleTimer):
530
531 2017-04-17  Saam Barati  <sbarati@apple.com>
532
533         BytecodeGenerator ".call" and ".apply" is exponential in nesting depth
534         https://bugs.webkit.org/show_bug.cgi?id=139847
535         <rdar://problem/19321122>
536
537         Reviewed by Oliver Hunt.
538
539         The BytecodeGenerator's .apply(...) and .call(...) code would
540         emit bytecode for the evaluation of its arguments twice. This
541         is exponential, specifically, 2^n, where n is the nesting depth of
542         .call(...) or .apply(...) inside other .call(...) or .apply(...).
543         
544         The reason we emit code for the arguments twice is that we try
545         to emit efficient code for when .call or .apply is Function.prototype.call
546         or Function.prototype.apply. Because of this, we compare .call/.apply to
547         Function.prototype.call/.apply, and if they're the same, we emit a specialized
548         function call in bytecode. Otherwise, we emit the generalized version.
549         
550         This patch makes it so that each .call(...) and .apply(...) records
551         its max inner nesting depth. Then, we only perform the optimization
552         for the bottom k (where k = 6) layers of the nesting tree. The reason we
553         apply the optimization to the bottom k layers instead of top k layers
554         is that we'll produce less code this way.
555
556         * bytecompiler/NodesCodegen.cpp:
557         (JSC::CallFunctionCallDotNode::emitBytecode):
558         (JSC::ApplyFunctionCallDotNode::emitBytecode):
559         * parser/ASTBuilder.h:
560         (JSC::ASTBuilder::makeFunctionCallNode):
561         * parser/NodeConstructors.h:
562         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
563         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
564         * parser/Nodes.h:
565         * parser/Parser.cpp:
566         (JSC::recordCallOrApplyDepth):
567         (JSC::Parser<LexerType>::parseMemberExpression):
568         * parser/Parser.h:
569         (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth):
570         (JSC::Parser::CallOrApplyDepth::maxChildDepth):
571         (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth):
572         * parser/SyntaxChecker.h:
573         (JSC::SyntaxChecker::makeFunctionCallNode):
574
575 2017-04-17  Mark Lam  <mark.lam@apple.com>
576
577         JSArray::appendMemcpy() needs to handle copying from Undecided indexing type too.
578         https://bugs.webkit.org/show_bug.cgi?id=170896
579         <rdar://problem/31651319>
580
581         Reviewed by JF Bastien and Keith Miller.
582
583         * runtime/JSArray.cpp:
584         (JSC::JSArray::appendMemcpy):
585
586 2017-04-17  Joseph Pecoraro  <pecoraro@apple.com>
587
588         Web Inspector: Doesn't show size of compressed content correctly
589         https://bugs.webkit.org/show_bug.cgi?id=155112
590         <rdar://problem/25006728>
591
592         Reviewed by Alex Christensen and Timothy Hatcher.
593
594         * inspector/protocol/Network.json:
595         New, exact size metrics, available after the load completes.
596
597 2017-04-17  Youenn Fablet  <youenn@apple.com>
598
599         Disable outdated WritableStream API
600         https://bugs.webkit.org/show_bug.cgi?id=170749
601         <rdar://problem/31446233>
602
603         Reviewed by Alex Christensen.
604
605         * Configurations/FeatureDefines.xcconfig:
606
607 2017-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
608
609         [JSCOnly] Fix build failures in macOS
610         https://bugs.webkit.org/show_bug.cgi?id=170887
611
612         Reviewed by Alex Christensen.
613
614         Align ICU header configuration to MacCMake port.
615
616         * PlatformJSCOnly.cmake:
617
618 2017-04-17  JF Bastien  <jfbastien@apple.com>
619
620         B3: don't allow unsigned offsets in Value
621         https://bugs.webkit.org/show_bug.cgi?id=170692
622
623         Reviewed by Filip Pizlo.
624
625         MemoryValue and similar B3 opcode classes always expects a signed
626         offset. Giving it an out-of-bounds unsigned offset causes
627         implementation-defined behavior, which can cause badness as I just
628         fixed in WebAssembly.  This patch makes it impossible to create a
629         Value opcodes with an unsigned value, or with an overly-large
630         value.
631
632         * b3/B3AtomicValue.cpp:
633         (JSC::B3::AtomicValue::AtomicValue):
634         * b3/B3AtomicValue.h:
635         * b3/B3Common.h:
636         (JSC::B3::isRepresentableAs):
637         * b3/B3EliminateCommonSubexpressions.cpp:
638         * b3/B3LowerToAir.cpp:
639         (JSC::B3::Air::LowerToAir::scaleForShl):
640         (JSC::B3::Air::LowerToAir::effectiveAddr):
641         (JSC::B3::Air::LowerToAir::addr):
642         (JSC::B3::Air::LowerToAir::tryAppendLea):
643         * b3/B3MemoryValue.cpp:
644         (JSC::B3::MemoryValue::isLegalOffsetImpl):
645         (JSC::B3::MemoryValue::MemoryValue):
646         * b3/B3MemoryValue.h:
647         * b3/B3MemoryValueInlines.h:
648         (JSC::B3::MemoryValue::isLegalOffsetImpl):
649         * b3/B3MoveConstants.cpp:
650         * b3/B3ReduceStrength.cpp:
651         * b3/B3StackmapSpecial.cpp:
652         (JSC::B3::StackmapSpecial::repForArg):
653         * b3/B3Value.h:
654         * b3/air/AirArg.cpp:
655         (JSC::B3::Air::Arg::stackAddrImpl):
656         * b3/air/AirArg.h:
657         (JSC::B3::Air::Arg::addr):
658         (JSC::B3::Air::Arg::stack):
659         (JSC::B3::Air::Arg::callArg):
660         (JSC::B3::Air::Arg::stackAddr):
661         (JSC::B3::Air::Arg::index):
662         (JSC::B3::Air::Arg::offset):
663         (JSC::B3::Air::Arg::isValidAddrForm):
664         (JSC::B3::Air::Arg::isValidIndexForm):
665         (JSC::B3::Air::Arg::asTrustedImm32):
666         (JSC::B3::Air::Arg::asAddress):
667         (JSC::B3::Air::Arg::asBaseIndex):
668         * b3/air/AirLowerStackArgs.cpp:
669         (JSC::B3::Air::lowerStackArgs):
670         * b3/testb3.cpp:
671         (JSC::B3::testMulArgStore):
672         (JSC::B3::testStore32):
673         (JSC::B3::testStoreConstant):
674         (JSC::B3::testStoreConstantPtr):
675         (JSC::B3::testStoreAddLoad32):
676         (JSC::B3::testStoreAddLoadImm32):
677         (JSC::B3::testStoreAddLoad8):
678         (JSC::B3::testStoreAddLoadImm8):
679         (JSC::B3::testStoreAddLoad16):
680         (JSC::B3::testStoreAddLoadImm16):
681         (JSC::B3::testStoreAddLoad64):
682         (JSC::B3::testStoreAddLoadImm64):
683         (JSC::B3::testStoreAddLoad32Index):
684         (JSC::B3::testStoreAddLoadImm32Index):
685         (JSC::B3::testStoreAddLoad64Index):
686         (JSC::B3::testStoreAddLoadImm64Index):
687         (JSC::B3::testStoreSubLoad):
688         (JSC::B3::testStoreAddLoadInterference):
689         (JSC::B3::testStoreAddAndLoad):
690         (JSC::B3::testStoreNegLoad32):
691         (JSC::B3::testStoreNegLoadPtr):
692         (JSC::B3::testLoadOffset):
693         (JSC::B3::testLoadOffsetNotConstant):
694         (JSC::B3::testLoadOffsetUsingAdd):
695         (JSC::B3::testLoadOffsetUsingAddInterference):
696         (JSC::B3::testLoadOffsetUsingAddNotConstant):
697         (JSC::B3::testStoreLoadStackSlot):
698         (JSC::B3::testLoad):
699         (JSC::B3::testInterpreter):
700         (JSC::B3::testTrappingStore):
701         (JSC::B3::testTrappingLoadAddStore):
702         (JSC::B3::testWasmAddress):
703         * wasm/WasmB3IRGenerator.cpp:
704         (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
705         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
706         (JSC::Wasm::B3IRGenerator::emitLoadOp):
707         (JSC::Wasm::B3IRGenerator::emitStoreOp):
708
709 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
710
711         test262: test262/test/built-ins/Object/prototype/toLocaleString/primitive_this_value.js
712         https://bugs.webkit.org/show_bug.cgi?id=170882
713
714         Reviewed by Saam Barati.
715
716         * runtime/ObjectPrototype.cpp:
717         (JSC::objectProtoFuncToLocaleString):
718         We should be using the this value without ToObject conversion both when
719         getting the potential accessor and calling it. In strict mode, the this
720         value will remain its simple value, in non-strict it is still converted.
721
722 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
723
724         test262: test262/test/built-ins/isNaN/toprimitive-not-callable-throws.js
725         https://bugs.webkit.org/show_bug.cgi?id=170888
726
727         Reviewed by Saam Barati.
728
729         * runtime/ExceptionHelpers.h:
730         * runtime/ExceptionHelpers.cpp:
731         (JSC::createInvalidInstanceofParameterErrorHasInstanceValueNotFunction):
732         Fix up this function name.
733
734         * runtime/JSObject.cpp:
735         (JSC::callToPrimitiveFunction):
736         When called with @@isPrimitive, bail on undefined or null and
737         throw a type error if the value is not callable.
738
739         (JSC::JSObject::toPrimitive):
740         Use throw scope to check for exception.
741
742 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
743
744         test262: test262/test/language/expressions/tagged-template/template-object.js
745         https://bugs.webkit.org/show_bug.cgi?id=170878
746
747         Reviewed by Saam Barati.
748
749         * runtime/JSArray.cpp:
750         (JSC::JSArray::put):
751         The fast path for setting an Array's length should check if length is
752         writable before checking for and possibly throwing a RangeError.
753
754 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
755
756         test262: test262/test/built-ins/Object/getOwnPropertyNames/15.2.3.4-4-44.js
757         https://bugs.webkit.org/show_bug.cgi?id=170879
758
759         Reviewed by Saam Barati.
760
761         * runtime/StringObject.h:
762         * runtime/StringObject.cpp:
763         (JSC::StringObject::getOwnPropertyNames):
764         (JSC::StringObject::getOwnNonIndexPropertyNames):
765         Ensure 'length' comes after all indexed properties by moving
766         it out to the getOwnNonIndexPropertyNames method which is called
767         inside of getOwnPropertyNames after JSObject handles indices.
768
769 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
770
771         test262: test262/test/built-ins/Date/prototype/Symbol.toPrimitive/name.js
772         https://bugs.webkit.org/show_bug.cgi?id=170884
773
774         Reviewed by Yusuke Suzuki.
775
776         * runtime/DatePrototype.cpp:
777         (JSC::DatePrototype::finishCreation):
778         * runtime/FunctionPrototype.cpp:
779         (JSC::FunctionPrototype::addFunctionProperties):
780         * runtime/RegExpPrototype.cpp:
781         (JSC::RegExpPrototype::finishCreation):
782         * runtime/SymbolPrototype.cpp:
783         (JSC::SymbolPrototype::finishCreation):
784         Give symbol property functions proper function names.
785         This addresses function.name but not function.toString().
786
787 2017-04-15  Joseph Pecoraro  <pecoraro@apple.com>
788
789         test262: test262/test/language/global-code/new.target-arrow.js
790         https://bugs.webkit.org/show_bug.cgi?id=170872
791
792         Reviewed by Saam Barati.
793
794         * parser/Parser.cpp:
795         (JSC::Parser<LexerType>::Parser):
796         Mark the global code scope.
797
798         (JSC::Parser<LexerType>::parseMemberExpression):
799         If new.target is detected in an arrow function defined in global scope
800         throw a SyntaxError.
801
802         * parser/Parser.h:
803         (JSC::Scope::Scope):
804         (JSC::Scope::setIsGlobalCodeScope):
805         (JSC::Scope::isGlobalCodeScope):
806         Marker for a global code scope.
807
808         * parser/ParserModes.h:
809         (JSC::isModuleParseMode):
810         (JSC::isProgramParseMode):
811         (JSC::isProgramOrModuleParseMode):
812         Helper for detecting global code based on parse mode.
813
814 2017-04-14  Nikita Vasilyev  <nvasilyev@apple.com>
815
816         Web Inspector: WebSockets: messages with non-latin letters are displayed incorrectly
817         https://bugs.webkit.org/show_bug.cgi?id=170760
818
819         Reviewed by Joseph Pecoraro.
820
821         Add payloadLength property, which is used to display size. When payloadLength is unavailable,
822         it is calculated from payloadData by Web Inspector frontend.
823
824         This fixes <webkit.org/b/170609> Web Inspector: WebSockets: Transferred size is incorrect.
825
826         * inspector/protocol/Network.json:
827
828 2017-04-14  Saam Barati  <sbarati@apple.com>
829
830         ParseInt intrinsic in DFG backend doesn't properly flush its operands
831         https://bugs.webkit.org/show_bug.cgi?id=170865
832
833         Reviewed by Mark Lam and Geoffrey Garen.
834
835         The DFG backend code needed to first call .gpr()/.jsValueRegs()
836         before calling flushRegisters(), or the input JSValueOperand would
837         not be flushed.
838
839         * dfg/DFGSpeculativeJIT.cpp:
840         (JSC::DFG::SpeculativeJIT::compileParseInt):
841
842 2017-04-14  Mark Lam  <mark.lam@apple.com>
843
844         Update architectures in xcconfig files.
845         https://bugs.webkit.org/show_bug.cgi?id=170867
846         <rdar://problem/31628104>
847
848         Reviewed by Joseph Pecoraro.
849
850         * Configurations/Base.xcconfig:
851         * Configurations/FeatureDefines.xcconfig:
852         * Configurations/JavaScriptCore.xcconfig:
853         * Configurations/ToolExecutable.xcconfig:
854
855 2017-04-14  Keith Miller  <keith_miller@apple.com>
856
857         WebAssembly: B3IRGenerator should use phis for result types
858         https://bugs.webkit.org/show_bug.cgi?id=170863
859
860         Reviewed by Filip Pizlo.
861
862         Currently, we use variables for the result types of control flow in
863         Wasm. We did this originally since we weren't sure that the phis we
864         generated would be optimal. Since then, we have verified that the edges
865         in wasm control flow ensure that each upsilon will dominate its phi
866         so we don't need to use variables.
867
868         * wasm/WasmB3IRGenerator.cpp:
869         (JSC::Wasm::B3IRGenerator::ControlData::ControlData):
870         (JSC::Wasm::B3IRGenerator::addTopLevel):
871         (JSC::Wasm::B3IRGenerator::addBlock):
872         (JSC::Wasm::B3IRGenerator::addLoop):
873         (JSC::Wasm::B3IRGenerator::unify):
874
875 2017-04-14  Alex Christensen  <achristensen@webkit.org>
876
877         Fix Windows build after r215368.
878         https://bugs.webkit.org/show_bug.cgi?id=170641
879
880         * CMakeLists.txt:
881         Add new directory containing files needed in WebCore.
882
883 2017-04-14  Caitlin Potter  <caitp@igalia.com>
884
885         [JSC] use ExpressionErrorClassifier for AwaitExpression operand
886         https://bugs.webkit.org/show_bug.cgi?id=170844
887
888         Reviewed by Saam Barati.
889
890         In parseAssignmentExpression(), several cover grammars are handled, and
891         use ExpressionErrorClassifier to record hints about which grammars to
892         try.
893
894         In parseAwaitExpression(), the hints recorded during parsing of the
895         operand need to be discarded, because if they propagate to the outer
896         parseAssignmentExpression(), the hints will lead the parser down invalid
897         branches that should be skipped.
898
899         This change adds an additional ExpressionErrorClassifier to
900         parseAwaitExpression(), in order to discard hints recorded trying to
901         parse the operand.
902
903         * parser/Parser.cpp:
904         (JSC::Parser<LexerType>::parseAwaitExpression):
905
906 2017-04-14  Saam Barati  <sbarati@apple.com>
907
908         WebAssembly: There is a short window of time where a CodeBlock could be destroyed before all of its async compilation callbacks are called
909         https://bugs.webkit.org/show_bug.cgi?id=170641
910
911         Reviewed by Keith Miller.
912
913         There is an unlikely race when a CodeBlock compilation fails,
914         the module compiles a new CodeBlock for that memory mode, all while
915         the CodeBlock is notifying its callbacks that it has finished.
916         There is a chance that the Module could deref its failed CodeBlock 
917         at that point, destroying it, before the callbacks were able to
918         grab a Ref to the CodeBlock. This patch fixes the race by having the
919         callbacks ref the CodeBlock.
920
921         This patch also has the Plan clear out all of its callbacks
922         once it gets completed. This adds an extra defense to anybody
923         that grabs refs to the Plan in the callback.
924
925         * wasm/WasmCodeBlock.cpp:
926         (JSC::Wasm::CodeBlock::CodeBlock):
927         (JSC::Wasm::CodeBlock::compileAsync):
928         * wasm/WasmPlan.cpp:
929         (JSC::Wasm::Plan::complete):
930
931 2017-04-13  Filip Pizlo  <fpizlo@apple.com>
932
933         Air::RegLiveness should be constraint-based
934         https://bugs.webkit.org/show_bug.cgi?id=170817
935
936         Reviewed by Saam Barati.
937         
938         Previously, I changed the Air liveness analyses based on Air::Liveness<> to be
939         constraint-based and this was a significant speed-up. Now I'm adding the same
940         functionality to RegLiveness.
941         
942         This is a 1% speed-up on wasm B3 -O1 compile times.
943         
944         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
945         * b3/air/AirLivenessAdapter.h:
946         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
947         (JSC::B3::Air::LivenessAdapter::prepareToCompute):
948         (JSC::B3::Air::LivenessAdapter::actionsAt):
949         * b3/air/AirRegLiveness.cpp:
950         (JSC::B3::Air::RegLiveness::RegLiveness):
951         (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::LocalCalcForUnifiedTmpLiveness):
952         (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::execute):
953         (JSC::B3::Air::RegLiveness::LocalCalc::execute): Deleted.
954         * b3/air/AirRegLiveness.h:
955         (JSC::B3::Air::RegLiveness::Actions::Actions):
956         (JSC::B3::Air::RegLiveness::LocalCalcBase::LocalCalcBase):
957         (JSC::B3::Air::RegLiveness::LocalCalcBase::live):
958         (JSC::B3::Air::RegLiveness::LocalCalcBase::isLive):
959         (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
960         (JSC::B3::Air::RegLiveness::LocalCalc::execute):
961         (JSC::B3::Air::RegLiveness::LocalCalc::live): Deleted.
962         (JSC::B3::Air::RegLiveness::LocalCalc::isLive): Deleted.
963
964 2017-04-13  JF Bastien  <jfbastien@apple.com>
965
966         WebAssembly: fix windows build
967         https://bugs.webkit.org/show_bug.cgi?id=170832
968
969         Reviewed by Mark Lam.
970
971         My previous patch re-declared isIOS which AssemblerCommon.h
972         already provided, and which was already included by Options.cpp.
973
974         * runtime/Options.cpp:
975
976 2017-04-13  Saam Barati  <sbarati@apple.com>
977
978         WebAssembly: We should be able to postMessage a JSWebAssemblyModule
979         https://bugs.webkit.org/show_bug.cgi?id=170573
980
981         Reviewed by Filip Pizlo.
982
983         This patch adds a callback to JSRunLoopTimer to notify
984         clients that a timer has been set. This is used inside
985         WorkerRunLoop in WebCore so that its RunLoop can perform
986         an iteration when it sees that a timer got set.
987
988         * JavaScriptCore.xcodeproj/project.pbxproj:
989         * runtime/JSRunLoopTimer.cpp:
990         (JSC::JSRunLoopTimer::scheduleTimer):
991         (JSC::JSRunLoopTimer::addTimerSetNotification):
992         (JSC::JSRunLoopTimer::removeTimerSetNotification):
993         * runtime/JSRunLoopTimer.h:
994         * wasm/WasmCodeBlock.cpp:
995         (JSC::Wasm::CodeBlock::~CodeBlock):
996         * wasm/WasmCodeBlock.h:
997         * wasm/WasmModule.cpp:
998         (JSC::Wasm::Module::~Module):
999         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
1000         (JSC::Wasm::makeValidationCallback):
1001         (JSC::Wasm::Module::validateSync):
1002         (JSC::Wasm::Module::validateAsync):
1003         (JSC::Wasm::Module::validateSyncImpl): Deleted.
1004         (JSC::Wasm::Module::makeValidationCallback): Deleted.
1005         * wasm/WasmModule.h:
1006         (JSC::Wasm::Module::validateSync): Deleted.
1007         (JSC::Wasm::Module::validateAsync): Deleted.
1008         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): Deleted.
1009         (JSC::Wasm::Module::nonNullCodeBlock): Deleted.
1010         * wasm/js/JSWebAssemblyCodeBlock.cpp:
1011         (JSC::JSWebAssemblyCodeBlock::create):
1012         * wasm/js/JSWebAssemblyCodeBlock.h:
1013         (JSC::JSWebAssemblyCodeBlock::create): Deleted.
1014         * wasm/js/JSWebAssemblyModule.cpp:
1015         (JSC::JSWebAssemblyModule::source):
1016         * wasm/js/JSWebAssemblyModule.h:
1017         (JSC::JSWebAssemblyModule::source): Deleted.
1018         * wasm/js/WebAssemblyFunction.cpp:
1019         (JSC::callWebAssemblyFunction):
1020         * wasm/js/WebAssemblyModulePrototype.cpp:
1021
1022 2017-04-13  Mark Lam  <mark.lam@apple.com>
1023
1024         Should use flushDirect() when flushing the scopeRegister due to needsScopeRegister().
1025         https://bugs.webkit.org/show_bug.cgi?id=170661
1026         <rdar://problem/31579046>
1027
1028         Reviewed by Filip Pizlo.
1029
1030         Previously, we were using flush() to flush the outermost frame's scopeRegister.
1031         This is incorrect because flush() expects the VirtualRegister value passed to
1032         it to be that of the top most inlined frame.  In the event that we reach a
1033         terminal condition while inside an inlined frame, flush() will end up flushing
1034         the wrong register.  The fix is simply to use flushDirect() instead.
1035
1036         * dfg/DFGByteCodeParser.cpp:
1037         (JSC::DFG::ByteCodeParser::flush):
1038
1039 2017-04-13  Andy VanWagoner  <thetalecrafter@gmail.com>
1040
1041         Change Intl prototypes to plain objects
1042         https://bugs.webkit.org/show_bug.cgi?id=168178
1043
1044         Reviewed by JF Bastien.
1045
1046         * builtins/StringPrototype.js:
1047         (localeCompare): Create default Collator once instead of using prototype.
1048         * runtime/IntlCollatorPrototype.cpp:
1049         (JSC::IntlCollatorPrototype::IntlCollatorPrototype):
1050         * runtime/IntlCollatorPrototype.h:
1051         * runtime/IntlDateTimeFormatPrototype.cpp:
1052         (JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype):
1053         * runtime/IntlDateTimeFormatPrototype.h:
1054         * runtime/IntlNumberFormatPrototype.cpp:
1055         (JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype):
1056         * runtime/IntlNumberFormatPrototype.h:
1057         * runtime/IntlObject.cpp:
1058         (JSC::IntlObject::finishCreation): Don't set constructor on each prototype.
1059
1060 2017-04-13  Oliver Hunt  <oliver@apple.com>
1061
1062         allocationSize should use safe arithmetic by default
1063         https://bugs.webkit.org/show_bug.cgi?id=170804
1064
1065         Reviewed by JF Bastien.
1066
1067         Make all allocationSize() functions work in terms
1068         of Checked<size_t>
1069
1070         * runtime/DirectArguments.h:
1071         (JSC::DirectArguments::offsetOfSlot):
1072         (JSC::DirectArguments::allocationSize):
1073         * runtime/HashMapImpl.h:
1074         (JSC::HashMapBuffer::allocationSize):
1075         * runtime/JSArray.h:
1076         (JSC::JSArray::allocationSize):
1077         * runtime/JSArrayBufferView.h:
1078         (JSC::JSArrayBufferView::allocationSize):
1079         * runtime/JSAsyncFunction.h:
1080         (JSC::JSAsyncFunction::allocationSize):
1081         * runtime/JSFixedArray.h:
1082         (JSC::JSFixedArray::allocationSize):
1083         * runtime/JSFunction.h:
1084         (JSC::JSFunction::allocationSize):
1085         * runtime/JSGeneratorFunction.h:
1086         (JSC::JSGeneratorFunction::allocationSize):
1087         * runtime/JSModuleNamespaceObject.h:
1088         * runtime/JSObject.h:
1089         (JSC::JSFinalObject::allocationSize):
1090         * runtime/JSWrapperObject.h:
1091         (JSC::JSWrapperObject::allocationSize):
1092         * runtime/ScopedArguments.h:
1093         (JSC::ScopedArguments::allocationSize):
1094         * runtime/VM.h:
1095         (JSC::ScratchBuffer::allocationSize):
1096         * wasm/js/JSWebAssemblyCodeBlock.h:
1097         (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
1098         (JSC::JSWebAssemblyCodeBlock::allocationSize):
1099         * wasm/js/JSWebAssemblyInstance.h:
1100         (JSC::JSWebAssemblyInstance::allocationSize):
1101
1102 2017-04-13  JF Bastien  <jfbastien@apple.com>
1103
1104         WebAssembly: manage memory better
1105         https://bugs.webkit.org/show_bug.cgi?id=170628
1106
1107         Reviewed by Keith Miller, Michael Saboff.
1108
1109         WebAssembly fast memories weren't managed very well. This patch
1110         refactors it and puts us in a good position to further improve our
1111         fast memory handling in the future.
1112
1113         We now cache fast memories at a process granularity, but make sure
1114         that they don't consume dirty pages. We add a cap to the total
1115         number of allocated fast memories to avoid ASLR degradation.
1116
1117         We teach the GC about memories as a kind of resource it should
1118         care about because it didn't have visibility into the amount of
1119         memory each represented. This allows benchmarks which allocate
1120         memories back-to-back to reliably get fast memories 100% of the
1121         time, even on a system under load, which wasn't the case
1122         before. This reliability yields roughly 8% perf bump on x86-64
1123         WasmBench.
1124
1125         The GC heuristic is as follows: each time we allocate a fast
1126         memory we notify the GC, which then keeps track of the total
1127         number of fast memories allocated since it last GC'd. We
1128         separately keep track of the total number of fast memories which
1129         have ever existed at any point in time (cached + allocated). This
1130         is a monotonically-increasing high watermark. The GC will force a
1131         full collection if, since it last ran, half or more of the high
1132         watermark of fast memories was allocated.
1133
1134         At the same time, if we fail obtaining a fast memory from the
1135         cache we do a GC to try to find one. If that fails we'll allocate
1136         a new one (this can also fail, then we go to slow memory). This
1137         can also be improved, but it's a good start.
1138
1139         This currently disables fast memories on iOS because getting fast
1140         memories isn't a guaranteed thing. Rather, we get quite a few of
1141         them and achieve significant speedups, but benchmarks which
1142         allocate memories back-to-back end up falling behind because the
1143         GC can conservatively hold onto memories, which then yields a perf
1144         cliff. That cliff isn't reliable, WasmBench gets roughly 10 of 18
1145         fast memories when in theory it should get all of them fast (as
1146         MacOS does). The patch significantly improves the state of iOS
1147         though, and in a follow-up we could re-enable fast memories.
1148
1149         Part of this good positioning is a facility to pre-allocate fast
1150         memories very early at startup, before any fragmentation
1151         occurs. This is currently disabled but worked extremely reliably
1152         on iOS. Once we fix the above issues we'll want to re-visit and
1153         turn on pre-allocation.
1154
1155         We also avoid locking for fast memory identification when
1156         performing signal handling. I'm very nervous about acquiring locks
1157         in a signal handler because in general signals can happen when
1158         we've messed up. This isn't the case with fast memories: we're
1159         raising a signal on purpose and handling it. However this doesn't
1160         mean we won't mess up elsewhere! This will get more complicated
1161         once we add support for multiple threads sharing memories and
1162         being able to grow their memories. One example: the code calls
1163         CRASH(), which executes the following code in release:
1164
1165             *(int *)(uintptr_t)0xbbadbeef = 0;
1166
1167         This is a segfault, which our fast memory signal handler tries to
1168         handle. It does so by first figuring out whether 0xbbadbeef is in
1169         a fast memory region, reqiring a lock. If we CRASH() while holding
1170         the lock then our thread self-deadlocks, giving us no crash report
1171         and a bad user experience.
1172
1173         Avoiding a lock therefore it's not about speed or reduced
1174         contention. In fact, I'd use something else than a FIFO if these
1175         were a concern. We're also doing syscalls, which dwarf any locking
1176         cost.
1177
1178         We now only allocate 4GiB + redzone of 64k * 128 for fast memories
1179         instead of 8GiB. This patch reuses the logic from
1180         B3::WasmBoundsCheck to perform bounds checks when accesses could
1181         exceed the redzone. We'll therefore benefit from CSE goodness when
1182         it reaches WasmBoundsCheck. See bug #163469.
1183
1184         * b3/B3LowerToAir.cpp: fix a baaaaddd bug where unsigned->signed
1185         conversion allowed out-of-bounds reads by -2GiB. I'll follow-up in
1186         bug #170692 to prevent this type of bug once and for all.
1187         (JSC::B3::Air::LowerToAir::lower):
1188         * b3/B3Validate.cpp: update WasmBoundsCheck validation.
1189         * b3/B3Value.cpp:
1190         (JSC::B3::Value::effects): update WasmBoundsCheck effects.
1191         * b3/B3WasmBoundsCheckValue.cpp:
1192         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
1193         (JSC::B3::WasmBoundsCheckValue::redzoneLimit):
1194         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
1195         * b3/B3WasmBoundsCheckValue.h:
1196         (JSC::B3::WasmBoundsCheckValue::maximum):
1197         * b3/air/AirCustom.cpp:
1198         (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
1199         * b3/testb3.cpp:
1200         (JSC::B3::testWasmBoundsCheck):
1201         * heap/Heap.cpp:
1202         (JSC::Heap::Heap):
1203         (JSC::Heap::reportWebAssemblyFastMemoriesAllocated):
1204         (JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold):
1205         (JSC::Heap::updateAllocationLimits):
1206         (JSC::Heap::didAllocateWebAssemblyFastMemories):
1207         (JSC::Heap::shouldDoFullCollection):
1208         (JSC::Heap::collectIfNecessaryOrDefer):
1209         * heap/Heap.h:
1210         * runtime/InitializeThreading.cpp:
1211         (JSC::initializeThreading):
1212         * runtime/Options.cpp:
1213         * runtime/Options.h:
1214         * wasm/WasmB3IRGenerator.cpp:
1215         (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
1216         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1217         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
1218         (JSC::Wasm::B3IRGenerator::emitLoadOp):
1219         (JSC::Wasm::B3IRGenerator::emitStoreOp):
1220         (JSC::Wasm::createJSToWasmWrapper):
1221         * wasm/WasmFaultSignalHandler.cpp:
1222         (JSC::Wasm::trapHandler):
1223         * wasm/WasmMemory.cpp: Rewrite.
1224         (JSC::Wasm::makeString):
1225         (JSC::Wasm::Memory::initializePreallocations):
1226         (JSC::Wasm::Memory::createImpl):
1227         (JSC::Wasm::Memory::create):
1228         (JSC::Wasm::Memory::~Memory):
1229         (JSC::Wasm::Memory::fastMappedRedzoneBytes):
1230         (JSC::Wasm::Memory::fastMappedBytes):
1231         (JSC::Wasm::Memory::maxFastMemoryCount):
1232         (JSC::Wasm::Memory::addressIsInActiveFastMemory):
1233         (JSC::Wasm::Memory::grow):
1234         * wasm/WasmMemory.h:
1235         (Memory::maxFastMemoryCount):
1236         (Memory::addressIsInActiveFastMemory):
1237         * wasm/js/JSWebAssemblyInstance.cpp:
1238         (JSC::JSWebAssemblyInstance::finishCreation):
1239         (JSC::JSWebAssemblyInstance::visitChildren):
1240         (JSC::JSWebAssemblyInstance::globalMemoryByteSize):
1241         * wasm/js/JSWebAssemblyInstance.h:
1242         * wasm/js/JSWebAssemblyMemory.cpp:
1243         (JSC::JSWebAssemblyMemory::grow):
1244         (JSC::JSWebAssemblyMemory::finishCreation):
1245         (JSC::JSWebAssemblyMemory::visitChildren):
1246
1247 2017-04-13  Yusuke Suzuki  <utatane.tea@gmail.com>
1248
1249         [JSC] Use proper ifdef guard for code using MachineContext
1250         https://bugs.webkit.org/show_bug.cgi?id=170800
1251
1252         Reviewed by Carlos Alberto Lopez Perez.
1253
1254         This patch drops MachineContext use if it is not available.
1255         This situation can be considered like, building WebKit with musl.
1256         In that case, we simply disable features that rely on MachineContext.
1257         Examples are wasm fast memory, sampling profiler, and code profiling.
1258
1259         * runtime/Options.cpp:
1260         (JSC::overrideDefaults):
1261         * tools/CodeProfiling.cpp:
1262         (JSC::CodeProfiling::begin):
1263         (JSC::CodeProfiling::end):
1264         Previously, PLATFORM(GTK) is excluded. But it is not obvious why it is excluded.
1265         This patch just includes such platforms.
1266
1267         * wasm/WasmFaultSignalHandler.cpp:
1268         (JSC::Wasm::enableFastMemory):
1269
1270 2017-04-12  Dan Bernstein  <mitz@apple.com>
1271
1272         [Mac] Future-proof .xcconfig files
1273         https://bugs.webkit.org/show_bug.cgi?id=170802
1274
1275         Reviewed by Tim Horton.
1276
1277         * Configurations/Base.xcconfig:
1278         * Configurations/DebugRelease.xcconfig:
1279         * Configurations/FeatureDefines.xcconfig:
1280         * Configurations/Version.xcconfig:
1281
1282 2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>
1283
1284         test262: test262/test/built-ins/NativeErrors/EvalError/proto.js
1285         https://bugs.webkit.org/show_bug.cgi?id=170668
1286
1287         Reviewed by Keith Miller.
1288
1289         * runtime/JSGlobalObject.cpp:
1290         (JSC::JSGlobalObject::init):
1291         The [[Prototype]] of NativeError Constructor's should be the %Error%.
1292         https://tc39.github.io/ecma262/#sec-properties-of-the-nativeerror-constructors
1293
1294 2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>
1295
1296         test262: test262/test/language/literals/regexp/u-dec-esc.js
1297         https://bugs.webkit.org/show_bug.cgi?id=170687
1298
1299         Reviewed by Michael Saboff.
1300
1301         * yarr/YarrParser.h:
1302         (JSC::Yarr::Parser::parseEscape):
1303         * yarr/YarrPattern.cpp:
1304         (JSC::Yarr::YarrPattern::errorMessage):
1305         (JSC::Yarr::YarrPattern::compile):
1306         * yarr/YarrPattern.h:
1307         In unicoe patterns, invalid backreferences are an error.
1308
1309 2017-04-12  Filip Pizlo  <fpizlo@apple.com>
1310
1311         Move common stack allocation utilities out of AirAllocateStackByGraphColoring.cpp
1312         https://bugs.webkit.org/show_bug.cgi?id=170799
1313
1314         Reviewed by Michael Saboff and Keith Miller.
1315         
1316         When I added stack allocation to allocateRegistersByLinearScan, I reused a handful of
1317         utility functions from AirAllocateStackByGraphColoring.cpp. I accomplished this by
1318         putting their declarations in AirAllocateStackByGraphColoring.h.
1319         
1320         That was pretty weird.
1321         
1322         This patch moves a family of stack allocation helper functions out of
1323         AirAllocateStackByGraphColoring.cpp and into the new AirStackAllocation.h|cpp. The
1324         linear scan stack allocator no longer has to include the other stack allocator's
1325         header, which addresses my OCD.
1326         
1327         I moved the functions transitively reachable from the two functions that the linear
1328         scan allocator needed. This forced me to give them better names (i.e. no "fooBarImpl")
1329         and short descriptive comments. I think that such comments are useful in code that is
1330         doing a convoluted version of some theoretical concept.
1331         
1332         No behavior change.
1333
1334         * CMakeLists.txt:
1335         * JavaScriptCore.xcodeproj/project.pbxproj:
1336         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
1337         * b3/air/AirAllocateStackByGraphColoring.cpp:
1338         (JSC::B3::Air::allocateStackByGraphColoring):
1339         (JSC::B3::Air::allocateEscapedStackSlots): Deleted.
1340         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): Deleted.
1341         * b3/air/AirAllocateStackByGraphColoring.h:
1342         * b3/air/AirStackAllocation.cpp: Added.
1343         (JSC::B3::Air::attemptAssignment):
1344         (JSC::B3::Air::assign):
1345         (JSC::B3::Air::allocateAndGetEscapedStackSlotsWithoutChangingFrameSize):
1346         (JSC::B3::Air::allocateEscapedStackSlots):
1347         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
1348         * b3/air/AirStackAllocation.h: Added.
1349
1350 2017-04-12  Filip Pizlo  <fpizlo@apple.com>
1351
1352         B3 -O1 should not allocateStackByGraphColoring
1353         https://bugs.webkit.org/show_bug.cgi?id=170742
1354
1355         Reviewed by Keith Miller.
1356         
1357         One of B3 -O1's longest running phases is allocateStackByGraphColoring. One approach to
1358         this would be to make that phase cheaper. But it's weird that this phase reruns
1359         liveness after register allocation already ran liveness. If only it could reuse the
1360         liveness computed by register allocation then it would run a lot faster. At -O2, we do
1361         not want this, since we run phases between register allocation and stack allocation,
1362         and those phases are free to change the liveness of spill slots (in fact,
1363         fixObviousSpills will both shorten and lengthen live ranges because of load and store
1364         elimination, respectively). But at -O1, we don't really need to run any phases between
1365         register and stack allocation.
1366         
1367         This changes Air's backend in the following ways:
1368         
1369         - Linear scan does stack allocation. This means that we don't need to run
1370           allocateStackByGraphColoring at all. In reality, we reuse some of its innards, but
1371           we don't run the expensive part of it (liveness->interference->coalescing->coloring).
1372           This is a speed-up because we only run liveness once and reuse it for both register
1373           and stack allocation.
1374         
1375         - Phases that previously ran between register and stack allocation are taken care of,
1376           each in its own special way:
1377           
1378           -> handleCalleSaves: this is now a utility function called by both
1379              allocateStackByGraphColoring and allocateRegistersAndStackByLinearScan.
1380           
1381           -> fixObviousSpills: we didn't run this at -O1, so nothing needs to be done.
1382           
1383           -> lowerAfterRegAlloc: this needed to be able to run before stack allocation because
1384              it could change register usage (vis a vis callee saves) and it could introduce
1385              spill slots. I changed this phase to have a secondary mode for when it runs after
1386              stack allocation.
1387         
1388         - The part of allocateStackByGraphColoring that lowered stack addresses and took care
1389           of the call arg area is now a separate phase called lowerStackArgs. We run this phase
1390           regardless of optimization level. It's a cheap and general lowering.
1391         
1392         This also removes spillEverything, because we never use that phase, we never test it,
1393         and it got in the way in this refactoring.
1394         
1395         This is a 21% speed-up on wasm -O1 compile times. This does not significantly change
1396         -O1 throughput. We had already disabled allocateStack's most important optimization
1397         (spill coalescing). This probably regresses average stack frame size, but I didn't
1398         measure by how much. Stack frame size is really not that important. The algorithm in
1399         allocateStackByGraphColoring is about much more than optimal frame size; it also
1400         tries to avoid having to zero-extend 32-bit spills, it kills dead code, and of course
1401         it coalesces.
1402
1403         * CMakeLists.txt:
1404         * JavaScriptCore.xcodeproj/project.pbxproj:
1405         * b3/B3Procedure.cpp:
1406         (JSC::B3::Procedure::calleeSaveRegisterAtOffsetList):
1407         (JSC::B3::Procedure::calleeSaveRegisters): Deleted.
1408         * b3/B3Procedure.h:
1409         * b3/B3StackmapGenerationParams.cpp:
1410         (JSC::B3::StackmapGenerationParams::unavailableRegisters):
1411         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.cpp.
1412         (JSC::B3::Air::allocateRegistersAndStackByLinearScan):
1413         (JSC::B3::Air::allocateRegistersByLinearScan): Deleted.
1414         * b3/air/AirAllocateRegistersAndStackByLinearScan.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.h.
1415         * b3/air/AirAllocateRegistersByLinearScan.cpp: Removed.
1416         * b3/air/AirAllocateRegistersByLinearScan.h: Removed.
1417         * b3/air/AirAllocateStackByGraphColoring.cpp:
1418         (JSC::B3::Air::allocateEscapedStackSlots):
1419         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
1420         (JSC::B3::Air::allocateStackByGraphColoring):
1421         * b3/air/AirAllocateStackByGraphColoring.h:
1422         * b3/air/AirArg.cpp:
1423         (JSC::B3::Air::Arg::stackAddr):
1424         * b3/air/AirArg.h:
1425         (JSC::B3::Air::Arg::stackAddr): Deleted.
1426         * b3/air/AirCode.cpp:
1427         (JSC::B3::Air::Code::addStackSlot):
1428         (JSC::B3::Air::Code::setCalleeSaveRegisterAtOffsetList):
1429         (JSC::B3::Air::Code::calleeSaveRegisterAtOffsetList):
1430         (JSC::B3::Air::Code::dump):
1431         * b3/air/AirCode.h:
1432         (JSC::B3::Air::Code::setStackIsAllocated):
1433         (JSC::B3::Air::Code::stackIsAllocated):
1434         (JSC::B3::Air::Code::calleeSaveRegisters):
1435         * b3/air/AirGenerate.cpp:
1436         (JSC::B3::Air::prepareForGeneration):
1437         (JSC::B3::Air::generate):
1438         * b3/air/AirHandleCalleeSaves.cpp:
1439         (JSC::B3::Air::handleCalleeSaves):
1440         * b3/air/AirHandleCalleeSaves.h:
1441         * b3/air/AirLowerAfterRegAlloc.cpp:
1442         (JSC::B3::Air::lowerAfterRegAlloc):
1443         * b3/air/AirLowerStackArgs.cpp: Added.
1444         (JSC::B3::Air::lowerStackArgs):
1445         * b3/air/AirLowerStackArgs.h: Added.
1446         * b3/testb3.cpp:
1447         (JSC::B3::testPinRegisters):
1448         * ftl/FTLCompile.cpp:
1449         (JSC::FTL::compile):
1450         * jit/RegisterAtOffsetList.h:
1451         * wasm/WasmB3IRGenerator.cpp:
1452         (JSC::Wasm::parseAndCompile):
1453
1454 2017-04-12  Michael Saboff  <msaboff@apple.com>
1455
1456         Implement Object.isFrozen() and Object.isSealed() per ECMA spec
1457         https://bugs.webkit.org/show_bug.cgi?id=170753
1458
1459         Reviewed by Mark Lam.
1460
1461         * runtime/ObjectConstructor.cpp:
1462         (JSC::testIntegrityLevel): Added local helper as described in the ECMA standard.
1463
1464         (JSC::objectConstructorSeal):
1465         (JSC::objectConstructorFreeze):
1466         Eliminated incomplete special handling of JSFinalObjects.
1467
1468         (JSC::objectConstructorIsSealed):
1469         (JSC::objectConstructorIsFrozen):
1470         Refactored to use the new testIntegrityLevel() helper.
1471
1472 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1473
1474         Use HAVE(MACHINE_CONTEXT) instead of USE(MACHINE_CONTEXT)
1475         https://bugs.webkit.org/show_bug.cgi?id=170770
1476
1477         Rubber stamped by Mark Lam.
1478
1479         * heap/MachineStackMarker.cpp:
1480         (JSC::MachineThreads::MachineThread::Registers::framePointer):
1481         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
1482         (JSC::MachineThreads::MachineThread::Registers::llintPC):
1483         * runtime/MachineContext.h:
1484         (JSC::MachineContext::stackPointer):
1485         (JSC::MachineContext::framePointer):
1486         (JSC::MachineContext::instructionPointer):
1487         (JSC::MachineContext::argumentPointer<1>):
1488         (JSC::MachineContext::llintInstructionPointer):
1489
1490 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1491
1492         [JSC] Clean up heap/MachineStackMarker by introducing USE(MACHINE_CONTEXT)
1493         https://bugs.webkit.org/show_bug.cgi?id=170770
1494
1495         Reviewed by Mark Lam.
1496
1497         We use USE(MACHINE_CONTEXT) to clean up runtime/MachineContext.h. And
1498         we clean up heap/MachineStackMarker.cpp by using MachineContext functions.
1499
1500         * heap/MachineStackMarker.cpp:
1501         (JSC::MachineThreads::MachineThread::Registers::stackPointer):
1502         (JSC::MachineThreads::MachineThread::Registers::framePointer):
1503         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
1504         (JSC::MachineThreads::MachineThread::Registers::llintPC):
1505         * heap/MachineStackMarker.h:
1506         * runtime/MachineContext.h:
1507         (JSC::MachineContext::stackPointer):
1508         (JSC::MachineContext::framePointer):
1509         (JSC::MachineContext::instructionPointer):
1510         (JSC::MachineContext::argumentPointer<1>):
1511         (JSC::MachineContext::llintInstructionPointer):
1512
1513 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1514
1515         [WTF] Introduce Thread class and use RefPtr<Thread> and align Windows Threading implementation semantics to Pthread one
1516         https://bugs.webkit.org/show_bug.cgi?id=170502
1517
1518         Reviewed by Mark Lam.
1519
1520         * API/tests/CompareAndSwapTest.cpp:
1521         (testCompareAndSwap):
1522         * JavaScriptCore.xcodeproj/project.pbxproj:
1523         * b3/air/testair.cpp:
1524         * b3/testb3.cpp:
1525         (JSC::B3::run):
1526         * bytecode/SuperSampler.cpp:
1527         (JSC::initializeSuperSampler):
1528         * dfg/DFGWorklist.cpp:
1529         * disassembler/Disassembler.cpp:
1530         * heap/Heap.cpp:
1531         (JSC::Heap::lastChanceToFinalize):
1532         (JSC::Heap::notifyIsSafeToCollect):
1533         * heap/Heap.h:
1534         * heap/MachineStackMarker.cpp:
1535         (JSC::MachineThreads::~MachineThreads):
1536         (JSC::MachineThreads::addCurrentThread):
1537         (JSC::MachineThreads::removeThread):
1538         (JSC::MachineThreads::removeThreadIfFound):
1539         (JSC::MachineThreads::MachineThread::MachineThread):
1540         (JSC::MachineThreads::MachineThread::getRegisters):
1541         (JSC::MachineThreads::MachineThread::Registers::stackPointer):
1542         (JSC::MachineThreads::MachineThread::Registers::framePointer):
1543         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
1544         (JSC::MachineThreads::MachineThread::Registers::llintPC):
1545         (JSC::MachineThreads::MachineThread::captureStack):
1546         (JSC::MachineThreads::tryCopyOtherThreadStack):
1547         (JSC::MachineThreads::tryCopyOtherThreadStacks):
1548         (pthreadSignalHandlerSuspendResume): Deleted.
1549         (JSC::threadData): Deleted.
1550         (JSC::MachineThreads::Thread::Thread): Deleted.
1551         (JSC::MachineThreads::Thread::createForCurrentThread): Deleted.
1552         (JSC::MachineThreads::Thread::operator==): Deleted.
1553         (JSC::MachineThreads::machineThreadForCurrentThread): Deleted.
1554         (JSC::MachineThreads::ThreadData::ThreadData): Deleted.
1555         (JSC::MachineThreads::ThreadData::~ThreadData): Deleted.
1556         (JSC::MachineThreads::ThreadData::suspend): Deleted.
1557         (JSC::MachineThreads::ThreadData::resume): Deleted.
1558         (JSC::MachineThreads::ThreadData::getRegisters): Deleted.
1559         (JSC::MachineThreads::ThreadData::Registers::stackPointer): Deleted.
1560         (JSC::MachineThreads::ThreadData::Registers::framePointer): Deleted.
1561         (JSC::MachineThreads::ThreadData::Registers::instructionPointer): Deleted.
1562         (JSC::MachineThreads::ThreadData::Registers::llintPC): Deleted.
1563         (JSC::MachineThreads::ThreadData::freeRegisters): Deleted.
1564         (JSC::MachineThreads::ThreadData::captureStack): Deleted.
1565         * heap/MachineStackMarker.h:
1566         (JSC::MachineThreads::MachineThread::suspend):
1567         (JSC::MachineThreads::MachineThread::resume):
1568         (JSC::MachineThreads::MachineThread::threadID):
1569         (JSC::MachineThreads::MachineThread::stackBase):
1570         (JSC::MachineThreads::MachineThread::stackEnd):
1571         (JSC::MachineThreads::threadsListHead):
1572         (JSC::MachineThreads::Thread::operator!=): Deleted.
1573         (JSC::MachineThreads::Thread::suspend): Deleted.
1574         (JSC::MachineThreads::Thread::resume): Deleted.
1575         (JSC::MachineThreads::Thread::getRegisters): Deleted.
1576         (JSC::MachineThreads::Thread::freeRegisters): Deleted.
1577         (JSC::MachineThreads::Thread::captureStack): Deleted.
1578         (JSC::MachineThreads::Thread::platformThread): Deleted.
1579         (JSC::MachineThreads::Thread::stackBase): Deleted.
1580         (JSC::MachineThreads::Thread::stackEnd): Deleted.
1581         * jit/ICStats.cpp:
1582         (JSC::ICStats::ICStats):
1583         (JSC::ICStats::~ICStats):
1584         * jit/ICStats.h:
1585         * jsc.cpp:
1586         (functionDollarAgentStart):
1587         (startTimeoutThreadIfNeeded):
1588         * runtime/JSLock.cpp:
1589         (JSC::JSLock::lock):
1590         * runtime/JSLock.h:
1591         (JSC::JSLock::ownerThread):
1592         (JSC::JSLock::currentThreadIsHoldingLock):
1593         * runtime/SamplingProfiler.cpp:
1594         (JSC::FrameWalker::isValidFramePointer):
1595         (JSC::SamplingProfiler::SamplingProfiler):
1596         (JSC::SamplingProfiler::createThreadIfNecessary):
1597         (JSC::SamplingProfiler::takeSample):
1598         * runtime/SamplingProfiler.h:
1599         * runtime/VM.h:
1600         (JSC::VM::ownerThread):
1601         * runtime/VMTraps.cpp:
1602         (JSC::findActiveVMAndStackBounds):
1603         (JSC::VMTraps::SignalSender::send):
1604         (JSC::VMTraps::fireTrap):
1605
1606 2017-04-11  Dean Jackson  <dino@apple.com>
1607
1608         Disable outdated WritableStream API
1609         https://bugs.webkit.org/show_bug.cgi?id=170749
1610         <rdar://problem/31446233>
1611
1612         Reviewed by Tim Horton.
1613
1614         The API we implement is no longer accurate. Disable it until we
1615         are compatible with the new specification
1616
1617         * Configurations/FeatureDefines.xcconfig:
1618
1619 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1620
1621         Unreviewed, build fix for CF ports after r215241
1622         https://bugs.webkit.org/show_bug.cgi?id=170725
1623
1624         * heap/GCActivityCallback.cpp:
1625         (JSC::GCActivityCallback::nextFireTime):
1626
1627 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1628
1629         [WebCore][JSC] ResourceUsageData.{timeOfNextEdenCollection,timeOfNextFullCollection} should be MonotonicTime
1630         https://bugs.webkit.org/show_bug.cgi?id=170725
1631
1632         Reviewed by Sam Weinig.
1633
1634         This patch makes GCActivityCallback return MonotonicTime instead of raw double value.
1635
1636         * heap/GCActivityCallback.cpp:
1637         (JSC::GCActivityCallback::nextFireTime):
1638         * heap/GCActivityCallback.h:
1639
1640 2017-04-11  Guillaume Emont  <guijemont@igalia.com>
1641
1642         [jsc] Add missing MacroAssemblerMIPS::or32() implementation
1643         https://bugs.webkit.org/show_bug.cgi?id=169714
1644
1645         Reviewed by Michael Catanzaro.
1646
1647         * assembler/MacroAssemblerMIPS.h:
1648         (JSC::MacroAssemblerMIPS::or32):
1649         Added or32(TrustedImm32, Address).
1650
1651 2017-04-11  Joseph Pecoraro  <pecoraro@apple.com>
1652
1653         test262: test262/test/annexB/language/comments/multi-line-html-close.js
1654         https://bugs.webkit.org/show_bug.cgi?id=170648
1655
1656         Reviewed by Keith Miller.
1657
1658         * parser/Lexer.cpp:
1659         (JSC::Lexer<T>::lex):
1660         A multi-line comment that contains a line terminator is itself treated
1661         like a line terminator. An HTML Close Comment that comes after it can
1662         therefore treat it like it is at the start of a line, because it was
1663         immediately preceeded by the equivalent of a line terminator.
1664
1665 2017-04-11  Joseph Pecoraro  <pecoraro@apple.com>
1666
1667         test262: test262/test/built-ins/Array/S15.4.3_A2.2.js
1668         https://bugs.webkit.org/show_bug.cgi?id=170652
1669
1670         Reviewed by Michael Saboff.
1671
1672         * runtime/ArrayConstructor.cpp:
1673         (JSC::ArrayConstructor::finishCreation):
1674         * runtime/BooleanConstructor.cpp:
1675         (JSC::BooleanConstructor::finishCreation):
1676         * runtime/DateConstructor.cpp:
1677         (JSC::DateConstructor::finishCreation):
1678         * runtime/FunctionConstructor.cpp:
1679         (JSC::FunctionConstructor::finishCreation):
1680         * runtime/JSArrayBufferConstructor.cpp:
1681         (JSC::JSArrayBufferConstructor::finishCreation):
1682         * runtime/NumberConstructor.cpp:
1683         (JSC::NumberConstructor::finishCreation):
1684         * runtime/ObjectConstructor.cpp:
1685         (JSC::ObjectConstructor::finishCreation):
1686         * runtime/RegExpConstructor.cpp:
1687         (JSC::RegExpConstructor::finishCreation):
1688         * runtime/StringConstructor.cpp:
1689         (JSC::StringConstructor::finishCreation):
1690         * runtime/SymbolConstructor.cpp:
1691         (JSC::SymbolConstructor::finishCreation):
1692         Ensure the "length" property on these native constructors is configurable (deletable).
1693
1694 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1695
1696         Unreviewed, build fix for Windows after r215228 part 2
1697         https://bugs.webkit.org/show_bug.cgi?id=170723
1698
1699         Since GCActivityCallback class is annotated exported, we do not need to annotate each member.
1700
1701         * heap/GCActivityCallback.h:
1702
1703 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1704
1705         [JSC][GTK] Use RunLoop::Timer in GTK port
1706         https://bugs.webkit.org/show_bug.cgi?id=170723
1707
1708         Reviewed by Carlos Garcia Campos.
1709
1710         This patch makes GTK port use RunLoop::Timer for JSRunLoopTimer.
1711         Only Cocoa-based ports use platform-specific Timer because it
1712         has additional feature that changes RunLoop to the WebThread one.
1713
1714         And we enable Heap timers in all the ports including JSCOnly port.
1715
1716         * heap/EdenGCActivityCallback.cpp:
1717         (JSC::EdenGCActivityCallback::lastGCLength):
1718         * heap/EdenGCActivityCallback.h:
1719         * heap/FullGCActivityCallback.cpp:
1720         (JSC::FullGCActivityCallback::lastGCLength):
1721         * heap/FullGCActivityCallback.h:
1722         * heap/GCActivityCallback.cpp:
1723         (JSC::GCActivityCallback::GCActivityCallback):
1724         (JSC::GCActivityCallback::doWork):
1725         (JSC::GCActivityCallback::scheduleTimer):
1726         (JSC::GCActivityCallback::cancelTimer):
1727         (JSC::GCActivityCallback::nextFireTime):
1728         (JSC::GCActivityCallback::didAllocate):
1729         * heap/GCActivityCallback.h:
1730         * heap/IncrementalSweeper.cpp:
1731         (JSC::IncrementalSweeper::doWork):
1732         (JSC::IncrementalSweeper::doSweep):
1733         * heap/IncrementalSweeper.h:
1734         * heap/StopIfNecessaryTimer.cpp:
1735         (JSC::StopIfNecessaryTimer::scheduleSoon):
1736         * runtime/JSRunLoopTimer.cpp:
1737         (JSC::JSRunLoopTimer::setRunLoop):
1738         (JSC::JSRunLoopTimer::scheduleTimer):
1739         (JSC::JSRunLoopTimer::cancelTimer):
1740         (JSC::JSRunLoopTimer::JSRunLoopTimer):
1741         (JSC::JSRunLoopTimer::~JSRunLoopTimer):
1742         (JSC::JSRunLoopTimer::timerDidFireCallback):
1743         * runtime/JSRunLoopTimer.h:
1744         * runtime/PromiseDeferredTimer.cpp:
1745         (JSC::PromiseDeferredTimer::scheduleWorkSoon):
1746
1747 2017-04-11  Guillaume Emont  <guijemont@igalia.com>
1748
1749         [jsc][mips] Add missing MacroAssembler functions after r214187
1750         https://bugs.webkit.org/show_bug.cgi?id=170089
1751
1752         Reviewed by Yusuke Suzuki.
1753
1754         * assembler/MacroAssemblerMIPS.h:
1755         (JSC::MacroAssemblerMIPS::loadFloat): Added.
1756         (JSC::MacroAssemblerMIPS::storeFloat): Added.
1757
1758 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1759
1760         [JSC] Enable JSRunLoopTimer for JSCOnly and Windows
1761         https://bugs.webkit.org/show_bug.cgi?id=170655
1762
1763         Reviewed by Carlos Garcia Campos.
1764
1765         * runtime/JSRunLoopTimer.cpp:
1766         (JSC::JSRunLoopTimer::JSRunLoopTimer):
1767         (JSC::JSRunLoopTimer::scheduleTimer):
1768         (JSC::JSRunLoopTimer::cancelTimer):
1769         * runtime/JSRunLoopTimer.h:
1770
1771 2017-04-10  Alex Christensen  <achristensen@webkit.org>
1772
1773         Revert r215217
1774         https://bugs.webkit.org/show_bug.cgi?id=170703
1775
1776         * Configurations/FeatureDefines.xcconfig:
1777
1778 2017-04-10  Alex Christensen  <achristensen@webkit.org>
1779
1780         Continue enabling WebRTC
1781         https://bugs.webkit.org/show_bug.cgi?id=170703
1782
1783         Reviewed by Youenn Fablet.
1784
1785         * Configurations/FeatureDefines.xcconfig:
1786
1787 2017-04-10  Mark Lam  <mark.lam@apple.com>
1788
1789         Move ProbeContext and ProbeFunction out of AbstractMacroAssembler.
1790         https://bugs.webkit.org/show_bug.cgi?id=170681
1791
1792         Reviewed by Michael Saboff.
1793
1794         This is a refactoring step towards enabling custom probe printers the way printInternal() works for dataLog.
1795
1796         * assembler/AbstractMacroAssembler.h:
1797         (JSC::AbstractMacroAssembler::ProbeContext::gpr): Deleted.
1798         (JSC::AbstractMacroAssembler::ProbeContext::fpr): Deleted.
1799         (JSC::AbstractMacroAssembler::ProbeContext::gprName): Deleted.
1800         (JSC::AbstractMacroAssembler::ProbeContext::fprName): Deleted.
1801         * assembler/MacroAssembler.cpp:
1802         (JSC::stdFunctionCallback):
1803         (JSC::MacroAssembler::probe):
1804         * assembler/MacroAssembler.h:
1805         (JSC::ProbeContext::gpr):
1806         (JSC::ProbeContext::fpr):
1807         (JSC::ProbeContext::gprName):
1808         (JSC::ProbeContext::fprName):
1809         * assembler/MacroAssemblerARM.cpp:
1810         (JSC::MacroAssemblerARM::probe):
1811         * assembler/MacroAssemblerARM64.cpp:
1812         (JSC::arm64ProbeTrampoline):
1813         (JSC::MacroAssemblerARM64::probe):
1814         * assembler/MacroAssemblerARMv7.cpp:
1815         (JSC::MacroAssemblerARMv7::probe):
1816         * assembler/MacroAssemblerPrinter.cpp:
1817         * assembler/MacroAssemblerPrinter.h:
1818         * assembler/MacroAssemblerX86Common.cpp:
1819         (JSC::MacroAssemblerX86Common::probe):
1820         * ftl/FTLLowerDFGToB3.cpp:
1821         (JSC::FTL::DFG::LowerDFGToB3::abstractStructure):
1822         (JSC::FTL::DFG::LowerDFGToB3::probe): Deleted.
1823         - Deleted because this became a useless place-holder after the transition to B3.
1824
1825 2017-04-10  Keith Miller  <keith_miller@apple.com>
1826
1827         WebAssembly: Fix B3IRGenerator for BrTable
1828         https://bugs.webkit.org/show_bug.cgi?id=170685
1829
1830         Reviewed by JF Bastien.
1831
1832         For some reason this didn't get included in r215141.
1833
1834         This fixes an issue with BrTable and loops where we would use the loop's return type
1835         as the branch target type.
1836
1837         * wasm/WasmB3IRGenerator.cpp:
1838         (JSC::Wasm::B3IRGenerator::ControlData::resultForBranch):
1839         (JSC::Wasm::B3IRGenerator::unifyValuesWithBlock):
1840
1841 2017-04-08  Oliver Hunt  <oliver@apple.com>
1842
1843         Remove use of strcpy from JSC
1844         https://bugs.webkit.org/show_bug.cgi?id=170646
1845
1846         Reviewed by Mark Lam.
1847
1848         Replace the use of strcpy with memcpy as strcpy keeps
1849         on tripping various analyser warnings even though its
1850         trivially safe in this case.
1851
1852         Essentially code hygiene, no change in behaviour, no
1853         perf impact.
1854
1855         * dfg/DFGDisassembler.cpp:
1856         (JSC::DFG::Disassembler::dumpDisassembly):
1857
1858 2017-04-09  Joseph Pecoraro  <pecoraro@apple.com>
1859
1860         test262: test262/test/annexB/language/expressions/object/__proto__-fn-name.js
1861         https://bugs.webkit.org/show_bug.cgi?id=170650
1862
1863         Reviewed by Saam Barati.
1864
1865         * parser/Parser.cpp:
1866         (JSC::Parser<LexerType>::parseClass):
1867         (JSC::Parser<LexerType>::parseProperty):
1868         There needs to be special handling of:
1869         
1870           PropertyDefinition :  PropertyName ':' AssignmentExpression
1871          
1872         When the property name is __proto__. In this case the
1873         SetFunctionName path does not happen, so the name "__proto__"
1874         is not inferred on any anonymous function. See:
1875         https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers
1876
1877         * parser/Parser.h:
1878         * parser/SyntaxChecker.h:
1879         (JSC::SyntaxChecker::createProperty):
1880         * parser/ASTBuilder.h:
1881         (JSC::ASTBuilder::createProperty):
1882         Add an extra parameter to see if inferring / setting names are allowed.
1883
1884 2017-04-09  Joseph Pecoraro  <pecoraro@apple.com>
1885
1886         test262: test262/test/annexB/language/literals/regexp/identity-escape.js
1887         https://bugs.webkit.org/show_bug.cgi?id=170651
1888
1889         Reviewed by Saam Barati.
1890
1891         * yarr/YarrParser.h:
1892         (JSC::Yarr::Parser::parseEscape):
1893         For \8 and \9 match just the number "8" or "9" instead of both "\\" and the number.
1894         See: https://tc39.github.io/ecma262/#sec-decimalescape
1895
1896 2017-04-08  Youenn Fablet  <youenn@apple.com>
1897
1898         WebRTC tests gardening
1899         https://bugs.webkit.org/show_bug.cgi?id=170508
1900
1901         Reviewed by Eric Carlson.
1902
1903         * Configurations/FeatureDefines.xcconfig:
1904
1905 2017-04-07  Keith Miller  <keith_miller@apple.com>
1906
1907         WebAssembly: Fix issue with BrTable targeting a Loop
1908         https://bugs.webkit.org/show_bug.cgi?id=170638
1909
1910         Reviewed by Saam Barati.
1911
1912         This fixes the same issue V8 had in: https://github.com/WebAssembly/spec/pull/456#event-1033547537
1913
1914         * wasm/WasmValidate.cpp:
1915         (JSC::Wasm::Validate::ControlData::branchTargetSignature):
1916
1917 2017-04-07  Keith Miller  <keith_miller@apple.com>
1918
1919         Add a PriorityQueue class
1920         https://bugs.webkit.org/show_bug.cgi?id=170579
1921
1922         Reviewed by Saam Barati.
1923
1924         Update Wasm::Worklist to use WTF::PriorityQueue.
1925
1926         * wasm/WasmWorklist.cpp:
1927         (JSC::Wasm::Worklist::enqueue):
1928         (JSC::Wasm::Worklist::completePlanSynchronously):
1929         (JSC::Wasm::Worklist::stopAllPlansForVM):
1930         (JSC::Wasm::Worklist::~Worklist):
1931         (JSC::Wasm::Worklist::iterate): Deleted.
1932         * wasm/WasmWorklist.h:
1933         (JSC::Wasm::Worklist::isHigherPriority):
1934         (JSC::Wasm::Worklist::Comparator::operator()): Deleted.
1935
1936 2017-04-07  Yuichiro Kikura  <y.kikura@gmail.com>
1937
1938         WebGPU: implement ComputeCommandEncoder and related components
1939         https://bugs.webkit.org/show_bug.cgi?id=170444
1940
1941         Reviewed by Alex Christensen.
1942
1943         I added some identifiers related with WebGPUComputeCommandEncoder based on the proposal.
1944         https://webkit.org/wp-content/uploads/webgpu-api-proposal.html
1945
1946         * runtime/CommonIdentifiers.h:
1947
1948 2017-04-07  Saam Barati  <sbarati@apple.com>
1949
1950         WebAssembly: Module::getOrCreateCodeBlock is wrong
1951         https://bugs.webkit.org/show_bug.cgi?id=170612
1952
1953         Reviewed by Keith Miller.
1954
1955         When we were getting a module's CodeBlock, we were checking if !runnable(),
1956         and if !runnable(), we were re-creating the CodeBlock. This is wrong, since
1957         !runnable() is true while the CodeBlock is compiling. Instead, we should check
1958         if we've finished compiling, and if so, if that compilation failed.
1959
1960         * wasm/WasmModule.cpp:
1961         (JSC::Wasm::Module::getOrCreateCodeBlock):
1962
1963 2017-04-07  Saam Barati  <sbarati@apple.com>
1964
1965         WebAssembly: Make to a compilation API that allows for multi-VM concurrent compilations of Wasm Modules
1966         https://bugs.webkit.org/show_bug.cgi?id=170488
1967
1968         Reviewed by JF Bastien.
1969
1970         This patch adds a class called Wasm::Module. It contains the bits from
1971         JSWebAssemblyModule that were not VM specific. JSWebAssemblyModule
1972         now has a Ref<Wasm::Module>. Similarly, there is now a Wasm::CodeBlock,
1973         which owns the non-VM-specific bits that JSWebAssemblyCodeBlock used
1974         to own.
1975         
1976         This patch also simplifies how we verify and compile code. Wasm::Module
1977         now has an API for both sync/async validation and compilation. This
1978         API abstracts away how Wasm::Plan works.
1979         
1980         This is hopefully the last patch needed before we can implement
1981         window.postMessage for a JSWebAssemblyModule. I think all that's
1982         needed now to implement postMessage is simply creating a new
1983         JSWebAssemblyModule with the underlying Wasm::Module.
1984         
1985         This patch is neutral on WasmBench.
1986         
1987         Finally, this patch changes the promise deferred timer to
1988         allow for new tasks to be added while we're executing
1989         a task. Before, we'd deadlock if this happened.
1990
1991         * CMakeLists.txt:
1992         * JavaScriptCore.xcodeproj/project.pbxproj:
1993         * jsc.cpp:
1994         (functionTestWasmModuleFunctions):
1995         * runtime/PromiseDeferredTimer.cpp:
1996         (JSC::PromiseDeferredTimer::doWork):
1997         (JSC::PromiseDeferredTimer::scheduleWorkSoon):
1998         * runtime/PromiseDeferredTimer.h:
1999         * wasm/WasmB3IRGenerator.cpp:
2000         * wasm/WasmBinding.cpp:
2001         (JSC::Wasm::wasmToJs):
2002         (JSC::Wasm::wasmToWasm):
2003         (JSC::Wasm::exitStubGenerator): Deleted.
2004         * wasm/WasmBinding.h:
2005         * wasm/WasmCodeBlock.cpp: Added.
2006         (JSC::Wasm::CodeBlock::CodeBlock):
2007         (JSC::Wasm::CodeBlock::waitUntilFinished):
2008         (JSC::Wasm::CodeBlock::compileAsync):
2009         (JSC::Wasm::CodeBlock::isSafeToRun):
2010         * wasm/WasmCodeBlock.h: Added.
2011         (JSC::Wasm::CodeBlock::create):
2012         (JSC::Wasm::CodeBlock::compilationFinished):
2013         (JSC::Wasm::CodeBlock::runnable):
2014         (JSC::Wasm::CodeBlock::errorMessage):
2015         (JSC::Wasm::CodeBlock::functionImportCount):
2016         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
2017         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
2018         * wasm/WasmModule.cpp: Added.
2019         (JSC::Wasm::Module::Module):
2020         (JSC::Wasm::makeValidationResult):
2021         (JSC::Wasm::Module::validateSyncImpl):
2022         (JSC::Wasm::Module::getOrCreateCodeBlock):
2023         (JSC::Wasm::Module::compileSync):
2024         (JSC::Wasm::Module::makeValidationCallback):
2025         (JSC::Wasm::Module::compileAsync):
2026         * wasm/WasmModule.h: Added.
2027         (JSC::Wasm::Module::create):
2028         (JSC::Wasm::Module::validateSync):
2029         (JSC::Wasm::Module::validateAsync):
2030         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
2031         (JSC::Wasm::Module::moduleInformation):
2032         (JSC::Wasm::Module::nonNullCodeBlock):
2033         * wasm/WasmPlan.cpp:
2034         (JSC::Wasm::Plan::Plan):
2035         (JSC::Wasm::Plan::addCompletionTask):
2036         (JSC::Wasm::Plan::prepare):
2037         (JSC::Wasm::Plan::compileFunctions):
2038         (JSC::Wasm::Plan::complete):
2039         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
2040         (JSC::Wasm::Plan::cancel): Deleted.
2041         * wasm/WasmPlan.h:
2042         (JSC::Wasm::Plan::dontFinalize):
2043         (JSC::Wasm::Plan::takeWasmToWasmExitStubs):
2044         (JSC::Wasm::Plan::mode):
2045         (JSC::Wasm::Plan::takeWasmExitStubs): Deleted.
2046         (JSC::Wasm::Plan::vm): Deleted.
2047         * wasm/WasmWorklist.cpp:
2048         (JSC::Wasm::Worklist::stopAllPlansForVM):
2049         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2050         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
2051         (JSC::JSWebAssemblyCodeBlock::isSafeToRun):
2052         (JSC::JSWebAssemblyCodeBlock::initialize): Deleted.
2053         * wasm/js/JSWebAssemblyCodeBlock.h:
2054         (JSC::JSWebAssemblyCodeBlock::create):
2055         (JSC::JSWebAssemblyCodeBlock::functionImportCount):
2056         (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
2057         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
2058         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
2059         (JSC::JSWebAssemblyCodeBlock::mode): Deleted.
2060         (JSC::JSWebAssemblyCodeBlock::initialized): Deleted.
2061         (JSC::JSWebAssemblyCodeBlock::plan): Deleted.
2062         (JSC::JSWebAssemblyCodeBlock::runnable): Deleted.
2063         (JSC::JSWebAssemblyCodeBlock::errorMessage): Deleted.
2064         (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee): Deleted.
2065         (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee): Deleted.
2066         * wasm/js/JSWebAssemblyInstance.cpp:
2067         (JSC::JSWebAssemblyInstance::finalizeCreation):
2068         (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): Deleted.
2069         * wasm/js/JSWebAssemblyInstance.h:
2070         (JSC::JSWebAssemblyInstance::initialized): Deleted.
2071         * wasm/js/JSWebAssemblyModule.cpp:
2072         (JSC::JSWebAssemblyModule::createStub):
2073         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
2074         (JSC::JSWebAssemblyModule::finishCreation):
2075         * wasm/js/JSWebAssemblyModule.h:
2076         (JSC::JSWebAssemblyModule::moduleInformation):
2077         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
2078         (JSC::JSWebAssemblyModule::module):
2079         * wasm/js/WebAssemblyFunction.cpp:
2080         (JSC::WebAssemblyFunction::create):
2081         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2082         (JSC::constructJSWebAssemblyInstance):
2083         * wasm/js/WebAssemblyModuleConstructor.cpp:
2084         (JSC::WebAssemblyModuleConstructor::createModule):
2085         * wasm/js/WebAssemblyPrototype.cpp:
2086         (JSC::reject):
2087         (JSC::webAssemblyCompileFunc):
2088         (JSC::resolve):
2089         (JSC::instantiate):
2090         (JSC::compileAndInstantiate):
2091         (JSC::webAssemblyValidateFunc):
2092
2093 2017-04-07  Carlos Garcia Campos  <cgarcia@igalia.com>
2094
2095         [GTK] Update the priorities used in glib main loop sources
2096         https://bugs.webkit.org/show_bug.cgi?id=170457
2097
2098         Reviewed by Žan Doberšek.
2099
2100         * runtime/JSRunLoopTimer.cpp:
2101         (JSC::JSRunLoopTimer::JSRunLoopTimer):
2102
2103 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
2104
2105         Rename allocateStack to allocateStackByGraphColoring.
2106
2107         Rubber stamped by Saam Barati.
2108
2109         * CMakeLists.txt:
2110         * JavaScriptCore.xcodeproj/project.pbxproj:
2111         * b3/air/AirAllocateStack.cpp: Removed.
2112         * b3/air/AirAllocateStack.h: Removed.
2113         * b3/air/AirAllocateStackByGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.cpp.
2114         (JSC::B3::Air::allocateStackByGraphColoring):
2115         (JSC::B3::Air::allocateStack): Deleted.
2116         * b3/air/AirAllocateStackByGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.h.
2117         * b3/air/AirGenerate.cpp:
2118         (JSC::B3::Air::prepareForGeneration):
2119
2120 2017-04-06  Michael Saboff  <msaboff@apple.com>
2121
2122         Cannot Object.seal() or Object.freeze() global "this"
2123         https://bugs.webkit.org/show_bug.cgi?id=170549
2124
2125         Reviewed by Mark Lam.
2126
2127         Needed to implement JSProxy::isExtensible() which returns the results of calling
2128         the same on wrapped object.
2129
2130         Implemented step 11 of Runtime Semantics: EvalDeclarationInstantiation from the ECMAScript
2131         spec to properly return a TypeError object when attempting to add properties to a
2132         non-extensible global object.
2133
2134         * interpreter/Interpreter.cpp:
2135         (JSC::Interpreter::execute):
2136         * runtime/JSProxy.cpp:
2137         (JSC::JSProxy::isExtensible):
2138         * runtime/JSProxy.h:
2139
2140 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
2141
2142         Linear scan should run liveness only once
2143         https://bugs.webkit.org/show_bug.cgi?id=170569
2144
2145         Reviewed by Keith Miller.
2146         
2147         Air has a longstanding design bug that Tmps from different banks are indexed independently. This
2148         means that all of our analyses over Tmps do separate GP and FP passes. This does have some
2149         marginal benefits (the rest of the algorithm is specialized for Bank) but it's probably net bad.
2150         However, I don't want to think about solving that general problem.
2151         
2152         Instead, this just makes linear scan use a UnifiedTmpLiveness that uses a single "linear"
2153         indexing for GP and FP. This lets me avoid the much larger refactoring (which would involve
2154         substantial changes in graph coloring) while getting the bulk of the benefit (liveness runs once,
2155         instead of twice, for linear scan).
2156         
2157         This patch implements a lot of plumbing to make it possible for Liveness<> to view Tmps as having
2158         a unified indexing scheme. Tmp calls this LinearlyIndexed (to match the naming convention of
2159         AbsolutelyIndexed and Indexed), while AirLiveness calls this UnifiedTmpLiveness. With this
2160         change, -O1 never does any liveness analysis that uses separate GP and FP passes. I think this
2161         eliminates any urgency from the larger Tmp indexing bug. We can probably live with graph coloring
2162         doing separate passes.
2163         
2164         This is a ~6% speed-up for wasm -O1 compile times. I think this means that linear scan is no
2165         longer the longest pole in the tent.
2166
2167         * JavaScriptCore.xcodeproj/project.pbxproj:
2168         * b3/B3VariableLiveness.h:
2169         (JSC::B3::VariableLivenessAdapter::prepareToCompute):
2170         * b3/air/AirAllocateRegistersByLinearScan.cpp:
2171         (JSC::B3::Air::allocateRegistersByLinearScan):
2172         * b3/air/AirCode.h:
2173         (JSC::B3::Air::Code::forEachTmp):
2174         * b3/air/AirLiveness.h:
2175         * b3/air/AirLivenessAdapter.h:
2176         (JSC::B3::Air::LivenessAdapter::Actions::Actions):
2177         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
2178         (JSC::B3::Air::LivenessAdapter::adapter):
2179         (JSC::B3::Air::LivenessAdapter::prepareToCompute):
2180         (JSC::B3::Air::LivenessAdapter::actionsAt):
2181         (JSC::B3::Air::LivenessAdapter::forEachUse):
2182         (JSC::B3::Air::LivenessAdapter::forEachDef):
2183         (JSC::B3::Air::TmpLivenessAdapter::numIndices):
2184         (JSC::B3::Air::UnifiedTmpLivenessAdapter::UnifiedTmpLivenessAdapter):
2185         (JSC::B3::Air::UnifiedTmpLivenessAdapter::numIndices):
2186         (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsBank):
2187         (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsRole):
2188         (JSC::B3::Air::UnifiedTmpLivenessAdapter::valueToIndex):
2189         (JSC::B3::Air::UnifiedTmpLivenessAdapter::indexToValue):
2190         * b3/air/AirLivenessConstraints.h: Removed.
2191         * b3/air/AirRegLiveness.h:
2192         (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
2193         * b3/air/AirTmp.cpp:
2194         * b3/air/AirTmp.h:
2195         * b3/air/AirTmpInlines.h:
2196         (JSC::B3::Air::Tmp::LinearlyIndexed::LinearlyIndexed):
2197         (JSC::B3::Air::Tmp::LinearlyIndexed::index):
2198         (JSC::B3::Air::Tmp::linearlyIndexed):
2199         (JSC::B3::Air::Tmp::indexEnd):
2200         (JSC::B3::Air::Tmp::absoluteIndexEnd):
2201         (JSC::B3::Air::Tmp::linearIndexEnd):
2202         (JSC::B3::Air::Tmp::tmpForAbsoluteIndex):
2203         (JSC::B3::Air::Tmp::tmpForLinearIndex):
2204         * b3/air/AirTmpMap.h: Added.
2205         (JSC::B3::Air::TmpMap::TmpMap):
2206         (JSC::B3::Air::TmpMap::resize):
2207         (JSC::B3::Air::TmpMap::clear):
2208         (JSC::B3::Air::TmpMap::operator[]):
2209         (JSC::B3::Air::TmpMap::append):
2210
2211 2017-04-06  Ryan Haddad  <ryanhaddad@apple.com>
2212
2213         Unreviewed, rolling out r215046.
2214
2215         This change broke internal builds.
2216
2217         Reverted changeset:
2218
2219         "WebRTC tests gardening"
2220         https://bugs.webkit.org/show_bug.cgi?id=170508
2221         http://trac.webkit.org/changeset/215046
2222
2223 2017-04-06  Joseph Pecoraro  <pecoraro@apple.com>
2224
2225         Web Inspector: Show all headers in the Request Headers section of the Resource details sidebar
2226         https://bugs.webkit.org/show_bug.cgi?id=16531
2227         <rdar://problem/5712895>
2228
2229         Reviewed by Timothy Hatcher.
2230
2231         * inspector/protocol/Network.json:
2232         Optional refined list of request headers in Metrics.
2233
2234 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
2235
2236         B3 -O1 should generate better code than -O0
2237         https://bugs.webkit.org/show_bug.cgi?id=170563
2238
2239         Reviewed by Michael Saboff.
2240         
2241         Prior to this change, code generated by -O1 ran slower than code generated by -O0. This turned
2242         out to be because of reduceStrength optimizations that increase live ranges and create register
2243         pressure, which then creates problems for linear scan.
2244         
2245         It seemed obvious that canonicalizations that help isel, constant folding, and one-for-one
2246         strength reductions should stay. It also seemed obvious that SSA and CFG simplification are fast
2247         and harmless. So, I focused on removing:
2248         
2249         - CSE, which increases live ranges. This is a risky optimization when we know that we've chosen
2250           to use a bad register allocator.
2251         
2252         - Sophisticated strength reductions that create more code, like the insane division optimization.
2253         
2254         - Anything that inserts basic blocks.
2255         
2256         CSE appeared to be the cause of half of the throughput regression of -O1 but none of the compile
2257         time. This change also reduces the running time of reduceStrength by making it not a fixpoint at
2258         optLevel<2.
2259         
2260         This makes wasm -O1 compile 17% faster. This makes wasm -O1 run 19% faster. This makes -O1 code
2261         run 3% faster than -O0, and compile about 4% slower than -O0. We may yet end up choosing to use
2262         -O0, but at least now -O1 isn't totally useless.
2263
2264         * b3/B3ReduceStrength.cpp:
2265
2266 2017-04-06  Jon Davis  <jond@apple.com>
2267
2268         Updates feature status for recently shipped features
2269         https://bugs.webkit.org/show_bug.cgi?id=170359
2270
2271         Reviewed by Brian Burg.
2272
2273         Changed "Done" status to "Supported".
2274
2275         * features.json:
2276
2277 2017-04-06  Youenn Fablet  <youenn@apple.com>
2278
2279         WebRTC tests gardening
2280         https://bugs.webkit.org/show_bug.cgi?id=170508
2281
2282         Reviewed by Eric Carlson.
2283
2284         * Configurations/FeatureDefines.xcconfig:
2285
2286 2017-04-06  Guillaume Emont  <guijemont@igalia.com>
2287
2288         [JSC][MIPS][DFG] Use x86 generic HasOwnProperty
2289         https://bugs.webkit.org/show_bug.cgi?id=170222
2290
2291         Reviewed by Yusuke Suzuki.
2292
2293         * dfg/DFGFixupPhase.cpp:
2294         (JSC::DFG::FixupPhase::fixupNode):
2295         use the X86 special version for HasOwnProperty on MIPS too.
2296         * dfg/DFGSpeculativeJIT32_64.cpp:
2297         (JSC::DFG::SpeculativeJIT::compile):
2298         use the X86 special version for HasOwnProperty on MIPS too.
2299
2300 2017-04-05  Saam Barati  <sbarati@apple.com>
2301
2302         REGRESSION fix bad isWasm() test by ensuring proper Wasm callee bit pattern
2303         https://bugs.webkit.org/show_bug.cgi?id=170494
2304         <rdar://problem/31446485>
2305
2306         Reviewed by Yusuke Suzuki and Mark Lam.
2307
2308         This patch fixes how we test a 64 bit JSValue pattern to see if it's
2309         a Wasm callee. We now tag Wasm::Callee's with 0b011 in their lower 3 bits.
2310         The new test is for a Wasm Callee is as follows:
2311         isWasm(uint64_t x)
2312         {
2313             return x & 0xffff000000000007 == 3;
2314         }
2315         
2316         This test works because the lower 3 bits of the non-number immediate values are as follows:
2317         undefined: 0b010
2318         null:      0b010
2319         true:      0b111
2320         false:     0b110
2321         The test rejects all of these because none have just the value 3 in their lower 3 bits.
2322         The test also rejects all numbers, because they have non-zero upper 16 bits.
2323         The test also rejects normal cells because they won't have the number 3 as
2324         their lower 3 bits. Note, this bit pattern also allows the normal JSValue isCell(), etc,
2325         predicates to work on a Wasm::Callee because the various tests will fail if you
2326         bit casted a boxed Wasm::Callee* to a JSValue. isCell() would fail since it sees
2327         TagBitTypeOther. The other tests also trivially fail, since it won't be a number,
2328         and it won't be equal to null, undefined, true, or false. The isBoolean() predicate
2329         will fail because we won't have TagBitBool set.
2330
2331         * interpreter/CallFrame.h:
2332         (JSC::ExecState::guaranteedJSValueCallee):
2333         (JSC::ExecState::calleeAsValue): Deleted.
2334         * interpreter/CalleeBits.h:
2335         (JSC::CalleeBits::boxWasm):
2336         (JSC::CalleeBits::isWasm):
2337         (JSC::CalleeBits::asWasmCallee):
2338         * jit/JITOperations.cpp:
2339         * runtime/JSCJSValue.h:
2340
2341 2017-04-05  Keith Miller  <keith_miller@apple.com>
2342
2343         WebAssembly: Plans should be able to have more than one completion task.
2344         https://bugs.webkit.org/show_bug.cgi?id=170516
2345
2346         Reviewed by Saam Barati.
2347
2348         This patch also eliminates the need for blocked tasks on the
2349         PromiseDeferredTimer and pendingPromise on Wasm::Plan.
2350
2351         * runtime/PromiseDeferredTimer.cpp:
2352         (JSC::PromiseDeferredTimer::doWork):
2353         (JSC::PromiseDeferredTimer::cancelPendingPromise):
2354         (JSC::PromiseDeferredTimer::scheduleBlockedTask): Deleted.
2355         * runtime/PromiseDeferredTimer.h:
2356         * wasm/WasmPlan.cpp:
2357         (JSC::Wasm::Plan::Plan):
2358         (JSC::Wasm::Plan::addCompletionTask):
2359         (JSC::Wasm::Plan::complete):
2360         * wasm/WasmPlan.h:
2361         (JSC::Wasm::Plan::setMode):
2362         (JSC::Wasm::Plan::mode):
2363         (JSC::Wasm::Plan::setModeAndPromise): Deleted.
2364         (JSC::Wasm::Plan::pendingPromise): Deleted.
2365         * wasm/WasmWorklist.cpp:
2366         (JSC::Wasm::Worklist::enqueue):
2367         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2368         (JSC::constructJSWebAssemblyInstance):
2369         * wasm/js/WebAssemblyPrototype.cpp:
2370         (JSC::instantiate):
2371
2372 2017-04-05  Guilherme Iscaro  <iscaro@profusion.mobi>
2373
2374         Do not use BLX for immediates (ARM-32)
2375
2376         https://bugs.webkit.org/show_bug.cgi?id=170351
2377
2378         Reviewed by Mark Lam.
2379
2380         Currently the offline asm generator for 32-bit ARM code translates the
2381         'call' meta-instruction (which may be found in LowLevelInterpreter.asm
2382         and friends) to the ARM's BLX instrunction. The BLX instruction may be
2383         used for labels (immediates) and registers and one side effect of BLX
2384         is that it may switch the processor's instruction set.
2385         A 'BLX register' instruction will change/remain the processor state to
2386         ARM if the  register_bit[0] is set to 0 or change/remain to Thumb if
2387         register_bit[0] is set to 1. However, a 'BLX label' instruction will
2388         always switch the processor state. It switches ARM to thumb and vice-versa.
2389         This behaviour is unwanted, since the C++ code and the offlineasm generated code
2390         are both compiled using the same instruction set, thus a instruction
2391         set change will likely produce a crash. In order to fix the problem the
2392         BL instruction can be used for labels. It will branch just like BLX,
2393         but it won't change the instruction set. It's important to note that
2394         Darwin is not affected by this problem, thus to minimize the impact of
2395         this change the BL instruction will only be used on non-darwin targets.
2396
2397         BLX reference: http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHBJCDC.html?resultof=%22%62%6c%78%22%20
2398
2399         * offlineasm/arm.rb:
2400
2401 2017-04-05  Keith Miller  <keith_miller@apple.com>
2402
2403         WebAssembly: We shouldn't need to pin size registers if we have a fast memory.
2404         https://bugs.webkit.org/show_bug.cgi?id=170504
2405
2406         Reviewed by Mark Lam.
2407
2408         * wasm/WasmB3IRGenerator.cpp:
2409         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2410         (JSC::Wasm::createJSToWasmWrapper):
2411         (JSC::Wasm::parseAndCompile):
2412         * wasm/WasmMemoryInformation.h:
2413         (JSC::Wasm::PinnedRegisterInfo::toSave):
2414
2415 2017-04-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2416
2417         [JSC] Suppress warnings in GCC
2418         https://bugs.webkit.org/show_bug.cgi?id=170501
2419
2420         Reviewed by Keith Miller.
2421
2422         Should use ASSERT_NOT_REACHED since return-type pragma is only
2423         enabled under ASSERT_DISABLED environment. We shoud use
2424         ASSERT_NOTREACHED to emit assertions in debug build. It effectively
2425         catches bugs while keeping performance in release build.
2426
2427         * b3/B3Opcode.cpp:
2428         (JSC::B3::storeOpcode):
2429         * b3/B3Width.h:
2430         (JSC::B3::mask):
2431         * runtime/Options.cpp:
2432         (JSC::parse):
2433         * wasm/WasmSections.h:
2434         (JSC::Wasm::makeString):
2435         * wasm/WasmSignature.cpp:
2436         (JSC::Wasm::SignatureInformation::tryCleanup):
2437         * wasm/generateWasmValidateInlinesHeader.py:
2438
2439 2017-04-05  Carlos Garcia Campos  <cgarcia@igalia.com>
2440
2441         Implement PromiseDeferredTimer for non CF based ports
2442         https://bugs.webkit.org/show_bug.cgi?id=170391
2443
2444         Reviewed by Yusuke Suzuki.
2445
2446         RunLoop handling is only implemented for CF causing several wasm tests to fail for other ports.
2447
2448         * jsc.cpp:
2449         (runJSC): Remove CF ifdefs.
2450         * runtime/PromiseDeferredTimer.cpp:
2451         (JSC::PromiseDeferredTimer::doWork): Add non CF implementation using WTF RunLoop.
2452         (JSC::PromiseDeferredTimer::runRunLoop): Ditto.
2453         * runtime/PromiseDeferredTimer.h:
2454
2455 2017-04-05  Carlos Garcia Campos  <cgarcia@igalia.com>
2456
2457         WebAssembly: several tests added in r214504 crash when building with GCC
2458         https://bugs.webkit.org/show_bug.cgi?id=170390
2459
2460         Reviewed by Saam Barati.
2461
2462         The pattern foo->bar([f = WTFMove(foo)]{}); crashes when building with GCC, I assume the move happens before the
2463         foo is used to invoke the function.
2464
2465         * wasm/js/WebAssemblyPrototype.cpp:
2466         (JSC::webAssemblyCompileFunc): Use p.vm() instead of plan->vm(), because plan is moved by the lambda.
2467         (JSC::instantiate): Ditto.
2468         (JSC::compileAndInstantiate): Ditto.
2469
2470 2017-03-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2471
2472         [JSC] Generate TemplateObjects at linking time
2473         https://bugs.webkit.org/show_bug.cgi?id=169743
2474
2475         Reviewed by Keith Miller.
2476
2477         Currently, the code calls getTemplateObject to get appropriate template objects at runtime.
2478         But this template object is constant value and never changed. So instead of creating it
2479         at runtime, we should create it at linking time and store it in the constant registers.
2480
2481         * builtins/BuiltinNames.h:
2482         * bytecode/CodeBlock.cpp:
2483         (JSC::CodeBlock::finishCreation):
2484         (JSC::CodeBlock::setConstantRegisters):
2485         * bytecode/CodeBlock.h:
2486         * bytecode/UnlinkedCodeBlock.cpp:
2487         (JSC::UnlinkedCodeBlock::shrinkToFit):
2488         * bytecode/UnlinkedCodeBlock.h:
2489         * bytecompiler/BytecodeGenerator.cpp:
2490         (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
2491         (JSC::BytecodeGenerator::emitGetTemplateObject):
2492         * bytecompiler/BytecodeGenerator.h:
2493         * bytecompiler/NodesCodegen.cpp:
2494         (JSC::TaggedTemplateNode::emitBytecode):
2495         * runtime/JSGlobalObject.cpp:
2496         (JSC::JSGlobalObject::init):
2497         (JSC::getTemplateObject): Deleted.
2498         * runtime/JSTemplateRegistryKey.cpp:
2499         * runtime/JSTemplateRegistryKey.h:
2500         (JSC::isTemplateRegistryKey):
2501
2502 2017-04-04  Mark Lam  <mark.lam@apple.com>
2503
2504         On ARM64, DFG::SpeculativeJIT::compileArithMod() failed to ensure result is of DataFormatInt32.
2505         https://bugs.webkit.org/show_bug.cgi?id=170473
2506         <rdar://problem/29912391>
2507
2508         Reviewed by Saam Barati.
2509
2510         In Unchecked mode, when DFG::SpeculativeJIT::compileArithMod() detects that the
2511         divisor is 0, we want it to return 0.  The result is expected to be of
2512         DataFormatIn32.
2513
2514         The ARM implementation just returns the value in the divisor register.  However,
2515         the divisor in this case can be of DataFormatJSInt32.  On ARM64, returning the
2516         divisor register yields the wrong result format because the same register also
2517         holds the upper 32-bit of the JSValue encoding.  The fix is to return an
2518         immediate 0 instead.
2519
2520         Also turned on the assertion in jitAssertIsInt32 for ARM64.  This assertion being
2521         disabled may have contributed to this bug going unnoticed all this time.
2522
2523         * dfg/DFGSpeculativeJIT.cpp:
2524         (JSC::DFG::SpeculativeJIT::compileArithMod):
2525         * jit/AssemblyHelpers.cpp:
2526         (JSC::AssemblyHelpers::jitAssertIsInt32):
2527
2528 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2529
2530         Air::eliminateDeadCode should not repeatedly process the same live instructions
2531         https://bugs.webkit.org/show_bug.cgi?id=170490
2532
2533         Reviewed by Keith Miller.
2534         
2535         This makes the eliminateDeadCode() fixpoint somewhat worklist-based: we track the set
2536         of Insts that might be dead. Every time we detect that one is live, we remove it from
2537         the set. This is a big (>2x) speed-up because lots of Insts are immediately found to
2538         be live.
2539         
2540         This is a ~1% wasm -O1 compile time progression.
2541
2542         * b3/air/AirEliminateDeadCode.cpp:
2543         (JSC::B3::Air::eliminateDeadCode):
2544
2545 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2546
2547         Air::eliminateDeadCode() should not use a HashSet
2548         https://bugs.webkit.org/show_bug.cgi?id=170487
2549
2550         Reviewed by Saam Barati.
2551         
2552         Introduce TmpSet, which is like a HashSet<Tmp>. Use this to make eliminateDeadCode()
2553         about 50% faster, resulting in a 1% wasm -O1 compile time progression.
2554
2555         * JavaScriptCore.xcodeproj/project.pbxproj:
2556         * b3/air/AirEliminateDeadCode.cpp:
2557         (JSC::B3::Air::eliminateDeadCode):
2558         * b3/air/AirTmpSet.h: Added.
2559         (JSC::B3::Air::TmpSet::TmpSet):
2560         (JSC::B3::Air::TmpSet::add):
2561         (JSC::B3::Air::TmpSet::remove):
2562         (JSC::B3::Air::TmpSet::contains):
2563         (JSC::B3::Air::TmpSet::size):
2564         (JSC::B3::Air::TmpSet::isEmpty):
2565         (JSC::B3::Air::TmpSet::iterator::iterator):
2566         (JSC::B3::Air::TmpSet::iterator::operator*):
2567         (JSC::B3::Air::TmpSet::iterator::operator++):
2568         (JSC::B3::Air::TmpSet::iterator::operator==):
2569         (JSC::B3::Air::TmpSet::iterator::operator!=):
2570         (JSC::B3::Air::TmpSet::begin):
2571         (JSC::B3::Air::TmpSet::end):
2572
2573 2017-04-04  Keith Miller  <keith_miller@apple.com>
2574
2575         WebAssembly: ModuleInformation should be a ref counted thing that can be shared across threads.
2576         https://bugs.webkit.org/show_bug.cgi?id=170478
2577
2578         Reviewed by Saam Barati.
2579
2580         ModuleInformation has been moved to its own file and is now
2581         ThreadSafeRefCounted.  All the Strings we used to keep in the
2582         ModuleInformation have been switched to Vector<LChar> this has the
2583         advantage that it can be passed across threads. However, this does
2584         mean that we need to decode the utf8 strings in each thread. This
2585         is likely not a problem because:
2586
2587         1) most modules have few imports/exports/custom sections.
2588         2) most of the time they are ascii so the conversion is cheap.
2589         3) we only have to do it once per thread, and there shouldn't be too many.
2590
2591         This patch also removes
2592         moduleSignatureIndicesToUniquedSignatureIndices since that
2593         information can already be recovered from the
2594         SignatureInformation.
2595
2596         * JavaScriptCore.xcodeproj/project.pbxproj:
2597         * jsc.cpp:
2598         (functionTestWasmModuleFunctions):
2599         * runtime/Identifier.h:
2600         (JSC::Identifier::fromString):
2601         * wasm/WasmB3IRGenerator.cpp:
2602         (JSC::Wasm::parseAndCompile):
2603         * wasm/WasmB3IRGenerator.h:
2604         * wasm/WasmFormat.cpp:
2605         (JSC::Wasm::makeString):
2606         (JSC::Wasm::ModuleInformation::~ModuleInformation): Deleted.
2607         * wasm/WasmFormat.h:
2608         (JSC::Wasm::makeString):
2609         (JSC::Wasm::ModuleInformation::functionIndexSpaceSize): Deleted.
2610         (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace): Deleted.
2611         (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace): Deleted.
2612         (JSC::Wasm::ModuleInformation::importFunctionCount): Deleted.
2613         (JSC::Wasm::ModuleInformation::internalFunctionCount): Deleted.
2614         * wasm/WasmFunctionParser.h:
2615         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
2616         * wasm/WasmModuleInformation.cpp: Copied from Source/JavaScriptCore/wasm/WasmValidate.h.
2617         (JSC::Wasm::ModuleInformation::~ModuleInformation):
2618         * wasm/WasmModuleInformation.h: Added.
2619         (JSC::Wasm::ModuleInformation::functionIndexSpaceSize):
2620         (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace):
2621         (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace):
2622         (JSC::Wasm::ModuleInformation::importFunctionCount):
2623         (JSC::Wasm::ModuleInformation::internalFunctionCount):
2624         (JSC::Wasm::ModuleInformation::ModuleInformation):
2625         * wasm/WasmModuleParser.cpp:
2626         * wasm/WasmModuleParser.h:
2627         (JSC::Wasm::ModuleParser::ModuleParser):
2628         * wasm/WasmParser.h:
2629         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
2630         * wasm/WasmPlan.cpp:
2631         (JSC::Wasm::Plan::Plan):
2632         (JSC::Wasm::Plan::parseAndValidateModule):
2633         (JSC::Wasm::Plan::prepare):
2634         (JSC::Wasm::Plan::compileFunctions):
2635         (JSC::Wasm::Plan::complete):
2636         (JSC::Wasm::Plan::cancel):
2637         * wasm/WasmPlan.h:
2638         (JSC::Wasm::Plan::internalFunctionCount):
2639         (JSC::Wasm::Plan::takeModuleInformation):
2640         * wasm/WasmSignature.cpp:
2641         (JSC::Wasm::SignatureInformation::get):
2642         * wasm/WasmSignature.h:
2643         * wasm/WasmValidate.cpp:
2644         (JSC::Wasm::validateFunction):
2645         * wasm/WasmValidate.h:
2646         * wasm/js/JSWebAssemblyHelpers.h:
2647         (JSC::createSourceBufferFromValue):
2648         * wasm/js/JSWebAssemblyModule.cpp:
2649         (JSC::JSWebAssemblyModule::createStub):
2650         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
2651         (JSC::JSWebAssemblyModule::finishCreation):
2652         * wasm/js/JSWebAssemblyModule.h:
2653         (JSC::JSWebAssemblyModule::moduleInformation):
2654         (JSC::JSWebAssemblyModule::source):
2655         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2656         (JSC::constructJSWebAssemblyInstance):
2657         * wasm/js/WebAssemblyModuleConstructor.cpp:
2658         (JSC::WebAssemblyModuleConstructor::createModule):
2659         * wasm/js/WebAssemblyModulePrototype.cpp:
2660         (JSC::webAssemblyModuleProtoCustomSections):
2661         (JSC::webAssemblyModuleProtoImports):
2662         (JSC::webAssemblyModuleProtoExports):
2663         * wasm/js/WebAssemblyModuleRecord.cpp:
2664         (JSC::WebAssemblyModuleRecord::link):
2665         * wasm/js/WebAssemblyModuleRecord.h:
2666         * wasm/js/WebAssemblyPrototype.cpp:
2667         (JSC::webAssemblyCompileFunc):
2668         (JSC::instantiate):
2669         (JSC::compileAndInstantiate):
2670
2671 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2672
2673         B3::fixSSA() needs a tune-up
2674         https://bugs.webkit.org/show_bug.cgi?id=170485
2675
2676         Reviewed by Saam Barati.
2677         
2678         After the various optimizations to liveness, register allocation, and other phases, the
2679         fixSSA() phase now looks like one of the top offenders. This includes a bunch of
2680         changes to make this phase run faster. This is a ~7% wasm -O1 compile time progression.
2681         
2682         Here's what I did:
2683         
2684         - We now use IndexSparseSet instead of IndexMap for tracking variable values. This
2685           makes it cheaper to chew through small blocks while there is a non-trivial number of
2686           total variables.
2687         
2688         - We now do a "local SSA conversion" pass before anything else. This eliminates
2689           obvious Get's. If we were using temporary Variables, it would eliminate many of
2690           those. That's useful for when we use demoteValues() and duplciateTails(). For wasm
2691           -O1, we mainly care about the fact that it makes a bunch of Set's dead.
2692         
2693         - We now do a Set DCE pass after the local SSA but before SSA conversion. This ensures
2694           that any block-local live intervals of Variables disappear and don't need further
2695           consideration.
2696         
2697         - We now cache the reaching defs calculation.
2698         
2699         - We now perform the reaching defs calculation lazily.
2700
2701         * b3/B3FixSSA.cpp:
2702         (JSC::B3::demoteValues):
2703         (JSC::B3::fixSSA):
2704         * b3/B3SSACalculator.cpp:
2705         (JSC::B3::SSACalculator::reachingDefAtTail):
2706         * b3/B3VariableLiveness.cpp:
2707         (JSC::B3::VariableLiveness::VariableLiveness):
2708         * b3/air/AirLiveness.h:
2709         (JSC::B3::Air::Liveness::Liveness):
2710         * dfg/DFGLivenessAnalysisPhase.cpp:
2711         (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase): Deleted.
2712         (JSC::DFG::LivenessAnalysisPhase::run): Deleted.
2713         (JSC::DFG::LivenessAnalysisPhase::processBlock): Deleted.
2714
2715 2017-04-04  Joseph Pecoraro  <pecoraro@apple.com>
2716
2717         Remove stale LLVM Header Path includes from JavaScriptCore
2718         https://bugs.webkit.org/show_bug.cgi?id=170483
2719
2720         Reviewed by Mark Lam.
2721
2722         * Configurations/Base.xcconfig:
2723
2724 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2725
2726         B3::LowerToAir incorrectly selects BitXor(AtomicStrongCAS(...), $1)
2727         https://bugs.webkit.org/show_bug.cgi?id=169867
2728
2729         Reviewed by Saam Barati.
2730         
2731         The BitXor(AtomicWeakCAS(...), $1) optimization makes a lot of sense because we an fold the
2732         BitXor into the CAS condition read-out. But there is no version of this that is profitable or
2733         correct for AtomicStrongCAS. The inversion case is handled by Equal(AtomicStrongCAS(...), ...)
2734         becoming NotEqual(AtomicStrongCAS(...), ...), and we alraedy handle that separately.
2735         
2736         So, the fix here is to make the BitXor CAS pattern only recognize AtomicWeakCAS.
2737
2738         * b3/B3LowerToAir.cpp:
2739         (JSC::B3::Air::LowerToAir::lower):
2740         * b3/testb3.cpp:
2741         (JSC::B3::testAtomicStrongCAS):
2742
2743 2017-04-04  Saam Barati  <sbarati@apple.com>
2744
2745         WebAssembly: JSWebAssemblyCallee should not be a JSCell
2746         https://bugs.webkit.org/show_bug.cgi?id=170135
2747
2748         Reviewed by Michael Saboff.
2749
2750         This patch is perhaps the last big change to the design of fundamental
2751         Wasm API to allow for PIC. It changes JSWebAssemblyCallee into a thing
2752         called Wasm::Callee. It serves the same purpose as before, except
2753         Wasm::Callee is not a JSCell. I had to refactor the various parts of the
2754         runtime that will see CallFrame's with Wasm::Callee's in the callee slot.
2755         Thankfully, the parts of the runtime that Wasm touches are limited. The
2756         main refactoring is changing the exception handling code, such as taking
2757         a stack trace, to be friendly to seeing a non JSCell callee.
2758         
2759         The callee() function on ExecState now returns a class I added in this
2760         patch called CalleeBits. CalleeBits will tell you if the callee is a
2761         JSCell or a Wasm::Callee. We tag Wasm::Callee's with a 1 in their lower
2762         bit so we can easily tell what is and isn't a Wasm::Callee.
2763         
2764         The stub that calls out from Wasm to JS still puts a JSCell callee
2765         into the call frame, even though the callee logically represents a
2766         Wasm frame. The reason for this is that we use the call IC infrastructure
2767         to make a call out to JS code, and the code that writes the IC expects
2768         a JSCell as the callee. This is knowingly part of our design. When we
2769         do structured cloning of Wasm Modules, we'll need to regenerate these
2770         JS call stubs.
2771
2772         * API/JSContextRef.cpp:
2773         (BacktraceFunctor::operator()):
2774         * CMakeLists.txt:
2775         * JavaScriptCore.xcodeproj/project.pbxproj:
2776         * debugger/Debugger.cpp:
2777         (JSC::Debugger::pauseIfNeeded):
2778         (JSC::Debugger::currentDebuggerCallFrame):
2779         * debugger/DebuggerCallFrame.cpp:
2780         (JSC::DebuggerCallFrame::create):
2781         (JSC::DebuggerCallFrame::DebuggerCallFrame):
2782         (JSC::DebuggerCallFrame::currentPosition):
2783         (JSC::DebuggerCallFrame::positionForCallFrame):
2784         * debugger/DebuggerCallFrame.h:
2785         * interpreter/CallFrame.cpp:
2786         (JSC::CallFrame::vmEntryGlobalObject):
2787         (JSC::CallFrame::wasmAwareLexicalGlobalObject):
2788         (JSC::CallFrame::isAnyWasmCallee):
2789         (JSC::CallFrame::callerSourceOrigin):
2790         * interpreter/CallFrame.h:
2791         (JSC::ExecState::calleeAsValue):
2792         (JSC::ExecState::jsCallee):
2793         (JSC::ExecState::callee):
2794         (JSC::ExecState::unsafeCallee):
2795         (JSC::ExecState::scope):
2796         (JSC::ExecState::iterate):
2797         * interpreter/CalleeBits.h: Added.
2798         (JSC::CalleeBits::CalleeBits):
2799         (JSC::CalleeBits::operator=):
2800         (JSC::CalleeBits::boxWasm):
2801         (JSC::CalleeBits::isWasm):
2802         (JSC::CalleeBits::isCell):
2803         (JSC::CalleeBits::asCell):
2804         (JSC::CalleeBits::asWasmCallee):
2805         (JSC::CalleeBits::rawPtr):
2806         * interpreter/Interpreter.cpp:
2807         (JSC::GetStackTraceFunctor::operator()):
2808         (JSC::Interpreter::getStackTrace):
2809         (JSC::notifyDebuggerOfUnwinding):
2810         (JSC::UnwindFunctor::UnwindFunctor):
2811         (JSC::UnwindFunctor::operator()):
2812         (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2813         (JSC::Interpreter::unwind):
2814         (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
2815         * interpreter/Interpreter.h:
2816         * interpreter/Register.h:
2817         (JSC::Register::pointer):
2818         * interpreter/ShadowChicken.cpp:
2819         (JSC::ShadowChicken::update):
2820         * interpreter/ShadowChickenInlines.h:
2821         (JSC::ShadowChicken::iterate):
2822         * interpreter/StackVisitor.cpp:
2823         (JSC::StackVisitor::StackVisitor):
2824         (JSC::StackVisitor::readFrame):
2825         (JSC::StackVisitor::readNonInlinedFrame):
2826         (JSC::StackVisitor::readInlinedFrame):
2827         (JSC::StackVisitor::Frame::calleeSaveRegisters):
2828         (JSC::StackVisitor::Frame::functionName):
2829         (JSC::StackVisitor::Frame::dump):
2830         * interpreter/StackVisitor.h:
2831         (JSC::StackVisitor::Frame::callee):
2832         (JSC::StackVisitor::visit):
2833         * jit/Repatch.cpp:
2834         (JSC::linkFor):
2835         (JSC::linkPolymorphicCall):
2836         * jsc.cpp:
2837         (callWasmFunction):
2838         (functionTestWasmModuleFunctions):
2839         * runtime/ArrayPrototype.cpp:
2840         * runtime/Error.cpp:
2841         (JSC::addErrorInfoAndGetBytecodeOffset):
2842         * runtime/ErrorInstance.cpp:
2843         (JSC::ErrorInstance::finishCreation):
2844         * runtime/JSCell.cpp:
2845         (JSC::JSCell::isAnyWasmCallee): Deleted.
2846         * runtime/JSCell.h:
2847         * runtime/JSCellInlines.h:
2848         (JSC::ExecState::vm):
2849         * runtime/JSFunction.cpp:
2850         (JSC::RetrieveArgumentsFunctor::operator()):
2851         (JSC::RetrieveCallerFunctionFunctor::operator()):
2852         * runtime/JSGlobalObject.cpp:
2853         * runtime/SamplingProfiler.cpp:
2854         (JSC::FrameWalker::recordJSFrame):
2855         (JSC::SamplingProfiler::processUnverifiedStackTraces):
2856         * runtime/SamplingProfiler.h:
2857         (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
2858         * runtime/StackFrame.cpp:
2859         (JSC::StackFrame::sourceURL):
2860         (JSC::StackFrame::functionName):
2861         * runtime/StackFrame.h:
2862         (JSC::StackFrame::wasm):
2863         * runtime/VM.cpp:
2864         (JSC::VM::VM):
2865         (JSC::VM::throwException):
2866         * runtime/VM.h:
2867         * wasm/JSWebAssembly.h:
2868         * wasm/WasmB3IRGenerator.cpp:
2869         * wasm/WasmBinding.cpp:
2870         (JSC::Wasm::wasmToWasm):
2871         * wasm/WasmCallee.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp.
2872         (JSC::Wasm::Callee::Callee):
2873         (JSC::JSWebAssemblyCallee::JSWebAssemblyCallee): Deleted.
2874         (JSC::JSWebAssemblyCallee::finishCreation): Deleted.
2875         (JSC::JSWebAssemblyCallee::destroy): Deleted.
2876         * wasm/WasmCallee.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.h.
2877         (JSC::Wasm::Callee::create):
2878         (JSC::JSWebAssemblyCallee::create): Deleted.
2879         (JSC::JSWebAssemblyCallee::createStructure): Deleted.
2880         (JSC::JSWebAssemblyCallee::entrypoint): Deleted.
2881         (JSC::JSWebAssemblyCallee::calleeSaveRegisters): Deleted.
2882         * wasm/WasmContext.h:
2883         * wasm/WasmPlan.cpp:
2884         * wasm/WasmPlan.h:
2885         * wasm/WasmPlanInlines.h:
2886         (JSC::Wasm::Plan::initializeCallees):
2887         * wasm/WasmThunks.cpp:
2888         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
2889         * wasm/js/JSWebAssemblyCallee.cpp: Removed.
2890         * wasm/js/JSWebAssemblyCallee.h: Removed.
2891         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2892         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
2893         (JSC::JSWebAssemblyCodeBlock::initialize):
2894         (JSC::JSWebAssemblyCodeBlock::visitChildren):
2895         * wasm/js/JSWebAssemblyCodeBlock.h:
2896         (JSC::JSWebAssemblyCodeBlock::create):
2897         (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
2898         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
2899         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
2900         (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub):
2901         (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee):
2902         (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee):
2903         (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
2904         (JSC::JSWebAssemblyCodeBlock::allocationSize):
2905         (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub):
2906         (JSC::JSWebAssemblyCodeBlock::callees): Deleted.
2907         (JSC::JSWebAssemblyCodeBlock::offsetOfCallees): Deleted.
2908         * wasm/js/JSWebAssemblyInstance.h:
2909         (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
2910         * wasm/js/JSWebAssemblyModule.cpp:
2911         * wasm/js/WebAssemblyFunction.cpp:
2912         (JSC::callWebAssemblyFunction):
2913         (JSC::WebAssemblyFunction::create):
2914         (JSC::WebAssemblyFunction::WebAssemblyFunction):
2915         (JSC::WebAssemblyFunction::visitChildren):
2916         (JSC::WebAssemblyFunction::finishCreation):
2917         * wasm/js/WebAssemblyFunction.h:
2918         (JSC::WebAssemblyFunction::wasmEntrypoint):
2919         (JSC::WebAssemblyFunction::jsEntrypoint):
2920         (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint):
2921         (JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode): Deleted.
2922         * wasm/js/WebAssemblyModuleConstructor.cpp:
2923         * wasm/js/WebAssemblyModuleRecord.cpp:
2924         (JSC::WebAssemblyModuleRecord::link):
2925         (JSC::WebAssemblyModuleRecord::evaluate):
2926
2927 2017-04-04  Keith Miller  <keith_miller@apple.com>
2928
2929         WasmBench asserts in debug jsc
2930         https://bugs.webkit.org/show_bug.cgi?id=170462
2931
2932         Reviewed by Saam Barati.
2933
2934         The assertion should have been an if.
2935
2936         * wasm/WasmWorklist.cpp:
2937
2938 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2939
2940         Air::lowerAfterRegAlloc should bail early if it finds no Shuffles or ColdCCalls
2941         https://bugs.webkit.org/show_bug.cgi?id=170305
2942
2943         Reviewed by Saam Barati.
2944         
2945         This reduces and sometimes completely eliminates the need to run lowerAfterRegAlloc().
2946         
2947         This lowers the Shuffle for the arguments of a CCall before register allocation unless
2948         the CCall arguments require a real shuffle (like if the CCall arguments were argument
2949         registers). This lowers a ColdCCall like a CCall for optLevel<2.
2950         
2951         Finally, lowerAfterRegAlloc() now checks if there are any Shuffles or CCalls before it
2952         does anything else. For wasm at -O1, this means that the phase doesn't run at all. This
2953         is a ~3% wasm -O1 compile time progression.
2954         
2955         To make this easy, I changed optLevel into a property of Procedure and Code rather than
2956         an argument we thread through everything. I like how Procedure and Code are dumping
2957         ground classes. This does not bother me. Note that I cloned optLevel into Procedure and
2958         Code so that it's cheap to query inside Air phases.
2959
2960         * b3/B3Compile.cpp:
2961         (JSC::B3::compile):
2962         * b3/B3Compile.h:
2963         * b3/B3Generate.cpp:
2964         (JSC::B3::prepareForGeneration):
2965         (JSC::B3::generateToAir):
2966         * b3/B3Generate.h:
2967         * b3/B3Procedure.cpp:
2968         (JSC::B3::Procedure::setOptLevel):
2969         * b3/B3Procedure.h:
2970         (JSC::B3::Procedure::optLevel):
2971         * b3/air/AirCode.h:
2972         (JSC::B3::Air::Code::isPinned):
2973         (JSC::B3::Air::Code::setOptLevel):
2974         (JSC::B3::Air::Code::optLevel):
2975         * b3/air/AirEmitShuffle.cpp:
2976         (JSC::B3::Air::ShufflePair::bank):
2977         (JSC::B3::Air::ShufflePair::opcode):
2978         (JSC::B3::Air::ShufflePair::inst):
2979         (JSC::B3::Air::emitShuffle):
2980         * b3/air/AirEmitShuffle.h:
2981         (JSC::B3::Air::moveFor):
2982         * b3/air/AirGenerate.cpp:
2983         (JSC::B3::Air::prepareForGeneration):
2984         * b3/air/AirGenerate.h:
2985         * b3/air/AirLowerAfterRegAlloc.cpp:
2986         (JSC::B3::Air::lowerAfterRegAlloc):
2987         * b3/air/AirLowerMacros.cpp:
2988         (JSC::B3::Air::lowerMacros):
2989         * b3/testb3.cpp:
2990         (JSC::B3::compileProc):
2991         * wasm/WasmB3IRGenerator.cpp:
2992         (JSC::Wasm::parseAndCompile):
2993
2994 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2995
2996         Don't need to Air::reportUsedRegisters for wasm at -O1
2997         https://bugs.webkit.org/show_bug.cgi?id=170459
2998
2999         Reviewed by Saam Barati.
3000         
3001         I did some refactorings to Liveness<> to try to understand its performance. Based on
3002         this I concluded that the bigger immediate issue is just removing unnecessary phases
3003         from -O1.
3004         
3005         This removes Air::reportUsedRegisters() from -O1 if the user has indicated that he is
3006         not interested in StackmapGenerationParams::usedRegisters(). The logic here is a bit
3007         weird because of how Air does spill code generation. The register allocator's spiller
3008         will emit spill code using identifiable spill slots, which allows subsequent phases to
3009         register-allocate the spill slots. We do this by a forward flow CSE phase called
3010         fixObviousSpills (which is a terrible name since there is no longer anything obvious
3011         about some of the spills that this phase can fix!). As is most natural for CSEs over
3012         3AC, it rewires the uses of redundant computations rather than removing the redundant
3013         computations. This means that if a spill got "fixed", there may be either or both of
3014         the following:
3015         
3016         - Dead loads from the stack.
3017         - Dead stores to the stack.
3018         
3019         We know that a load from the stack is dead if the register is dead at the point of the
3020         load. We know that a store to the stack is dead if the spill slot is dead at the point
3021         of the store.
3022         
3023         Unfortunately, liveness analysis - over either registers or spill slots - is expensive.
3024         
3025         Fortunately, allocateStack() already does liveness analysis over spill slots. So, we
3026         baked elimination of stores to the stack into that phase. That aspect of clean-up after
3027         the spill CSE comes for free.
3028         
3029         Also fortunately for the FTL, we have to do reportUsedRegisters() anyway. This is a
3030         phase that enables StackmapGenerationParams::usedRegisters() to work, which then
3031         enables the FTL's patchpoints to do crazy slow-path live range splitting. So, Air's
3032         strategy for the load fix-up after spill CSE is to do it as part of
3033         reportUsedRegisters().
3034         
3035         This patch introduces the Procedure::setNeedsUsedRegisters() API. But if you set
3036         needsUsedRegisters to false then we will still run reportUsedRegisters() at -O2 as an
3037         optimization - it removes dead loads from the stack that are left behind from
3038         fixObviousSpills().
3039         
3040         This is a ~6% compile time progression at -O1.
3041
3042         * b3/B3Procedure.h:
3043         (JSC::B3::Procedure::setNeedsUsedRegisters):
3044         (JSC::B3::Procedure::needsUsedRegisters):
3045         * b3/B3StackmapGenerationParams.h:
3046         * b3/B3VariableLiveness.cpp:
3047         (JSC::B3::VariableLiveness::VariableLiveness):
3048         * b3/air/AirCode.cpp:
3049         (JSC::B3::Air::Code::needsUsedRegisters):
3050         * b3/air/AirCode.h:
3051         * b3/air/AirGenerate.cpp:
3052         (JSC::B3::Air::prepareForGeneration):
3053         * b3/air/AirLiveness.h:
3054         (JSC::B3::Air::Liveness::Liveness):
3055         * wasm/WasmB3IRGenerator.cpp:
3056         (JSC::Wasm::parseAndCompile):
3057
3058 2017-04-03  Filip Pizlo  <fpizlo@apple.com>
3059
3060         Air liveness should build constraints and solve them rather than repeatedly parsing IR
3061         https://bugs.webkit.org/show_bug.cgi?id=170421
3062
3063         Reviewed by Saam Barati.
3064         
3065         Inst::forEach<> is expensive. The LivenessAdapter uses forEach with a particularly
3066         gnarly lambda that has many extra checks. Therefore, a lot of the time spent in
3067         liveness analysis is just recomputing forEach<> and that lambda to get uses and defs.
3068         
3069         This introduces LivenessConstraints<>, which is a liveness constraint system based on
3070         Adapter. It basically caches the results of doing forEach. It'll give you the uses and
3071         defs at each instruction boundary.
3072         
3073         This is a ~5% compile time progression at optLevel=1. It's also a ~3% compile time
3074         progression at optLevel=2.
3075         
3076         * JavaScriptCore.xcodeproj/project.pbxproj:
3077         * b3/air/AirLivenessAdapter.h:
3078         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
3079         (JSC::B3::Air::LivenessAdapter::forEachUse):
3080         (JSC::B3::Air::LivenessAdapter::forEachDef):
3081         * b3/air/AirLivenessConstraints.h: Added.
3082         (JSC::B3::Air::LivenessConstraints::Actions::Actions):
3083         (JSC::B3::Air::LivenessConstraints::LivenessConstraints):
3084         (JSC::B3::Air::LivenessConstraints::at):
3085
3086 2017-04-03  Mark Lam  <mark.lam@apple.com>
3087
3088         Fix incorrect capacity delta calculation reported in SparseArrayValueMap::add().
3089         https://bugs.webkit.org/show_bug.cgi?id=170412
3090         <rdar://problem/29697336>
3091
3092         Reviewed by Filip Pizlo.
3093
3094         Here's an example of code that will trigger underflow in the "deprecatedExtraMemory"
3095         reported by SparseArrayValueMap::add() that is added to Heap::m_deprecatedExtraMemorySize:
3096         
3097             arr = new Array;
3098             Object.defineProperty(arr, 18, ({writable: true, configurable: true}));
3099             for (var i = 0; i < 3; ++i) {
3100                 Array.prototype.push.apply(arr, ["", () => {}, {}]);
3101                 Array.prototype.sort.apply(arr, [() => {}, []]);
3102             }
3103
3104         However, Heap::m_deprecatedExtraMemorySize is only 1 of 3 values that are added
3105         up to form the result of Heap::extraMemorySize().  Heap::m_extraMemorySize and
3106         Heap::m_arrayBuffers.size() are the other 2.
3107
3108         While Heap::m_arrayBuffers.size() is bounded by actual allocated memory, both
3109         Heap::m_deprecatedExtraMemorySize and Heap::m_extraMemorySize are added to
3110         without any bounds checks, and they are only reset to 0 at the start of a full
3111         GC.  As a result, if we have a long sequence of eden GCs with a lot of additions
3112         to Heap::m_extraMemorySize and/or Heap::m_deprecatedExtraMemorySize, then these
3113         values could theoretically overflow.  Coupling this with the underflow from
3114         SparseArrayValueMap::add(), the result for Heap::extraMemorySize() can easily
3115         overflow.  Note: Heap::extraMemorySize() is used to compute the value
3116         currentHeapSize.
3117
3118         If multiple conditions line up just right, the above overflows can result in this
3119         debug assertion failure during an eden GC:
3120
3121             ASSERT(currentHeapSize >= m_sizeAfterLastCollect);
3122
3123         Otherwise, the effects of the overflows will only result in the computed
3124         currentHeapSize not being representative of actual memory usage, and therefore,
3125         a full GC may be triggered earlier or later than is ideal.
3126
3127         This patch ensures that SparseArrayValueMap::add() cannot underflow
3128         Heap::m_deprecatedExtraMemorySize.  It also adds overflows checks in the
3129         calculations of Heap::m_deprecatedExtraMemorySize, Heap::m_extraMemorySize, and
3130         Heap::extraMemorySize() so that their values are saturated appropriately to
3131         ensure that GC collections are triggered based on representative memory usage.
3132
3133         * heap/Heap.cpp:
3134         (JSC::Heap::deprecatedReportExtraMemorySlowCase):
3135         (JSC::Heap::extraMemorySize):
3136         (JSC::Heap::updateAllocationLimits):
3137         (JSC::Heap::reportExtraMemoryVisited):
3138         * runtime/SparseArrayValueMap.cpp:
3139         (JSC::SparseArrayValueMap::add):
3140
3141 2017-04-03  Filip Pizlo  <fpizlo@apple.com>
3142
3143         Move the Liveness<> adapters from AirLiveness.h to AirLivenessAdapter.h.
3144
3145         Rubber stamped by Keith Miller.
3146         
3147         This will make it easier to write other code that uses those adapters.
3148
3149         * JavaScriptCore.xcodeproj/project.pbxproj:
3150         * b3/air/AirLiveness.h:
3151         (JSC::B3::Air::LivenessAdapter::LivenessAdapter): Deleted.
3152         (JSC::B3::Air::LivenessAdapter::blockSize): Deleted.
3153         (JSC::B3::Air::LivenessAdapter::forEachUse): Deleted.
3154         (JSC::B3::Air::LivenessAdapter::forEachDef): Deleted.
3155         (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter): Deleted.
3156         (JSC::B3::Air::TmpLivenessAdapter::numIndices): Deleted.
3157         (JSC::B3::Air::TmpLivenessAdapter::acceptsBank): Deleted.
3158         (JSC::B3::Air::TmpLivenessAdapter::acceptsRole): Deleted.
3159         (JSC::B3::Air::TmpLivenessAdapter::valueToIndex): Deleted.
3160         (JSC::B3::Air::TmpLivenessAdapter::indexToValue): Deleted.
3161         (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter): Deleted.
3162         (JSC::B3::Air::StackSlotLivenessAdapter::numIndices): Deleted.
3163         (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank): Deleted.
3164         (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole): Deleted.
3165         (JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex): Deleted.
3166         (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue): Deleted.
3167         * b3/air/AirLivenessAdapter.h: Added.
3168         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
3169         (JSC::B3::Air::LivenessAdapter::blockSize):
3170         (JSC::B3::Air::LivenessAdapter::forEachUse):
3171         (JSC::B3::Air::LivenessAdapter::forEachDef):
3172         (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter):
3173         (JSC::B3::Air::TmpLivenessAdapter::numIndices):
3174         (JSC::B3::Air::TmpLivenessAdapter::acceptsBank):
3175         (JSC::B3::Air::TmpLivenessAdapter::acceptsRole):
3176         (JSC::B3::Air::TmpLivenessAdapter::valueToIndex):
3177         (JSC::B3::Air::TmpLivenessAdapter::indexToValue):
3178         (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter):
3179         (JSC::B3::Air::StackSlotLivenessAdapter::numIndices):
3180         (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank):
3181         (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole):
3182         (JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex):
3183         (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue):
3184
3185 2017-04-03  Filip Pizlo  <fpizlo@apple.com>
3186
3187         WTF::Liveness should have an API that focuses on actions at instruction boundaries
3188         https://bugs.webkit.org/show_bug.cgi?id=170407
3189
3190         Reviewed by Keith Miller.
3191         
3192         Adopt changes to the WTF::Liveness<> API. Instead of having separate functions for the
3193         early/late versions of uses and defs, we now have just a use/def API. Those
3194         automatically take care of eary/late issues as needed.
3195         
3196         This reduces the API surface between WTF::Liveness<> and its clients, which makes it
3197         easier to implement some other optimizations I'm thinking about.
3198
3199         * b3/B3VariableLiveness.h:
3200         (JSC::B3::VariableLivenessAdapter::forEachUse):
3201         (JSC::B3::VariableLivenessAdapter::forEachDef):
3202         (JSC::B3::VariableLivenessAdapter::forEachEarlyUse): Deleted.
3203         (JSC::B3::VariableLivenessAdapter::forEachLateUse): Deleted.
3204         (JSC::B3::VariableLivenessAdapter::forEachEarlyDef): Deleted.
3205         (JSC::B3::VariableLivenessAdapter::forEachLateDef): Deleted.
3206         * b3/air/AirLiveness.h:
3207         (JSC::B3::Air::LivenessAdapter::blockSize):
3208         (JSC::B3::Air::LivenessAdapter::forEachUse):
3209         (JSC::B3::Air::LivenessAdapter::forEachDef):
3210         (JSC::B3::Air::LivenessAdapter::forEachEarlyUse): Deleted.
3211         (JSC::B3::Air::LivenessAdapter::forEachLateUse): Deleted.
3212         (JSC::B3::Air::LivenessAdapter::forEachEarlyDef): Deleted.
3213         (JSC::B3::Air::LivenessAdapter::forEachLateDef): Deleted.
3214
3215 2017-04-03  Filip Pizlo  <fpizlo@apple.com>
3216
3217         Inst::forEachArg could compile to more compact code
3218         https://bugs.webkit.org/show_bug.cgi?id=170406
3219
3220         Reviewed by Sam Weinig.
3221         
3222         Prior to this change, Inst::forEachArg compiled to a ginormous ALWAYS_INLINE switch statement.
3223         It had one case for each opcode, and then each of those cases would have a switch statement over
3224         the number of operands. Then the cases of that switch statement would have a sequence of calls to
3225         the passed lambda. This meant that every user of forEachArg would generate an insane amount of
3226         code. It also meant that the inlining achieved nothing, since the lambda would surely then not
3227         be inlined - and if it was, then the icache pressure due to code bloat would surely negate any
3228         benefits.
3229         
3230         This replaces that code with a loop over a compact look-up table. We use the opcode and number of
3231         operands as keys into that look-up table. The table only takes about 20KB. It has one byte for
3232         each argument in each overload of each opcode.
3233         
3234         I can't measure any reproducible change in performance, but the JavaScriptCore framework binary
3235         shrinks by 2.7 MB. This is a 15% reduction in JavaScriptCore binary size.
3236
3237         * JavaScriptCore.xcodeproj/project.pbxproj:
3238         * b3/B3Width.h:
3239         * b3/air/AirCustom.h:
3240         (JSC::B3::Air::PatchCustom::forEachArg):
3241         * b3/air/AirFormTable.h: Added.
3242         (JSC::B3::Air::decodeFormRole):
3243         (JSC::B3::Air::decodeFormBank):
3244         (JSC::B3::Air::decodeFormWidth):
3245         * b3/air/AirInst.h:
3246         * b3/air/opcode_generator.rb:
3247
3248 2017-04-03  Keith Miller  <keith_miller@apple.com>
3249
3250         WebAssembly: remove lastAllocatedMode from Memory
3251         https://bugs.webkit.org/show_bug.cgi?id=170405
3252
3253         Reviewed by Mark Lam.
3254
3255         It's not used anymore so there isn't any point in keeping it around.
3256
3257         * wasm/WasmMemory.cpp:
3258         (JSC::Wasm::Memory::createImpl):
3259         (JSC::Wasm::Memory::lastAllocatedMode): Deleted.
3260         * wasm/WasmMemory.h:
3261
3262 2017-04-03  Zan Dobersek  <zdobersek@igalia.com>
3263
3264         [jsc] Add patchableJumpSize() for MIPS
3265         https://bugs.webkit.org/show_bug.cgi?id=169716
3266
3267         Reviewed by Yusuke Suzuki.
3268
3269         * assembler/MIPSAssembler.h:
3270         (JSC::MIPSAssembler::patchableJumpSize): Added.
3271         * assembler/MacroAssemblerMIPS.h:
3272         (JSC::MacroAssemblerMIPS::patchableJumpSize): Added.
3273
3274 2017-04-03  Guillaume Emont  <guijemont@igalia.com>
3275
3276         [jsc] implement MIPSAssembler::relinkJumpToNop()
3277         https://bugs.webkit.org/show_bug.cgi?id=169720
3278
3279         Reviewed by Yusuke Suzuki.
3280
3281         * assembler/MIPSAssembler.h:
3282         (JSC::MIPSAssembler::relinkJumpToNop): Added.
3283
3284 2017-04-02  Carlos Garcia Campos  <cgarcia@igalia.com>
3285
3286         Share implementation of JSRunLoopTimer::timerDidFire
3287         https://bugs.webkit.org/show_bug.cgi?id=170392
3288
3289         Reviewed by Michael Catanzaro.
3290
3291         The code is cross-platform but it's duplicated in CF and GLib implementations, it could be shared instead.
3292
3293         * runtime/JSRunLoopTimer.cpp:
3294         (JSC::JSRunLoopTimer::timerDidFire): Move common implementation here.
3295         (JSC::JSRunLoopTimer::setRunLoop): Use timerDidFireCallback.
3296         (JSC::JSRunLoopTimer::timerDidFireCallback): Call JSRunLoopTimer::timerDidFire().
3297         * runtime/JSRunLoopTimer.h:
3298
3299 2017-04-01  Oleksandr Skachkov  <gskachkov@gmail.com>
3300
3301         Object with numerical keys with gaps gets filled by NaN values
3302         https://bugs.webkit.org/show_bug.cgi?id=164412
3303
3304         Reviewed by Mark Lam.
3305
3306         This patch fixes issue when object have two properties 
3307         with name as number. The issue appears when during invoking 
3308         convertDoubleToArrayStorage, array is filled by pNaN and 
3309         method converting it to real NaN. This happeneds because a 
3310         pNaN in a Double array is a hole, and Double arrays cannot 
3311         have NaN values. To fix issue we need to check value and 
3312         clear it if it pNaN.
3313
3314         * runtime/JSObject.cpp:
3315         (JSC::JSObject::convertDoubleToArrayStorage):
3316
3317 2017-03-31  Saam Barati  <sbarati@apple.com>
3318
3319         WebAssembly: Make our calls out to JS PIC friendly
3320         https://bugs.webkit.org/show_bug.cgi?id=170261
3321
3322         Reviewed by Keith Miller.
3323
3324         This patch removes a direct call from the module to the Wasm to JS stub.
3325         Instead, we do an indirect call to the stub by loading the stub's executable
3326         address off of the CodeBlock. This is to make the code we emit for comply with
3327         requirements needed for PIC.
3328         
3329         Adding this indirection is not ideal. Although this patch is neutral on
3330         WasmBench, we really want to get back to a world where we have an IC
3331         call infrastructure. This patch is obviously a regression on some
3332         types of programs. I've filed this bug to make sure we implement a
3333         PIC compliant Wasm to JS call IC:
3334         https://bugs.webkit.org/show_bug.cgi?id=170375
3335
3336         * wasm/WasmB3IRGenerator.cpp:
3337         * wasm/WasmFormat.h:
3338         * wasm/WasmPlan.cpp:
3339         (JSC::Wasm::Plan::complete):
3340         * wasm/js/JSWebAssemblyCodeBlock.cpp:
3341         (JSC::JSWebAssemblyCodeBlock::initialize):
3342         * wasm/js/JSWebAssemblyCodeBlock.h:
3343         (JSC::JSWebAssemblyCodeBlock::create):
3344         (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub):
3345         (JSC::JSWebAssemblyCodeBlock::offsetOfCallees):
3346         (JSC::JSWebAssemblyCodeBlock::allocationSize):
3347         (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub):
3348         * wasm/js/JSWebAssemblyInstance.cpp:
3349         (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock):
3350         * wasm/js/JSWebAssemblyInstance.h:
3351         (JSC::JSWebAssemblyInstance::offsetOfCodeBlock):
3352
3353 2017-03-31  Keith Miller  <keith_miller@apple.com>
3354
3355         WebAssembly: webAssemblyB3OptimizationLevel should use defaultB3OptLevel by default
3356         https://bugs.webkit.org/show_bug.cgi?id=170378
3357
3358         Reviewed by Saam Barati.
3359
3360         * runtime/Options.h:
3361         * wasm/WasmB3IRGenerator.h:
3362
3363 2017-03-31  Keith Miller  <keith_miller@apple.com>
3364
3365         WebAssembly: Add compilation level option
3366         https://bugs.webkit.org/show_bug.cgi?id=170374
3367
3368         Reviewed by Mark Lam.
3369
3370         This patch adds an option, webAssemblyB3OptimizationLevel, which
3371         changes the optimization mode wasm passes to B3.
3372
3373         * runtime/Options.h:
3374         * wasm/WasmPlan.cpp:
3375         (JSC::Wasm::Plan::compileFunctions):
3376
3377 2017-03-31  Saam Barati  <sbarati@apple.com>
3378
3379         WebAssembly: Strip WasmParser and WasmFunctionParser from knowing about VM
3380         https://bugs.webkit.org/show_bug.cgi?id=170312
3381
3382         Reviewed by Mark Lam.
3383
3384         This is another step towards PIC-ifying Wasm. This patch removes
3385         the VM field that is no longer used.
3386
3387         * wasm/WasmB3IRGenerator.cpp:
3388         (JSC::Wasm::parseAndCompile):
3389         * wasm/WasmB3IRGenerator.h:
3390         * wasm/WasmFunctionParser.h:
3391         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
3392         * wasm/WasmModuleParser.h:
3393         (JSC::Wasm::ModuleParser::ModuleParser):
3394         * wasm/WasmParser.h:
3395         (JSC::Wasm::Parser<SuccessType>::Parser):
3396         * wasm/WasmPlan.cpp:
3397         (JSC::Wasm::Plan::parseAndValidateModule):
3398         (JSC::Wasm::Plan::compileFunctions):
3399         * wasm/WasmValidate.cpp:
3400         (JSC::Wasm::validateFunction):
3401         * wasm/WasmValidate.h:
3402
3403 2017-03-31  Saam Barati  <sbarati@apple.com>
3404
3405         WebAssembly: Ref count Signature and SignatureInformation should not care about VM
3406         https://bugs.webkit.org/show_bug.cgi?id=170316
3407
3408         Reviewed by Keith Miller.
3409
3410         This is yet again another step towards PIC-ifying Wasm.
3411         Signature should be ref counted so we can tell when
3412         no code is holding onto a Signature. This makes it easy
3413         to free unused Signatures. Also, this patch rids SignatureInfo
3414         of any VM knowledge. Now, there is just a single SignatureInfo that
3415         lives in a process.
3416
3417         * runtime/VM.h:
3418         * wasm/WasmB3IRGenerator.cpp:
3419         (JSC::Wasm::createJSToWasmWrapper):
3420         (JSC::Wasm::parseAndCompile):
3421         * wasm/WasmB3IRGenerator.h:
3422         * wasm/WasmBinding.cpp:
3423         (JSC::Wasm::wasmToJs):