a7e4c9af17582137a2f1904e25dbb2a99acab8af
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-04-25  Saam Barati  <sbarati@apple.com>
2
3         JSArray::isArrayPrototypeIteratorProtocolFastAndNonObservable is wrong because it does not do the necessary checks on the base object
4         https://bugs.webkit.org/show_bug.cgi?id=171150
5         <rdar://problem/31771880>
6
7         Reviewed by Sam Weinig.
8
9         This patch fixes a huge oversight from the patch that introduced
10         op_spread/Spread. The original patch did not account for the
11         base object having Symbol.iterator or getters that could
12         change the iterator protocol. This patch fixes the oversight both
13         in the C code, as well as the DFG/FTL backends. We only perform
14         the memcpy version of spread if we've proven that it's guaranteed
15         to be side-effect free (no indexed getters), and if the iterator
16         protocol is guaranteed to be the original protocol. To do this, we
17         must prove that:
18         1. The protocol on Array.prototype hasn't changed (this is the same as the
19         introductory patch for op_spread).
20         2. The base object's __proto__ is Array.prototype
21         3. The base object does not have indexed getters
22         4. The base object does not have Symbol.iterator property.
23
24         * dfg/DFGGraph.cpp:
25         (JSC::DFG::Graph::canDoFastSpread):
26         * dfg/DFGGraph.h:
27         * dfg/DFGSpeculativeJIT.cpp:
28         (JSC::DFG::SpeculativeJIT::compileSpread):
29         * ftl/FTLLowerDFGToB3.cpp:
30         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
31         * runtime/JSArray.cpp:
32         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
33         * runtime/JSArray.h:
34         * runtime/JSArrayInlines.h:
35         (JSC::JSArray::isIteratorProtocolFastAndNonObservable): Deleted.
36         * runtime/JSGlobalObject.h:
37         * runtime/JSGlobalObjectInlines.h:
38         (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
39         (JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable): Deleted.
40
41 2017-04-25  Mark Lam  <mark.lam@apple.com>
42
43         Array.prototype.slice() should ensure that end >= begin.
44         https://bugs.webkit.org/show_bug.cgi?id=170989
45         <rdar://problem/31705652>
46
47         Reviewed by Saam Barati.
48
49         * runtime/ArrayPrototype.cpp:
50         (JSC::arrayProtoFuncSlice):
51
52 2017-04-25  Don Olmstead  <don.olmstead@am.sony.com>
53
54         [Win] Use Clang's __has_declspec_attribute for export macros
55         https://bugs.webkit.org/show_bug.cgi?id=171240
56
57         Reviewed by Alex Christensen.
58
59         * runtime/JSExportMacros.h:
60
61 2017-04-25  Saam Barati  <sbarati@apple.com>
62
63         Unreviewed. Attempt armv7k build fix after r215720
64
65         I think we're just missing an include for the definition of ExecState::r().
66
67         * runtime/JSFixedArray.cpp:
68
69 2017-04-25  Daniel Bates  <dabates@apple.com>
70
71         [Cocoa][Win] Enable of X-Content-Type-Options: nosniff header
72         https://bugs.webkit.org/show_bug.cgi?id=136452
73         <rdar://problem/23412620>
74
75         Reviewed by Brent Fulgham.
76
77         Enable X-Content-Type-Options: nosniff on Mac, iOS and Windows platforms.
78
79         * Configurations/FeatureDefines.xcconfig:
80
81 2017-04-25  Mark Lam  <mark.lam@apple.com>
82
83         Local CSE wrongly CSEs array accesses with different result types.
84         https://bugs.webkit.org/show_bug.cgi?id=170990
85         <rdar://problem/31705945>
86
87         Reviewed by Saam Barati.
88
89         The fix is to use different LocationKind enums for the different type of array
90         result types.  This makes the HeapLocation values different based on the result
91         types, and allows CSE to discern between them.
92
93         * dfg/DFGCSEPhase.cpp:
94         * dfg/DFGClobberize.h:
95         (JSC::DFG::clobberize):
96         * dfg/DFGHeapLocation.cpp:
97         (WTF::printInternal):
98         * dfg/DFGHeapLocation.h:
99         (JSC::DFG::indexedPropertyLocForResultType):
100
101 2017-04-25  Mark Lam  <mark.lam@apple.com>
102
103         Make DFG SpeculatedType dumps easier to read.
104         https://bugs.webkit.org/show_bug.cgi?id=171280
105
106         Reviewed by Saam Barati.
107
108         Adding a pretty printer to insert |s between each type string and changing the
109         dumped strings to match the SpeculatedType names case-wise.
110
111         * bytecode/SpeculatedType.cpp:
112         (JSC::PrettyPrinter::PrettyPrinter):
113         (JSC::PrettyPrinter::print):
114         (JSC::dumpSpeculation):
115         * bytecode/SpeculatedType.h:
116
117 2017-04-25  JF Bastien  <jfbastien@apple.com>
118
119         lowerStackArgs: check Arg::addr.isValidForm when falling back to SP offsets
120         https://bugs.webkit.org/show_bug.cgi?id=171278
121
122         Reviewed by Filip Pizlo.
123
124         lowerStackArgs checked that the FP offsets it tries to generate
125         are valid form, but didn't check that the fallback was valid
126         form. This lead to stackAddr's assertion being dead, and the
127         MaroAssembler asserting way later on move / add when handed a huge
128         immediate.
129
130         * b3/air/AirArg.cpp:
131         (JSC::B3::Air::Arg::stackAddrImpl):
132
133 2017-04-25  Zan Dobersek  <zdobersek@igalia.com>
134
135         [aarch64] moveConditionally32(), moveConditionallyTest32() should move from/to 64-bit registers
136         https://bugs.webkit.org/show_bug.cgi?id=170891
137
138         Reviewed by Saam Barati.
139
140         moveConditionally32() and moveConditionallyTest32() operations in
141         MacroAssemblerARM64 properly perform comparisons and tests on 32-bit
142         values, but end up performing the moves from and to 32-bit registers.
143
144         Move operations should instead be done on 64-bit registers, just like
145         on the X86_64 platform. This is achieved by specifying 64 as the data
146         size for the csel instructions.
147
148         * assembler/MacroAssemblerARM64.h:
149         (JSC::MacroAssemblerARM64::moveConditionally32):
150         (JSC::MacroAssemblerARM64::moveConditionallyTest32):
151
152 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
153
154         test262: test262/test/language/expressions/object/method-definition/early-errors-object-method-duplicate-parameters.js
155         https://bugs.webkit.org/show_bug.cgi?id=171190
156
157         Reviewed by Saam Barati.
158
159         * bytecompiler/BytecodeGenerator.cpp:
160         (JSC::BytecodeGenerator::BytecodeGenerator):
161         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
162         (JSC::BytecodeGenerator::emitNewFunction):
163         * bytecompiler/NodesCodegen.cpp:
164         (JSC::FunctionNode::emitBytecode):
165         (JSC::Scope::setSourceParseMode):
166         * parser/ParserModes.h:
167         (JSC::isFunctionParseMode):
168         (JSC::isMethodParseMode):
169         (JSC::isGeneratorOrAsyncFunctionWrapperParseMode):
170         (JSC::isGeneratorParseMode):
171         (JSC::isGeneratorWrapperParseMode):
172         * runtime/FunctionExecutable.h:
173         * runtime/JSFunction.cpp:
174         (JSC::JSFunction::getOwnPropertySlot):
175         Add a new GeneratorWrapperMethodMode parse mode. The other function types
176         (async, arrow) already have a FunctionMode and a MethodMode. Give
177         generators one as well. This lets isMethodParseMode actually be accurate.
178
179         * parser/Parser.cpp:
180         (JSC::Parser<LexerType>::parseInner):
181         (JSC::Parser<LexerType>::isArrowFunctionParameters):
182         (JSC::Parser<LexerType>::parseFormalParameters):
183         (JSC::stringForFunctionMode):
184         (JSC::Parser<LexerType>::parseFunctionParameters):
185         (JSC::Parser<LexerType>::parseFunctionInfo):
186         (JSC::Parser<LexerType>::parseClass):
187         (JSC::Parser<LexerType>::parsePropertyMethod):
188         * parser/Parser.h:
189         Add a duplicate parameter failure if there are duplicate parameters
190         in method syntax.
191
192 2017-04-24  Andy VanWagoner  <thetalecrafter@gmail.com>
193
194         Clean up ICU headers
195         https://bugs.webkit.org/show_bug.cgi?id=170997
196
197         Reviewed by JF Bastien.
198
199         Update all icu headers to 55.1
200
201         * icu/LICENSE: Update copyright
202         * icu/README: Explain ICU headers for OS X better
203         * icu/unicode/localpointer.h:
204         (LocalPointer::LocalPointer):
205         (LocalPointer::adoptInsteadAndCheckErrorCode):
206         * icu/unicode/platform.h:
207         * icu/unicode/putil.h:
208         * icu/unicode/ucal.h:
209         * icu/unicode/uchar.h:
210         * icu/unicode/ucnv.h:
211         * icu/unicode/ucol.h:
212         * icu/unicode/uconfig.h:
213         * icu/unicode/ucurr.h:
214         * icu/unicode/udatpg.h:
215         * icu/unicode/udisplaycontext.h:
216         * icu/unicode/uformattable.h:
217         * icu/unicode/uloc.h:
218         * icu/unicode/umachine.h:
219         * icu/unicode/unum.h:
220         * icu/unicode/unumsys.h:
221         * icu/unicode/urename.h:
222         * icu/unicode/uscript.h:
223         * icu/unicode/uset.h:
224         * icu/unicode/ustring.h:
225         * icu/unicode/utf8.h:
226         * icu/unicode/utypes.h:
227
228 2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
229
230         [JSC] Use JSFixedArray directly when using call_varargs
231         https://bugs.webkit.org/show_bug.cgi?id=171057
232
233         Reviewed by Saam Barati.
234
235         Previously we always emit new_array_with_spread when calling call(...args).
236         But this array is unnecessary if varargs operation can handle Spread directly.
237
238         This patch implements a peep-hole optimization in the bytecode compiler layer
239         to omit new_array_with_spread. This is very simple and effective because this
240         peep-hole optimization is quite common when using (...args) style calls and
241         this optimization works all the tiers. While we can implement the phase to
242         omit this NewArrayWithSpread in argument elimination phase, it only works
243         for FTL. While such an optimization can work with complex data flow, this
244         peep-hole optimization can optimize a common case easily.
245
246         For now, Spread and PhantomSpread can be directly drained by CallVarargs
247         and LoadVarargs related operations. We modify DFG and FTL to handle this correctly.
248
249         This shows six-speed improvement.
250
251             spread.es6                 89.4300+-2.0236     ^     69.6015+-1.7278        ^ definitely 1.2849x faster
252             spread-generator.es6      344.7879+-5.9147     ^    331.2712+-6.8610        ^ definitely 1.0408x faster
253
254         * bytecompiler/BytecodeGenerator.cpp:
255         (JSC::BytecodeGenerator::emitCall):
256         (JSC::BytecodeGenerator::emitConstruct):
257         * dfg/DFGArgumentsEliminationPhase.cpp:
258         * dfg/DFGPreciseLocalClobberize.h:
259         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
260         * ftl/FTLLowerDFGToB3.cpp:
261         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
262         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
263         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
264         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
265         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
266         * interpreter/Interpreter.cpp:
267         (JSC::sizeOfVarargs):
268         (JSC::loadVarargs):
269         * parser/Nodes.h:
270         (JSC::ArrayNode::elements):
271         * runtime/JSFixedArray.cpp:
272         (JSC::JSFixedArray::copyToArguments):
273         * runtime/JSFixedArray.h:
274
275 2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
276
277         [WTF] Move JSC tools/StackTrace to WTF and unify stack trace dump code
278         https://bugs.webkit.org/show_bug.cgi?id=171199
279
280         Reviewed by Mark Lam.
281
282         This patch adds a utility method to produce demangled names with dladdr.
283         It fixes several memory leaks because the result of abi::__cxa_demangle()
284         needs to be `free`-ed.
285
286         * CMakeLists.txt:
287         * JavaScriptCore.xcodeproj/project.pbxproj:
288         * inspector/JSGlobalObjectInspectorController.cpp:
289         (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
290         * runtime/SamplingProfiler.cpp:
291         (JSC::SamplingProfiler::StackFrame::displayName):
292         * tools/CellProfile.h:
293         * tools/CodeProfile.cpp:
294         (JSC::CodeProfile::report):
295         (JSC::symbolName): Deleted.
296
297 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
298
299         Web Inspector: ObjC RWIProtocol codegen should better handle optional members
300         https://bugs.webkit.org/show_bug.cgi?id=171251
301         <rdar://problem/31697002>
302
303         Reviewed by Brian Burg.
304
305         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
306         (ObjCProtocolTypesImplementationGenerator._generate_getter_for_member):
307         * inspector/scripts/codegen/objc_generator.py:
308         (ObjCGenerator.protocol_to_objc_expression_for_member):
309         (ObjCGenerator.protocol_to_objc_code_block_for_object_member):
310         Always be safe and nil check object property accesses, optional or not.
311
312         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
313         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
314         Rebaselined inspector generator tests.
315
316 2017-04-24  Saam Barati  <sbarati@apple.com>
317
318         ASSERTION FAILED: m_table seen with workers/wasm-hashset LayoutTests
319         https://bugs.webkit.org/show_bug.cgi?id=171119
320         <rdar://problem/31760635>
321
322         Reviewed by Keith Miller.
323
324         The HashSet of timer set notification callbacks can be accessed
325         and augmented simultaneously from different threads. e.g, the worker
326         thread can augment it while the wasm compilation thread will
327         access it. Therefore, accesses must be guarded by a lock.
328
329         * runtime/JSRunLoopTimer.cpp:
330         (JSC::JSRunLoopTimer::scheduleTimer):
331         (JSC::JSRunLoopTimer::addTimerSetNotification):
332         (JSC::JSRunLoopTimer::removeTimerSetNotification):
333         * runtime/JSRunLoopTimer.h:
334
335 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
336
337         test262: test262/test/language/computed-property-names/class/static/getter-prototype.js
338         https://bugs.webkit.org/show_bug.cgi?id=170897
339
340         Reviewed by Saam Barati.
341
342         * parser/ASTBuilder.h:
343         (JSC::ASTBuilder::createArguments):
344         (JSC::ASTBuilder::createArgumentsList):
345         Reorder so all the createProperty methods are grouped together.
346
347         * parser/Parser.h:
348         * parser/Parser.cpp:
349         (JSC::Parser<LexerType>::parseClass):
350         (JSC::Parser<LexerType>::parseProperty):
351         (JSC::Parser<LexerType>::parseGetterSetter):
352         Refine the conditions for syntax errors for getter/setter
353         properties names. "prototype" is not allowed as a static
354         and "constructor" is not all when non-static.
355
356         * runtime/JSObject.cpp:
357         (JSC::JSObject::putGetter):
358         (JSC::JSObject::putSetter):
359         Throw exceptions. These methods are only used by this path
360         via op_put_getter_by_val / op_put_setter_by_val.
361
362 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
363
364         test262: test262/test/language/statements/for-of/dstr-array-elem-init-fn-name-arrow.js
365         https://bugs.webkit.org/show_bug.cgi?id=171160
366
367         Reviewed by JF Bastien.
368
369         * parser/ASTBuilder.h:
370         (JSC::ASTBuilder::tryInferNameInPattern):
371         (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
372         We supported getting the name from a BindingNode.
373         We extend this to support getting the name from a
374         ResolveNode inside of an AssignmentElementNode.
375
376         * parser/Nodes.h:
377         (JSC::DestructuringPatternNode::isAssignmentElementNode):
378         (JSC::AssignmentElementNode::isAssignmentElementNode):
379         Make it possible to identify an assignment element node.
380
381 2017-04-24  Alex Christensen  <achristensen@webkit.org>
382
383         Reduce copies and allocations in SharedBuffer::append
384         https://bugs.webkit.org/show_bug.cgi?id=170956
385
386         Reviewed by Andreas Kling.
387
388         * runtime/ArrayBuffer.h:
389
390 2017-04-24  Carlos Garcia Campos  <cgarcia@igalia.com>
391
392         [GTK] Switch to use ENABLE_REMOTE_INSPECTOR instead of ENABLE_INSPECTOR_SERVER for the remote inspector
393         https://bugs.webkit.org/show_bug.cgi?id=166680
394
395         Reviewed by Michael Catanzaro.
396
397         Add GTK+ port implementation of RemoteInspector.
398
399         * PlatformGTK.cmake:
400         * inspector/remote/RemoteConnectionToTarget.h:
401         * inspector/remote/RemoteInspector.h:
402         * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: Added.
403         (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget):
404         (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget):
405         (Inspector::RemoteConnectionToTarget::setup):
406         (Inspector::RemoteConnectionToTarget::sendMessageToTarget):
407         (Inspector::RemoteConnectionToTarget::close):
408         (Inspector::RemoteConnectionToTarget::targetClosed):
409         (Inspector::RemoteConnectionToTarget::targetIdentifier):
410         (Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
411         * inspector/remote/glib/RemoteInspectorGlib.cpp: Added.
412         (Inspector::RemoteInspector::singleton):
413         (Inspector::RemoteInspector::RemoteInspector):
414         (Inspector::RemoteInspector::start):
415         (Inspector::RemoteInspector::stopInternal):
416         (Inspector::RemoteInspector::setupConnection):
417         (Inspector::dbusConnectionCallAsyncReadyCallback):
418         (Inspector::RemoteInspector::listingForInspectionTarget):
419         (Inspector::RemoteInspector::listingForAutomationTarget):
420         (Inspector::RemoteInspector::pushListingsNow):
421         (Inspector::RemoteInspector::pushListingsSoon):
422         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
423         (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage):
424         (Inspector::RemoteInspector::sendMessageToRemote):
425         (Inspector::RemoteInspector::receivedGetTargetListMessage):
426         (Inspector::RemoteInspector::receivedSetupMessage):
427         (Inspector::RemoteInspector::receivedDataMessage):
428         (Inspector::RemoteInspector::receivedCloseMessage):
429         (Inspector::RemoteInspector::setup):
430         (Inspector::RemoteInspector::sendMessageToTarget):
431         (Inspector::RemoteInspector::requestAutomationSession):
432         * inspector/remote/glib/RemoteInspectorServer.cpp: Added.
433         (Inspector::generateConnectionID):
434         (Inspector::RemoteInspectorServer::singleton):
435         (Inspector::RemoteInspectorServer::~RemoteInspectorServer):
436         (Inspector::RemoteInspectorServer::interfaceInfo):
437         (Inspector::RemoteInspectorServer::start):
438         (Inspector::RemoteInspectorServer::newConnectionCallback):
439         (Inspector::RemoteInspectorServer::connectionClosedCallback):
440         (Inspector::RemoteInspectorServer::newConnection):
441         (Inspector::dbusConnectionCallAsyncReadyCallback):
442         (Inspector::RemoteInspectorServer::setTargetList):
443         (Inspector::RemoteInspectorServer::clientConnectionClosedCallback):
444         (Inspector::RemoteInspectorServer::getTargetList):
445         (Inspector::RemoteInspectorServer::setup):
446         (Inspector::RemoteInspectorServer::close):
447         (Inspector::RemoteInspectorServer::clientConnectionClosed):
448         (Inspector::RemoteInspectorServer::connectionClosed):
449         (Inspector::RemoteInspectorServer::sendMessageToBackend):
450         (Inspector::RemoteInspectorServer::sendMessageToFrontend):
451         (Inspector::RemoteInspectorServer::startAutomationSession):
452         * inspector/remote/glib/RemoteInspectorServer.h: Added.
453         (Inspector::RemoteInspectorServer::isRunning):
454
455 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
456
457         test262: test262/test/language/expressions/generators/yield-as-label.js
458         https://bugs.webkit.org/show_bug.cgi?id=170979
459
460         Reviewed by Saam Barati.
461
462         * parser/Parser.cpp:
463         (JSC::Parser<LexerType>::parseVariableDeclarationList):
464         (JSC::Parser<LexerType>::parseDestructuringPattern):
465         (JSC::Parser<LexerType>::parseFormalParameters):
466         Converge on "Cannot" instead of "Can't" in error messages.
467
468         (JSC::Parser<LexerType>::parseFunctionInfo):
469         Disallow "yield" as the generator function name in function expressions.
470         This refers to the difference between Declaration and Expression, where
471         only GeneratorExpression explicitly has [+Yield] disallowing yield for
472         the generator name:
473
474             GeneratorDeclaration[Yield, Await, Default]:
475                 function * BindingIdentifier[?Yield, ?Await] ...
476
477             GeneratorExpression:
478                 function * BindingIdentifier[+Yield, ~Await]opt ...
479
480         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
481         Disallow "yield" as a label name in strict mode or inside a generator.
482
483         (JSC::Parser<LexerType>::parseProperty):
484         Disallow "yield" or any keyword in object literal shorthands.
485
486         * parser/Parser.h:
487         (JSC::Parser::getToken):
488         (JSC::Parser::isDisallowedIdentifierLet):
489         (JSC::Parser::isDisallowedIdentifierYield):
490         (JSC::Parser::disallowedIdentifierLetReason):
491         (JSC::Parser::disallowedIdentifierYieldReason):
492         Follow pattern for improved error messages based on context.
493
494 2017-04-23  Commit Queue  <commit-queue@webkit.org>
495
496         Unreviewed, rolling out r215674.
497         https://bugs.webkit.org/show_bug.cgi?id=171212
498
499         Possible unintended commit. This patch was on the wrong bug.
500         (Requested by JoePeck on #webkit).
501
502         Reverted changeset:
503
504         "test262: test262/test/language/expressions/generators/yield-
505         as-label.js"
506         https://bugs.webkit.org/show_bug.cgi?id=170979
507         http://trac.webkit.org/changeset/215674
508
509 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
510
511         test262: test262/test/built-ins/Number/prototype/toPrecision/nan.js
512         https://bugs.webkit.org/show_bug.cgi?id=171197
513
514         Reviewed by Saam Barati.
515
516         * runtime/NumberPrototype.cpp:
517         (JSC::numberProtoFuncToExponential):
518         (JSC::numberProtoFuncToFixed):
519         (JSC::numberProtoFuncToPrecision):
520         Refine the order of operations to match the spec.
521
522 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
523
524         test262: test262/test/language/expressions/generators/yield-as-label.js
525         https://bugs.webkit.org/show_bug.cgi?id=170979
526
527         Reviewed by Saam Barati.
528
529         * parser/Parser.cpp:
530         (JSC::Parser<LexerType>::parseVariableDeclarationList):
531         (JSC::Parser<LexerType>::parseDestructuringPattern):
532         (JSC::Parser<LexerType>::parseFormalParameters):
533         Converge on "Cannot" instead of "Can't" in error messages.
534
535         (JSC::Parser<LexerType>::parseFunctionInfo):
536         Disallow "yield" as the generator function name in function expressions.
537         This refers to the difference between Declaration and Expression, where
538         only GeneratorExpression explicitly has [+Yield] disallowing yield for
539         the generator name:
540
541             GeneratorDeclaration[Yield, Await, Default]:
542                 function * BindingIdentifier[?Yield, ?Await] ...
543
544             GeneratorExpression:
545                 function * BindingIdentifier[+Yield, ~Await]opt ...
546
547         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
548         Disallow "yield" as a label name in strict mode or inside a generator.
549
550         (JSC::Parser<LexerType>::parseProperty):
551         Disallow "yield" or any keyword in object literal shorthands.
552
553         * parser/Parser.h:
554         (JSC::Parser::getToken):
555         (JSC::Parser::isDisallowedIdentifierLet):
556         (JSC::Parser::isDisallowedIdentifierYield):
557         (JSC::Parser::disallowedIdentifierLetReason):
558         (JSC::Parser::disallowedIdentifierYieldReason):
559         Follow pattern for improved error messages based on context.
560
561 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
562
563         test262: test262/test/built-ins/Number/parseFloat.js
564         https://bugs.webkit.org/show_bug.cgi?id=171193
565
566         Reviewed by Yusuke Suzuki.
567
568         * runtime/CommonIdentifiers.h:
569         * runtime/JSGlobalObject.cpp:
570         (JSC::JSGlobalObject::init):
571         (JSC::JSGlobalObject::visitChildren):
572         * runtime/JSGlobalObject.h:
573         (JSC::JSGlobalObject::parseFloatFunction):
574         Expose parseFloat on the global object to be shared with Number constructor.
575
576         * runtime/NumberConstructor.cpp:
577         (JSC::NumberConstructor::finishCreation):
578         parseFloat uses the same value as the global parseFloat.
579
580 2017-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
581
582         [JSC] Use DoublyLinkedList for MachineThread
583         https://bugs.webkit.org/show_bug.cgi?id=171171
584
585         Reviewed by Mark Lam.
586
587         MachineThread can use WTF::DoublyLinkedList to simplify
588         its implementation. We should not use Vector<> etc. since
589         we do not want to call allocations during suspending and
590         resuming threads.
591
592         * heap/MachineStackMarker.cpp:
593         (JSC::MachineThreads::MachineThreads):
594         (JSC::MachineThreads::~MachineThreads):
595         (JSC::MachineThreads::addCurrentThread):
596         (JSC::MachineThreads::removeThreadIfFound):
597         (JSC::MachineThreads::MachineThread::MachineThread):
598         (JSC::MachineThreads::tryCopyOtherThreadStacks):
599         * heap/MachineStackMarker.h:
600         (JSC::MachineThreads::threadsListHead):
601         * runtime/SamplingProfiler.cpp:
602         (JSC::FrameWalker::isValidFramePointer):
603         * runtime/VMTraps.cpp:
604         (JSC::findActiveVMAndStackBounds):
605
606 2017-04-22  JF Bastien  <jfbastien@apple.com>
607
608         WebAssembly: Module.exports, Module.imports, Module.customSections are wrong
609         https://bugs.webkit.org/show_bug.cgi?id=171078
610
611         Reviewed by Saam Barati.
612
613         They're static properties of Module, not instance properties of a module.
614         https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymoduleexports
615
616         * wasm/js/WebAssemblyModuleConstructor.cpp:
617         (JSC::webAssemblyModuleCustomSections):
618         (JSC::webAssemblyModuleImports):
619         (JSC::webAssemblyModuleExports):
620         * wasm/js/WebAssemblyModulePrototype.cpp:
621         (JSC::webAssemblyModuleProtoCustomSections): Deleted.
622         (JSC::webAssemblyModuleProtoImports): Deleted.
623         (JSC::webAssemblyModuleProtoExports): Deleted.
624
625 2017-04-21  Saam Barati  <sbarati@apple.com>
626
627         SharedArrayBuffer-opt.js fails with Briggs
628         https://bugs.webkit.org/show_bug.cgi?id=170948
629         <rdar://problem/31740568>
630
631         Reviewed by Michael Saboff.
632
633         The bug was not actually with Briggs, but instead was with
634         our X86-64 MacroAssembler. Michael fixed the bug here:
635         https://trac.webkit.org/changeset/215618/webkit
636         
637         The issue was we weren't adding the REX byte for AtomicXchg8,
638         leading to the incorrect encoding for the result register depending
639         on which register it was. If you look at this code, you'll see the issue:
640
641           Int32 @38 = AtomicXchg(@59, @64, width = 8, range = 0, fenceRange = 0, ControlDependent|Fence|Writes:0|Reads:0, DFG:@49)
642               AtomicXchg8 %rsi, (%rax,%rdx), @38
643                   0x2dcb5bc0015e: lock xchg %dh, (%rax,%rdx)
644           Int32 @66 = Const32(255, DFG:@49)
645           Int32 @67 = BitAnd(@38, $255(@66), DFG:@49)
646               ZeroExtend8To32 %rsi, %rax, @67
647                   0x2dcb5bc00162: movzx %sil, %eax
648
649         Air thought the result was in the lower 8 bits of %rsi,
650         however, the code we emitted stored it in the [8-15] bits
651         of %rdx. Since this issue is fixed, I'm turning Briggs back
652         on.
653
654         * b3/air/AirAllocateRegistersByGraphColoring.h:
655         (JSC::B3::Air::useIRC):
656
657 2017-04-20  Mark Lam  <mark.lam@apple.com>
658
659         Refactor MASM probe to allow printing of custom types.
660         https://bugs.webkit.org/show_bug.cgi?id=171101
661
662         Reviewed by JF Bastien.
663
664         For example, this allows us to add MASM printing of CodeBlock* and Air::Args.
665
666         In general, MASM print can be used like dataLog, except that it generates JITted
667         code for doing the dataLogging later when the JITted code runs.  MASM print can
668         print any value type that a specialized Printer template or a setPrinter()
669         function implemented for that type.
670
671         * CMakeLists.txt:
672         * JavaScriptCore.xcodeproj/project.pbxproj:
673         * assembler/MacroAssembler.h:
674
675         * assembler/MacroAssemblerPrinter.cpp:
676         (JSC::Printer::printAllRegisters):
677         (JSC::Printer::printPCRegister):
678         (JSC::Printer::printRegisterID):
679         (JSC::Printer::printFPRegisterID):
680         (JSC::Printer::printAddress):
681         (JSC::Printer::printMemory):
682         (JSC::Printer::printCallback):
683         (JSC::printIndent): Deleted.
684         (JSC::printCPU): Deleted.
685         (JSC::printCPURegisters): Deleted.
686         (JSC::printPC): Deleted.
687         (JSC::printRegister): Deleted.
688         (JSC::printMemory): Deleted.
689         (JSC::MacroAssemblerPrinter::printCallback): Deleted.
690         * assembler/MacroAssemblerPrinter.h:
691         (JSC::AllRegisters::AllRegisters):
692         (JSC::Printer::Printer<AllRegisters>::Printer):
693         (JSC::Printer::Printer<PCRegister>::Printer):
694         (JSC::Printer::Printer<MacroAssembler::RegisterID>::Printer):
695         (JSC::Printer::Printer<MacroAssembler::FPRegisterID>::Printer):
696         (JSC::Printer::Printer<MacroAssembler::Address>::Printer):
697         (JSC::Printer::Printer<Memory>::Printer):
698         (JSC::Printer::Printer<MemWord<IntType>>::Printer):
699         (JSC::MacroAssembler::print):
700         (JSC::MacroAssemblerPrinter::print): Deleted.
701         (JSC::MacroAssemblerPrinter::PrintArg::PrintArg): Deleted.
702         (JSC::MacroAssemblerPrinter::appendPrintArg): Deleted.
703         - Refactored to move the underlying PrintRecord (and associated data structures)
704           out to Printer.cpp/h.
705         - MacroAssemblerPrinter.cpp/h now only add custom Printers for MASM types like
706           RegisterID and Memory.  It also defines the implementation of
707           MacroAssembler::print().
708
709           As before, JIT code that wishes to use MacroAssembler::print() needs to
710           #include "MacroAssemblerPrinter.h".
711
712         - Also added the ability to specify an optional indentation (in number of chars)
713           when MASM printing AllRegisters.  This is useful because AllRegisters prints
714           a block of data unlike other printers which print inline.
715
716         * assembler/Printer.cpp: Added.
717         (JSC::Printer::printConstCharString):
718         (JSC::Printer::printIntptr):
719         (JSC::Printer::printUintptr):
720         (JSC::Printer::printPointer):
721         (JSC::Printer::setPrinter):
722         * assembler/Printer.h: Added.
723         (JSC::Printer::Context::Context):
724         (JSC::Printer::PrintRecord::PrintRecord):
725         (JSC::Printer::appendPrinter):
726         (JSC::Printer::makePrintRecordList):
727         (JSC::Printer::Printer<RawPointer>::Printer):
728         (JSC::Printer::setPrinter):
729         (JSC::Printer::Printer::Printer):
730         - Data structures for creating a list of PrintRecords.  Classes which wish to
731           add custom support for MASM printing can #include "Printer.h" and implement
732           either:
733           1. a specialized Printer template, or
734           2. a setPrinter() function.
735
736           See Printer<Reg> and Printer<B3::Air::Tmp> in AirPrintSpecial.h for examples of
737           (1).  See CodeBlock's setPrinter() for an example of (2).
738
739         * b3/B3LowerToAir.cpp:
740         (JSC::B3::Air::LowerToAir::print):
741         * b3/air/AirPrintSpecial.cpp: Added.
742         (JSC::B3::Air::PrintSpecial::PrintSpecial):
743         (JSC::B3::Air::PrintSpecial::~PrintSpecial):
744         (JSC::B3::Air::PrintSpecial::forEachArg):
745         (JSC::B3::Air::PrintSpecial::isValid):
746         (JSC::B3::Air::PrintSpecial::admitsStack):
747         (JSC::B3::Air::PrintSpecial::reportUsedRegisters):
748         (JSC::B3::Air::PrintSpecial::generate):
749         (JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs):
750         (JSC::B3::Air::PrintSpecial::extraClobberedRegs):
751         (JSC::B3::Air::PrintSpecial::dumpImpl):
752         (JSC::B3::Air::PrintSpecial::deepDumpImpl):
753         (JSC::Printer::printAirArg):
754         * b3/air/AirPrintSpecial.h: Added.
755         (JSC::Printer::appendAirArg):
756         (JSC::Printer::appendAirArgs):
757         (JSC::Printer::Printer<B3::Air::Tmp>::Printer):
758         (JSC::Printer::Printer<Reg>::Printer):
759         - Add the print() operation for use in LowerToAir.  print() will emit a
760           PrintSpecial that will ultimately emit a MASM print to print what we want.
761         - LowerToAir's print() adds the ability to print Air::Args.
762         - Unlike in the baseline JIT and the DFG, LowerToAir's print() can perturb the
763           usage of registers.  This is because PrintSpecial is a patch point, and it
764           prevents certain optimizations.  If not used carefully, an attempt to print()
765           an Arg by taking a Tmp, can force the B3 Value into a Tmp earlier than it would
766           otherwise do so.  So, use LowerToAir's print() with care.
767
768         * bytecode/CodeBlock.cpp:
769         (JSC::setPrinter):
770         - Now we can MASM print CodeBlock*.
771         (WTF::printInternal):
772         - Now we can dataLog CodeBlock* (including null CodeBlock pointers).
773
774         * bytecode/CodeBlock.h:
775
776         * runtime/VM.cpp:
777         (JSC::VM::throwException):
778         - Use the new ability to dataLog CodeBlock*.  No need to do an explicit null
779           check before printing anymore.
780
781 2017-04-21  Keith Miller  <keith_miller@apple.com>
782
783         Unreviewed, rolling out r215634.
784
785         underlying build issues should have been fixed
786
787         Reverted changeset:
788
789         "Unreviewed, rolling out r215620 and r215623."
790         https://bugs.webkit.org/show_bug.cgi?id=171139
791         http://trac.webkit.org/changeset/215634
792
793 2017-04-21  Commit Queue  <commit-queue@webkit.org>
794
795         Unreviewed, rolling out r215620 and r215623.
796         https://bugs.webkit.org/show_bug.cgi?id=171139
797
798         broke arm64 build (Requested by keith_miller on #webkit).
799
800         Reverted changesets:
801
802         "Add signaling API"
803         https://bugs.webkit.org/show_bug.cgi?id=170976
804         http://trac.webkit.org/changeset/215620
805
806         "Unreviewed, fix Cloop build."
807         http://trac.webkit.org/changeset/215623
808
809 2017-04-21  Keith Miller  <keith_miller@apple.com>
810
811         Remove LL/SC from Atomics
812         https://bugs.webkit.org/show_bug.cgi?id=171141
813
814         Reviewed by Saam Barati.
815
816         Adding load link and store conditionally was not an actual progression
817         and the existing code is causing problems for users of Atomics. So let's
818         get rid of it.
819
820         * heap/LargeAllocation.h:
821         (JSC::LargeAllocation::testAndSetMarked):
822         * heap/MarkedBlock.h:
823         (JSC::MarkedBlock::testAndSetMarked):
824         * heap/SlotVisitor.cpp:
825         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
826
827 2017-04-21  Keith Miller  <keith_miller@apple.com>
828
829         Unreviewed, fix Cloop build.
830
831         * jit/ExecutableAllocator.h:
832         (JSC::isJITPC):
833
834 2017-04-20  Keith Miller  <keith_miller@apple.com>
835
836         Add signaling API
837         https://bugs.webkit.org/show_bug.cgi?id=170976
838
839         Reviewed by Filip Pizlo.
840
841         Update various uses of sigaction to use the new signaling API.
842         Also switch VMTraps to use the thread message system instead of
843         rolling it's own.
844
845         * jit/ExecutableAllocator.h:
846         (JSC::isJITPC):
847         * runtime/VMTraps.cpp:
848         (JSC::installSignalHandler):
849         (JSC::VMTraps::VMTraps):
850         (JSC::VMTraps::SignalSender::send):
851         (JSC::handleSigusr1): Deleted.
852         (JSC::handleSigtrap): Deleted.
853         (JSC::installSignalHandlers): Deleted.
854         * runtime/VMTraps.h:
855         * tools/SigillCrashAnalyzer.cpp:
856         (JSC::installCrashHandler):
857         (JSC::handleCrash): Deleted.
858         * wasm/WasmFaultSignalHandler.cpp:
859         (JSC::Wasm::trapHandler):
860         (JSC::Wasm::enableFastMemory):
861
862 2017-04-21  Michael Saboff  <msaboff@apple.com>
863
864         X86-64 Assembler doesn't handle xchg with byte register src
865         https://bugs.webkit.org/show_bug.cgi?id=171118
866
867         Reviewed by Saam Barati.
868
869         * assembler/X86Assembler.h:
870         (JSC::X86Assembler::xchgb_rm): Use oneByteOp8() since these are 8 bit opcodes.
871
872 2017-04-21  Andy VanWagoner  <thetalecrafter@gmail.com>
873
874         [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
875         https://bugs.webkit.org/show_bug.cgi?id=169458
876
877         Reviewed by JF Bastien.
878
879         Use udat_formatForFields to iterate through the parts of a formatted date string.
880         Make formatToParts and related functions dependent on ICU version >= 55.
881
882         * icu/unicode/udat.h: Update to 55.1.
883         * icu/unicode/ufieldpositer.h: Added from 55.1.
884         * icu/unicode/uvernum.h: Update to 55.1
885         * runtime/IntlDateTimeFormat.cpp:
886         (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
887         (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
888         * runtime/IntlDateTimeFormat.h:
889         * runtime/IntlDateTimeFormatPrototype.cpp:
890         (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
891
892 2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>
893
894         [cmake] Define FORWARDING_HEADERS_DIR in WebKitFS and use it everywhere
895         https://bugs.webkit.org/show_bug.cgi?id=171071
896
897         Reviewed by Michael Catanzaro.
898
899         "${DERIVED_SOURCES_DIR}/ForwardingHeaders" path occurs very often in the
900         build system files. GTK-specifc FORWARDING_HEADERS_DIR variable should
901         be available for all ports.
902
903         * CMakeLists.txt:
904         * PlatformWin.cmake:
905
906 2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>
907
908         Remove unused lamda captures
909         https://bugs.webkit.org/show_bug.cgi?id=171098
910
911         Reviewed by Yusuke Suzuki.
912
913         * bytecompiler/NodesCodegen.cpp:
914         (JSC::ArrayNode::emitBytecode):
915         * ftl/FTLState.cpp:
916         (JSC::FTL::State::State):
917         * wasm/WasmB3IRGenerator.cpp:
918
919 2017-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
920
921         [JSC][FTL] FTL should support Arrayify
922         https://bugs.webkit.org/show_bug.cgi?id=169596
923
924         Reviewed by Saam Barati.
925
926         This patch simply expands the coverage of FTL by supporting Arrayify.
927         While ArrayifyToStructure is already supported, Arrayify is not supported
928         in FTL. While supporting Arrayify in FTL itself does not offer so much
929         performance difference from DFG's one, no FTL support for Arrayify
930         prevents us applying FTL to the code including Arrayify.
931
932         * dfg/DFGArrayMode.cpp:
933         (JSC::DFG::toIndexingShape):
934         * dfg/DFGSpeculativeJIT.cpp:
935         (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
936         * ftl/FTLCapabilities.cpp:
937         (JSC::FTL::canCompile):
938         * ftl/FTLLowerDFGToB3.cpp:
939         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
940         (JSC::FTL::DFG::LowerDFGToB3::compileArrayify):
941         (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray):
942         (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForArrayify):
943         (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForCheckArray):
944         (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): Deleted.
945         (JSC::FTL::DFG::LowerDFGToB3::isArrayType): Deleted.
946
947 2017-04-20  Mark Lam  <mark.lam@apple.com>
948
949         virtualThunkFor() needs to materialize its of tagMaskRegister for tail calls.
950         https://bugs.webkit.org/show_bug.cgi?id=171079
951         <rdar://problem/31684756>
952
953         Reviewed by Saam Barati.
954
955         This is needed because tail calls would restore callee saved registers (and
956         therefore, potentially clobber the tag registers) before jumping to the thunk.
957
958         * jit/ThunkGenerators.cpp:
959         (JSC::virtualThunkFor):
960
961 2017-04-20  Mark Lam  <mark.lam@apple.com>
962
963         Build fix after r215592.
964         https://bugs.webkit.org/show_bug.cgi?id=171088
965
966         Not reviewed.
967
968         * assembler/MacroAssemblerPrinter.h:
969
970 2017-04-20  Mark Lam  <mark.lam@apple.com>
971
972         Update the MASM probe to only take 1 arg instead of 2 (in addition to the callback function).
973         https://bugs.webkit.org/show_bug.cgi?id=171088
974
975         Reviewed by Michael Saboff and Saam Barati.
976
977         Experience shows that we never use the 2nd arg.  So, let's remove it to reduce
978         the footprint at each probe site.
979
980         Also fix the MacroAssembler::print() function so that it is a no-op when
981         !ENABLE(MASM_PROBE).  This will allow us to have print() statements in JIT code
982         without a lot of #if ENABLE(MASM_PROBE)s later.
983
984         * assembler/AbstractMacroAssembler.h:
985         * assembler/MacroAssembler.cpp:
986         (JSC::stdFunctionCallback):
987         (JSC::MacroAssembler::probe):
988         * assembler/MacroAssembler.h:
989         * assembler/MacroAssemblerARM.cpp:
990         (JSC::MacroAssemblerARM::probe):
991         * assembler/MacroAssemblerARM.h:
992         * assembler/MacroAssemblerARM64.cpp:
993         (JSC::MacroAssemblerARM64::probe):
994         * assembler/MacroAssemblerARM64.h:
995         * assembler/MacroAssemblerARMv7.cpp:
996         (JSC::MacroAssemblerARMv7::probe):
997         * assembler/MacroAssemblerARMv7.h:
998         * assembler/MacroAssemblerPrinter.cpp:
999         (JSC::MacroAssemblerPrinter::printCallback):
1000         * assembler/MacroAssemblerPrinter.h:
1001         (JSC::MacroAssemblerPrinter::print):
1002         (JSC::MacroAssembler::print):
1003         * assembler/MacroAssemblerX86Common.cpp:
1004         (JSC::MacroAssemblerX86Common::probe):
1005         * assembler/MacroAssemblerX86Common.h:
1006
1007 2017-04-20  Matt Baker  <mattbaker@apple.com>
1008
1009         Web Inspector: Add regular expression support to XHR breakpoints
1010         https://bugs.webkit.org/show_bug.cgi?id=170099
1011         <rdar://problem/31558082>
1012
1013         Reviewed by Joseph Pecoraro.
1014
1015         * inspector/protocol/DOMDebugger.json:
1016         New optional `isRegex` parameter denotes whether `url` contains
1017         a regular expression.
1018
1019 2017-04-15  Filip Pizlo  <fpizlo@apple.com>
1020
1021         Optimize SharedArrayBuffer in the DFG+FTL
1022         https://bugs.webkit.org/show_bug.cgi?id=164108
1023
1024         Reviewed by Saam Barati.
1025         
1026         This adds atomics intrinsics to the DFG and wires them through to the DFG and FTL backends. This
1027         was super easy in the FTL since B3 already has comprehensive atomic intrinsics, which are more
1028         powerful than what we need right now. In the DFG backend, I went with an easy-to-write
1029         implementation that just reduces everything to a weak CAS loop. It's very inefficient with
1030         registers (it needs ~8) but it's the DFG backend, so it's not obvious how much we care.
1031         
1032         To make the rare cases easy to handle, I refactored AtomicsObject.cpp so that the operations for
1033         the slow paths can share code with the native functions.
1034         
1035         This also fixes register handling in the X86 implementations of CAS, in the case that
1036         expectedAndResult is not %rax. This also fixes the ARM64 implementation of branchWeakCAS.
1037         
1038         I adapted the CascadeLock from WTF/benchmarks/ToyLocks.h as a microbenchmark of lock performance.
1039         This benchmark performs 2.5x faster, in both the contended and uncontended case, thanks to this
1040         change. It's still about 3x slower than native. I investigated this only a bit. I suspect that
1041         the story will be different in asm.js code, which will get constant-folding of the typed array
1042         backing store by virtue of how it uses lexically scoped variables as pointers to the heap arrays.
1043         It's worth noting that the native lock I was comparing against, the very nicely-tuned
1044         CascadeLock, is at the very high end of lock throughput under virtually all conditions
1045         (uncontended, microcontended, held for a long time). I also compared to WTF::Lock and others, and
1046         the only ones that performed better in this microbenchmark were spinlocks. I don't recommend
1047         using those. So, when I say this is 3x slower than native, I really mean that it's 3x slower than
1048         the fastest native lock that I have in my arsenal.
1049         
1050         Also worth noting is that I experimented with exposing Atomics.yield(), which uses sched_yield,
1051         as a way of testing if adding a yield loop to the JS cascadeLock would help. It does not help. I
1052         did not investigate why.
1053
1054         * assembler/AbstractMacroAssembler.h:
1055         (JSC::AbstractMacroAssembler::JumpList::append):
1056         * assembler/CPU.h:
1057         (JSC::is64Bit):
1058         (JSC::is32Bit):
1059         * b3/B3Common.h:
1060         (JSC::B3::is64Bit): Deleted.
1061         (JSC::B3::is32Bit): Deleted.
1062         * b3/B3LowerToAir.cpp:
1063         (JSC::B3::Air::LowerToAir::appendTrapping):
1064         (JSC::B3::Air::LowerToAir::appendCAS):
1065         (JSC::B3::Air::LowerToAir::appendGeneralAtomic):
1066         * dfg/DFGAbstractInterpreterInlines.h:
1067         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1068         * dfg/DFGByteCodeParser.cpp:
1069         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1070         * dfg/DFGClobberize.h:
1071         (JSC::DFG::clobberize):
1072         * dfg/DFGDoesGC.cpp:
1073         (JSC::DFG::doesGC):
1074         * dfg/DFGFixupPhase.cpp:
1075         (JSC::DFG::FixupPhase::fixupNode):
1076         * dfg/DFGNode.h:
1077         (JSC::DFG::Node::hasHeapPrediction):
1078         (JSC::DFG::Node::hasArrayMode):
1079         * dfg/DFGNodeType.h:
1080         (JSC::DFG::isAtomicsIntrinsic):
1081         (JSC::DFG::numExtraAtomicsArgs):
1082         * dfg/DFGPredictionPropagationPhase.cpp:
1083         * dfg/DFGSSALoweringPhase.cpp:
1084         (JSC::DFG::SSALoweringPhase::handleNode):
1085         * dfg/DFGSafeToExecute.h:
1086         (JSC::DFG::safeToExecute):
1087         * dfg/DFGSpeculativeJIT.cpp:
1088         (JSC::DFG::SpeculativeJIT::loadFromIntTypedArray):
1089         (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
1090         (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
1091         (JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand):
1092         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
1093         * dfg/DFGSpeculativeJIT.h:
1094         (JSC::DFG::SpeculativeJIT::callOperation):
1095         * dfg/DFGSpeculativeJIT32_64.cpp:
1096         (JSC::DFG::SpeculativeJIT::compile):
1097         * dfg/DFGSpeculativeJIT64.cpp:
1098         (JSC::DFG::SpeculativeJIT::compile):
1099         * ftl/FTLAbstractHeapRepository.cpp:
1100         (JSC::FTL::AbstractHeapRepository::decorateFencedAccess):
1101         (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
1102         * ftl/FTLAbstractHeapRepository.h:
1103         * ftl/FTLCapabilities.cpp:
1104         (JSC::FTL::canCompile):
1105         * ftl/FTLLowerDFGToB3.cpp:
1106         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1107         (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
1108         (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree):
1109         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
1110         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
1111         (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray):
1112         (JSC::FTL::DFG::LowerDFGToB3::loadFromIntTypedArray):
1113         (JSC::FTL::DFG::LowerDFGToB3::storeType):
1114         (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
1115         (JSC::FTL::DFG::LowerDFGToB3::getIntTypedArrayStoreOperand):
1116         (JSC::FTL::DFG::LowerDFGToB3::vmCall):
1117         * ftl/FTLOutput.cpp:
1118         (JSC::FTL::Output::store):
1119         (JSC::FTL::Output::store32As8):
1120         (JSC::FTL::Output::store32As16):
1121         (JSC::FTL::Output::atomicXchgAdd):
1122         (JSC::FTL::Output::atomicXchgAnd):
1123         (JSC::FTL::Output::atomicXchgOr):
1124         (JSC::FTL::Output::atomicXchgSub):
1125         (JSC::FTL::Output::atomicXchgXor):
1126         (JSC::FTL::Output::atomicXchg):
1127         (JSC::FTL::Output::atomicStrongCAS):
1128         * ftl/FTLOutput.h:
1129         (JSC::FTL::Output::store32):
1130         (JSC::FTL::Output::store64):
1131         (JSC::FTL::Output::storePtr):
1132         (JSC::FTL::Output::storeFloat):
1133         (JSC::FTL::Output::storeDouble):
1134         * jit/JITOperations.h:
1135         * runtime/AtomicsObject.cpp:
1136         (JSC::atomicsFuncAdd):
1137         (JSC::atomicsFuncAnd):
1138         (JSC::atomicsFuncCompareExchange):
1139         (JSC::atomicsFuncExchange):
1140         (JSC::atomicsFuncIsLockFree):
1141         (JSC::atomicsFuncLoad):
1142         (JSC::atomicsFuncOr):
1143         (JSC::atomicsFuncStore):
1144         (JSC::atomicsFuncSub):
1145         (JSC::atomicsFuncWait):
1146         (JSC::atomicsFuncWake):
1147         (JSC::atomicsFuncXor):
1148         (JSC::operationAtomicsAdd):
1149         (JSC::operationAtomicsAnd):
1150         (JSC::operationAtomicsCompareExchange):
1151         (JSC::operationAtomicsExchange):
1152         (JSC::operationAtomicsIsLockFree):
1153         (JSC::operationAtomicsLoad):
1154         (JSC::operationAtomicsOr):
1155         (JSC::operationAtomicsStore):
1156         (JSC::operationAtomicsSub):
1157         (JSC::operationAtomicsXor):
1158         * runtime/AtomicsObject.h:
1159
1160 2017-04-19  Youenn Fablet  <youenn@apple.com>
1161
1162         [Mac] Allow customizing H264 encoder
1163         https://bugs.webkit.org/show_bug.cgi?id=170829
1164
1165         Reviewed by Alex Christensen.
1166
1167         * Configurations/FeatureDefines.xcconfig:
1168
1169 2017-04-19  Michael Saboff  <msaboff@apple.com>
1170
1171         Tune GC related JSC options for iOS
1172         https://bugs.webkit.org/show_bug.cgi?id=171019
1173
1174         Reviewed by Mark Lam.
1175
1176         Always set these GC options on iOS.
1177
1178         * runtime/Options.cpp:
1179         (JSC::overrideDefaults):
1180
1181 2017-04-19  JF Bastien  <jfbastien@apple.com>
1182
1183         WebAssembly: fast memory cleanups
1184         https://bugs.webkit.org/show_bug.cgi?id=170909
1185
1186         Reviewed by Saam Barati.
1187
1188         * b3/B3LowerToAir.cpp: correct comment, and make wasm-independent
1189         (JSC::B3::Air::LowerToAir::lower):
1190         * b3/B3Procedure.h:
1191         * b3/B3Validate.cpp:
1192         * b3/B3Value.cpp:
1193         (JSC::B3::Value::effects):
1194         * b3/B3WasmBoundsCheckValue.cpp: have the creator pass in a
1195         maximum, so we don't have to know so much about wasm here
1196         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
1197         (JSC::B3::WasmBoundsCheckValue::cloneImpl):
1198         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
1199         * b3/B3WasmBoundsCheckValue.h:
1200         (JSC::B3::WasmBoundsCheckValue::boundsType):
1201         (JSC::B3::WasmBoundsCheckValue::bounds):
1202         * b3/air/AirCode.h:
1203         * b3/air/AirCustom.h:
1204         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
1205         * b3/testb3.cpp:
1206         (JSC::B3::testWasmBoundsCheck):
1207         * wasm/WasmB3IRGenerator.cpp:
1208         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1209         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
1210         (JSC::Wasm::createJSToWasmWrapper): remove dead code
1211         * wasm/WasmMemory.cpp: don't GC if no memory could possibly be free'd
1212         (JSC::Wasm::Memory::initializePreallocations): verbose-only code,
1213         and copy-pasta bug
1214
1215 2017-04-19  Mark Lam  <mark.lam@apple.com>
1216
1217         B3StackmapSpecial should handle when stackmap values are not recoverable from a Def'ed arg.
1218         https://bugs.webkit.org/show_bug.cgi?id=170973
1219         <rdar://problem/30318657>
1220
1221         Reviewed by Filip Pizlo.
1222
1223         In the event of an arithmetic overflow on a binary sub instruction (where the
1224         result register is same as one of the operand registers), the CheckSub FTL
1225         operation will try to recover the original value in the clobbered result register.
1226
1227         This recover is done by adding the other operand value to the result register.
1228         However, this recovery method only works if the width of the original value in
1229         the result register is less or equal to the width of the expected result.  If the
1230         width of the original operand value (e.g. a JSInt32) is wider than the result
1231         (e.g. a machine Int32), then the sub operation would have zero extended the
1232         result and cleared the upper 32-bits of the result register.  Recovery by adding
1233         back the other operand will not restore the JSValue tag in the upper word.
1234
1235         This poses a problem if the stackmap value for the operand relies on that same
1236         clobbered register.
1237
1238         The fix is to detect this potential scenario (i.e. width of the Def's arg < width
1239         of a stackmap value).  If this condition is detected, we'll declare the stackmap
1240         value to be LateColdUse to ensure that the register allocator gives it a
1241         different register if needed so that it's not dependent on the clobbered register.
1242
1243         * b3/B3CheckSpecial.cpp:
1244         (JSC::B3::CheckSpecial::forEachArg):
1245         * b3/B3PatchpointSpecial.cpp:
1246         (JSC::B3::PatchpointSpecial::forEachArg):
1247         * b3/B3StackmapSpecial.cpp:
1248         (JSC::B3::StackmapSpecial::forEachArgImpl):
1249         * b3/B3StackmapSpecial.h:
1250
1251 2017-04-19  JF Bastien  <jfbastien@apple.com>
1252
1253         Unreviewed, rolling out r215520.
1254
1255         Broke Debian 8
1256
1257         Reverted changeset:
1258
1259         "[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts"
1260         https://bugs.webkit.org/show_bug.cgi?id=169458
1261         http://trac.webkit.org/changeset/215520
1262
1263 2017-04-19  JF Bastien  <jfbastien@apple.com>
1264
1265         WebAssembly: limit slow memories
1266         https://bugs.webkit.org/show_bug.cgi?id=170825
1267
1268         Reviewed by Saam Barati.
1269
1270         We limits the number of fast memories, partly because ASLR. The
1271         code then falls back to slow memories. It first tries to virtually
1272         allocated any declared maximum (and in there, physically the
1273         initial), and if that fails it tries to physically allocate the
1274         initial without any extra.
1275
1276         This can still be used to cause a bunch of virtual
1277         allocation. This patch imposes soft limit on slow memories as
1278         well. The total virtual maximum for slow memories is set at the
1279         same (theoretical) value as that for fast memories.
1280
1281         Anything exceeding that limit causes allocation/grow to fail.
1282
1283         * wasm/WasmMemory.cpp:
1284
1285 2017-04-19  JF Bastien  <jfbastien@apple.com>
1286
1287         Cannot compile JavaScriptCore/runtime/VMTraps.cpp on FreeBSD because std::pair has a non-trivial copy constructor
1288         https://bugs.webkit.org/show_bug.cgi?id=170875
1289
1290         Reviewed by Mark Lam.
1291
1292         WTF::ExpectedDetail::ConstexprBase doesn't have a user-defined
1293         copy constructor, and its implicitly-defined copy constructor is
1294         deleted because the default std::pair implementation on FreeBSD
1295         has a non-trivial copy constructor. /usr/include/c++/v1/__config
1296         says _LIBCPP_TRIVIAL_PAIR_COPY_CTOR is disabled in order to keep
1297         ABI compatibility:
1298         https://svnweb.freebsd.org/changeset/base/261801.
1299
1300         That's a huge bummer, and I'm not a fan of broken stdlibs, but in
1301         this case it's pretty nice to have a custom named type anyways and
1302         costs nothing.
1303
1304         * runtime/VMTraps.cpp:
1305         (JSC::findActiveVMAndStackBounds):
1306         (JSC::handleSigusr1):
1307         (JSC::handleSigtrap):
1308
1309 2017-04-19  Andy VanWagoner  <thetalecrafter@gmail.com>
1310
1311         [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
1312         https://bugs.webkit.org/show_bug.cgi?id=169458
1313
1314         Reviewed by JF Bastien.
1315
1316         Use udat_formatForFields to iterate through the parts of a formatted date string.
1317
1318         * icu/unicode/udat.h: Update to 55.1.
1319         * icu/unicode/ufieldpositer.h: Added from 55.1.
1320         * runtime/IntlDateTimeFormat.cpp:
1321         (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
1322         (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
1323         * runtime/IntlDateTimeFormat.h:
1324         * runtime/IntlDateTimeFormatPrototype.cpp:
1325         (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
1326
1327 2017-04-19  JF Bastien  <jfbastien@apple.com>
1328
1329         WebAssembly: don't expose any WebAssembly JS object if JIT is off
1330         https://bugs.webkit.org/show_bug.cgi?id=170782
1331
1332         Reviewed by Saam Barati.
1333
1334         It's unexpected that we expose the global WebAssembly object if no
1335         JIT is present because it can't be used to compile or
1336         instantiate. Other APIs such as Memory should also be Inaccessible
1337         in those circumstances.
1338
1339         Also ensure that we don't pre-allocate fast memories if
1340         WebAssembly won't be used, and don't mark our intention to use a
1341         fast TLS slot for WebAssembly.
1342
1343         * runtime/Options.cpp:
1344         (JSC::recomputeDependentOptions):
1345
1346 2017-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1347
1348         r211670 broke double to int conversion.
1349         https://bugs.webkit.org/show_bug.cgi?id=170961
1350
1351         Reviewed by Mark Lam.
1352
1353         In this patch, we take a template parameter way.
1354         While it reduces duplicate code, it effectively produces
1355         optimized code for operationToInt32SensibleSlow,
1356         and fixes kraken pbkdf2 regression on Linux.
1357
1358         And this patch also fixes undefined behavior by changing
1359         int32_t to uint32_t. If exp is 31, missingOne is 1 << 31,
1360         INT32_MIN. Thus missingOne - 1 will cause int32_t overflow,
1361         and it is an undefined behavior.
1362
1363         * runtime/MathCommon.cpp:
1364         (JSC::operationToInt32SensibleSlow):
1365         * runtime/MathCommon.h:
1366         (JSC::toInt32Internal):
1367         (JSC::toInt32):
1368
1369 2017-04-18  Mark Lam  <mark.lam@apple.com>
1370
1371         r211670 broke double to int conversion.
1372         https://bugs.webkit.org/show_bug.cgi?id=170961
1373         <rdar://problem/31687696>
1374
1375         Reviewed by Yusuke Suzuki.
1376
1377         This is because operationToInt32SensibleSlow() assumes that left shifts of greater
1378         than 31 bits on an 31-bit value will produce a 0.  However, the spec says that
1379         "if the value of the right operand is negative or is greater or equal to the
1380         number of bits in the promoted left operand, the behavior is undefined."
1381         See http://en.cppreference.com/w/cpp/language/operator_arithmetic#Bitwise_shift_operators.
1382
1383         This patch fixes this by restoring the check to prevent a shift of greater than
1384         31 bits.  It also consolidates the optimization in operationToInt32SensibleSlow()
1385         back into toInt32() so that we don't have 2 copies of the same code with only a
1386         slight variation.
1387
1388         JSC benchmarks shows that performance is neutral with this patch.
1389
1390         * dfg/DFGSpeculativeJIT.cpp:
1391         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
1392         * ftl/FTLLowerDFGToB3.cpp:
1393         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
1394         * runtime/MathCommon.cpp:
1395         (JSC::operationToInt32SensibleSlow): Deleted.
1396         * runtime/MathCommon.h:
1397         (JSC::toInt32):
1398
1399 2017-04-18  Oleksandr Skachkov  <gskachkov@gmail.com>
1400
1401         [ES6]. Implement Annex B.3.3 function hoisting rules for eval
1402         https://bugs.webkit.org/show_bug.cgi?id=163208
1403
1404         Reviewed by Saam Barati.
1405
1406         Current patch implements Annex B.3.3 that is related to 
1407         hoisting of function declaration in eval. 
1408         https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
1409         Function declaration in eval should create variable with 
1410         function name in function scope where eval is invoked 
1411         or bind to variable if it declared outside of the eval. 
1412         If variable is created it can be removed by 'delete a;' command. 
1413         If eval is invoke in block scope that contains let/const 
1414         variable with the same name as function declaration 
1415         we do not bind. This patch leads to the following behavior: 
1416         '''
1417         function foo() {
1418            {
1419              print(boo); // undefined
1420              eval('{ function boo() {}}');
1421              print(boo); // function boo() {}
1422            }
1423            print(boo); // function boo() {}
1424         }
1425
1426         function foobar() {
1427           { 
1428             let boo = 10;
1429             print(boo); // 10;
1430             eval('{ function boo() {}}');
1431             print(boo); // 10;
1432           }
1433           print(boo) // 10
1434         }
1435
1436         function bar() {
1437            {
1438               var boo = 10;
1439               print(boo); // 10
1440               eval('{ function boo() {} }'); 
1441               print(boo); // function boo() {}
1442            }
1443            print(boo); // function boo() {}
1444         }       
1445         
1446         function bas() {
1447             {
1448                  let boo = 10;
1449                  eval(' { function boo() {} } ');
1450                  print(boo); // 10
1451             }
1452             print(boo); //Reference Error
1453         }
1454         '''
1455
1456         Current implementation relies on already implemented 
1457         'hoist function in sloppy mode' feature, with small changes.
1458         In short it works in following way: during hoisting of function 
1459         with name S in eval, we are looking for first scope that 
1460         contains space for variable with name S and if this scope 
1461         has var type we bind function there
1462
1463         To implement this feature was added bytecode ops:
1464         op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
1465         or return undefined if variable can't be binded there.
1466
1467         There is a corner case, hoist function in eval within catch block,
1468         that is not covered by this patch, and will be fixed in 
1469         https://bugs.webkit.org/show_bug.cgi?id=168184
1470
1471         * bytecode/BytecodeDumper.cpp:
1472         (JSC::BytecodeDumper<Block>::dumpBytecode):
1473         * bytecode/BytecodeList.json:
1474         * bytecode/BytecodeUseDef.h:
1475         (JSC::computeUsesForBytecodeOffset):
1476         (JSC::computeDefsForBytecodeOffset):
1477         * bytecode/CodeBlock.cpp:
1478         (JSC::CodeBlock::finalizeLLIntInlineCaches):
1479         * bytecode/EvalCodeBlock.h:
1480         (JSC::EvalCodeBlock::functionHoistingCandidate):
1481         (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
1482         * bytecode/UnlinkedEvalCodeBlock.h:
1483         * bytecompiler/BytecodeGenerator.cpp:
1484         (JSC::BytecodeGenerator::BytecodeGenerator):
1485         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
1486         (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
1487         * bytecompiler/BytecodeGenerator.h:
1488         * dfg/DFGAbstractInterpreterInlines.h:
1489         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1490         * dfg/DFGByteCodeParser.cpp:
1491         (JSC::DFG::ByteCodeParser::parseBlock):
1492         * dfg/DFGCapabilities.cpp:
1493         (JSC::DFG::capabilityLevel):
1494         * dfg/DFGClobberize.h:
1495         (JSC::DFG::clobberize):
1496         * dfg/DFGDoesGC.cpp:
1497         (JSC::DFG::doesGC):
1498         * dfg/DFGFixupPhase.cpp:
1499         (JSC::DFG::FixupPhase::fixupNode):
1500         * dfg/DFGNode.h:
1501         (JSC::DFG::Node::hasIdentifier):
1502         * dfg/DFGNodeType.h:
1503         * dfg/DFGOperations.cpp:
1504         * dfg/DFGOperations.h:
1505         * dfg/DFGPredictionPropagationPhase.cpp:
1506         * dfg/DFGSafeToExecute.h:
1507         (JSC::DFG::safeToExecute):
1508         * dfg/DFGSpeculativeJIT.cpp:
1509         (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
1510         * dfg/DFGSpeculativeJIT.h:
1511         (JSC::DFG::SpeculativeJIT::callOperation):
1512         * dfg/DFGSpeculativeJIT32_64.cpp:
1513         (JSC::DFG::SpeculativeJIT::compile):
1514         * dfg/DFGSpeculativeJIT64.cpp:
1515         (JSC::DFG::SpeculativeJIT::compile):
1516         * ftl/FTLCapabilities.cpp:
1517         (JSC::FTL::canCompile):
1518         * ftl/FTLLowerDFGToB3.cpp:
1519         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1520         (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
1521         * interpreter/Interpreter.cpp:
1522         (JSC::Interpreter::execute):
1523         * jit/JIT.cpp:
1524         (JSC::JIT::privateCompileMainPass):
1525         * jit/JIT.h:
1526         * jit/JITOperations.h:
1527         * jit/JITPropertyAccess.cpp:
1528         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
1529         * jit/JITPropertyAccess32_64.cpp:
1530         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
1531         * llint/LowLevelInterpreter.asm:
1532         * parser/Parser.cpp:
1533         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
1534         * parser/Parser.h:
1535         (JSC::Scope::getSloppyModeHoistedFunctions):
1536         (JSC::Parser::declareFunction):
1537         * runtime/CommonSlowPaths.cpp:
1538         (JSC::SLOW_PATH_DECL):
1539         * runtime/CommonSlowPaths.h:
1540         * runtime/EvalExecutable.h:
1541         (JSC::EvalExecutable::numFunctionHoistingCandidates):
1542         (JSC::EvalExecutable::numTopLevelFunctionDecls):
1543         (JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
1544         * runtime/JSScope.cpp:
1545         (JSC::JSScope::resolve):
1546         (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
1547         * runtime/JSScope.h:
1548
1549 2017-04-18  Saam Barati  <sbarati@apple.com>
1550
1551         Follow up to address Mark's comments after r215453
1552
1553         Rubber stamped by Mark Lam.
1554
1555         This patch chooses better names for things, adhering to Mark's suggestions
1556         in https://bugs.webkit.org/show_bug.cgi?id=139847
1557
1558         * bytecompiler/NodesCodegen.cpp:
1559         (JSC::CallFunctionCallDotNode::emitBytecode):
1560         (JSC::ApplyFunctionCallDotNode::emitBytecode):
1561         * parser/NodeConstructors.h:
1562         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
1563         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
1564         * parser/Nodes.h:
1565         * parser/Parser.cpp:
1566         (JSC::recordCallOrApplyDepth):
1567         (JSC::Parser<LexerType>::parseMemberExpression):
1568         * parser/Parser.h:
1569         (JSC::Parser::CallOrApplyDepthScope::CallOrApplyDepthScope):
1570         (JSC::Parser::CallOrApplyDepthScope::distanceToInnermostChild):
1571         (JSC::Parser::CallOrApplyDepthScope::~CallOrApplyDepthScope):
1572         (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth): Deleted.
1573         (JSC::Parser::CallOrApplyDepth::maxChildDepth): Deleted.
1574         (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth): Deleted.
1575
1576 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1577
1578         [DFG] Convert ValueAdd(Int32, String) => MakeRope(ToString(Int32), String)
1579         https://bugs.webkit.org/show_bug.cgi?id=170943
1580
1581         Reviewed by Geoffrey Garen.
1582
1583         This patch converts ValueAdd(Int32, String) to MakeRope(ToString(Int32), String).
1584         This has 2 great features.
1585
1586         1. MakeRope(ToString(Int32), String) is less clobbering.
1587
1588         While ValueAdd ends up calling functions, VM knows much about MakeRope(ToString(Int32), String)
1589         and VM knows it is less clobbering. It encourages LICM and other operations that is conservatively
1590         executed because of ValueAdd's clobbering.
1591
1592         2. Simply, MakeRope(ToString(Int32), String) is faster than ValueAdd.
1593
1594         While ValueAdd ends up calling a generic function, our ToString(Int32) calls well-optimized toString
1595         operation. And later, MakeRope can fall into the fast path that just takes a string from a free list.
1596         It is simply faster than ValueAdd.
1597
1598         We ensure that this patch shows performance improvement in attached benchmarks.
1599
1600                                                         baseline                  patched
1601
1602             number-to-string-with-add-empty         16.2763+-3.3930     ^     10.3142+-1.0967        ^ definitely 1.5780x faster
1603             number-to-string-with-add-in-loop      168.7621+-10.9738    ^     15.5307+-3.3179        ^ definitely 10.8664x faster
1604             number-to-string-with-add               18.8557+-4.8292           11.6901+-2.5650          might be 1.6130x faster
1605
1606         In SixSpeed,
1607
1608                                                baseline                  patched
1609
1610             template_string_tag.es5       200.1027+-20.6871    ^     25.7925+-11.4052       ^ definitely 7.7582x faster
1611             template_string_tag.es6       331.3913+-12.1750    ^    286.6958+-26.0441       ^ definitely 1.1559x faster
1612             for-of-array.es5              412.4344+-23.2517    ^    272.8707+-47.2118       ^ definitely 1.5115x faster
1613             for-of-array.es6              504.0082+-65.5045    ^    300.3277+-12.8193       ^ definitely 1.6782x faster
1614
1615         * dfg/DFGFixupPhase.cpp:
1616         (JSC::DFG::FixupPhase::fixupNode):
1617         (JSC::DFG::FixupPhase::createToString):
1618         * dfg/DFGPredictionPropagationPhase.cpp:
1619
1620 2017-04-18  Michael Saboff  <msaboff@apple.com>
1621
1622         REGRESSION(215272): microbenchmark/seal-and-do-work and microbenchmark/freeze-and-do-work are 27x slower
1623         https://bugs.webkit.org/show_bug.cgi?id=170881
1624
1625         Reviewed by Saam Barati.
1626
1627         * runtime/ObjectConstructor.cpp:
1628         (JSC::objectConstructorSeal):
1629         (JSC::objectConstructorFreeze):
1630         Restored fast paths for final objects that don't have indexed properties.
1631
1632 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1633
1634         [DFG] Use Phantom for base instead of getter when inlining intrinsic getter
1635         https://bugs.webkit.org/show_bug.cgi?id=170947
1636
1637         Reviewed by Saam Barati.
1638
1639         getter does not need to be live after OSR Exit.
1640
1641         * dfg/DFGByteCodeParser.cpp:
1642         (JSC::DFG::ByteCodeParser::handleGetById):
1643
1644 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1645
1646         Unreviewed, follow-up patch after r215459
1647         https://bugs.webkit.org/show_bug.cgi?id=170940
1648
1649         Reviewed by Filip Pizlo.
1650
1651         CheckCell can cause OSRExit. Thus Phantom should be placed after CheckCell.
1652
1653         * dfg/DFGByteCodeParser.cpp:
1654         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
1655         (JSC::DFG::ByteCodeParser::handleGetById):
1656
1657 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1658
1659         [DFG] Drop unknown use of CheckCell's child2 to work ObjectAllocationSinking for Array iterator object
1660         https://bugs.webkit.org/show_bug.cgi?id=170940
1661
1662         Reviewed by Filip Pizlo.
1663
1664         The second argument of CheckCell is not used in meaningful way. It is just *use* the node.
1665         The problem is that it effectively *use* the child2 in ObjectAllocationSinking phase, and
1666         prevent us from eliminating object allocations. Actually, it materializes Array iterator
1667         when inlining `next()`. Instead, we should use Phantom in such a case.
1668
1669         It improves destructuring.es6 in SixSpeed 2.5x.
1670
1671         destructuring.es6      308.5184+-25.3490    ^    119.5680+-15.0520       ^ definitely 2.5803x faster
1672
1673         Note that SixSpeed tested in arewefastyet executes all the tests in one process while our SixSpeed
1674         tests each one in isolated way.
1675
1676         * dfg/DFGByteCodeParser.cpp:
1677         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
1678         (JSC::DFG::ByteCodeParser::handleGetById):
1679
1680 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1681
1682         [JSC][GTK] glib RunLoop does not accept negative start interval
1683         https://bugs.webkit.org/show_bug.cgi?id=170775
1684
1685         Reviewed by Saam Barati.
1686
1687         * heap/GCActivityCallback.cpp:
1688         (JSC::GCActivityCallback::scheduleTimer):
1689
1690 2017-04-17  Saam Barati  <sbarati@apple.com>
1691
1692         BytecodeGenerator ".call" and ".apply" is exponential in nesting depth
1693         https://bugs.webkit.org/show_bug.cgi?id=139847
1694         <rdar://problem/19321122>
1695
1696         Reviewed by Oliver Hunt.
1697
1698         The BytecodeGenerator's .apply(...) and .call(...) code would
1699         emit bytecode for the evaluation of its arguments twice. This
1700         is exponential, specifically, 2^n, where n is the nesting depth of
1701         .call(...) or .apply(...) inside other .call(...) or .apply(...).
1702         
1703         The reason we emit code for the arguments twice is that we try
1704         to emit efficient code for when .call or .apply is Function.prototype.call
1705         or Function.prototype.apply. Because of this, we compare .call/.apply to
1706         Function.prototype.call/.apply, and if they're the same, we emit a specialized
1707         function call in bytecode. Otherwise, we emit the generalized version.
1708         
1709         This patch makes it so that each .call(...) and .apply(...) records
1710         its max inner nesting depth. Then, we only perform the optimization
1711         for the bottom k (where k = 6) layers of the nesting tree. The reason we
1712         apply the optimization to the bottom k layers instead of top k layers
1713         is that we'll produce less code this way.
1714
1715         * bytecompiler/NodesCodegen.cpp:
1716         (JSC::CallFunctionCallDotNode::emitBytecode):
1717         (JSC::ApplyFunctionCallDotNode::emitBytecode):
1718         * parser/ASTBuilder.h:
1719         (JSC::ASTBuilder::makeFunctionCallNode):
1720         * parser/NodeConstructors.h:
1721         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
1722         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
1723         * parser/Nodes.h:
1724         * parser/Parser.cpp:
1725         (JSC::recordCallOrApplyDepth):
1726         (JSC::Parser<LexerType>::parseMemberExpression):
1727         * parser/Parser.h:
1728         (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth):
1729         (JSC::Parser::CallOrApplyDepth::maxChildDepth):
1730         (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth):
1731         * parser/SyntaxChecker.h:
1732         (JSC::SyntaxChecker::makeFunctionCallNode):
1733
1734 2017-04-17  Mark Lam  <mark.lam@apple.com>
1735
1736         JSArray::appendMemcpy() needs to handle copying from Undecided indexing type too.
1737         https://bugs.webkit.org/show_bug.cgi?id=170896
1738         <rdar://problem/31651319>
1739
1740         Reviewed by JF Bastien and Keith Miller.
1741
1742         * runtime/JSArray.cpp:
1743         (JSC::JSArray::appendMemcpy):
1744
1745 2017-04-17  Joseph Pecoraro  <pecoraro@apple.com>
1746
1747         Web Inspector: Doesn't show size of compressed content correctly
1748         https://bugs.webkit.org/show_bug.cgi?id=155112
1749         <rdar://problem/25006728>
1750
1751         Reviewed by Alex Christensen and Timothy Hatcher.
1752
1753         * inspector/protocol/Network.json:
1754         New, exact size metrics, available after the load completes.
1755
1756 2017-04-17  Youenn Fablet  <youenn@apple.com>
1757
1758         Disable outdated WritableStream API
1759         https://bugs.webkit.org/show_bug.cgi?id=170749
1760         <rdar://problem/31446233>
1761
1762         Reviewed by Alex Christensen.
1763
1764         * Configurations/FeatureDefines.xcconfig:
1765
1766 2017-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1767
1768         [JSCOnly] Fix build failures in macOS
1769         https://bugs.webkit.org/show_bug.cgi?id=170887
1770
1771         Reviewed by Alex Christensen.
1772
1773         Align ICU header configuration to MacCMake port.
1774
1775         * PlatformJSCOnly.cmake:
1776
1777 2017-04-17  JF Bastien  <jfbastien@apple.com>
1778
1779         B3: don't allow unsigned offsets in Value
1780         https://bugs.webkit.org/show_bug.cgi?id=170692
1781
1782         Reviewed by Filip Pizlo.
1783
1784         MemoryValue and similar B3 opcode classes always expects a signed
1785         offset. Giving it an out-of-bounds unsigned offset causes
1786         implementation-defined behavior, which can cause badness as I just
1787         fixed in WebAssembly.  This patch makes it impossible to create a
1788         Value opcodes with an unsigned value, or with an overly-large
1789         value.
1790
1791         * b3/B3AtomicValue.cpp:
1792         (JSC::B3::AtomicValue::AtomicValue):
1793         * b3/B3AtomicValue.h:
1794         * b3/B3Common.h:
1795         (JSC::B3::isRepresentableAs):
1796         * b3/B3EliminateCommonSubexpressions.cpp:
1797         * b3/B3LowerToAir.cpp:
1798         (JSC::B3::Air::LowerToAir::scaleForShl):
1799         (JSC::B3::Air::LowerToAir::effectiveAddr):
1800         (JSC::B3::Air::LowerToAir::addr):
1801         (JSC::B3::Air::LowerToAir::tryAppendLea):
1802         * b3/B3MemoryValue.cpp:
1803         (JSC::B3::MemoryValue::isLegalOffsetImpl):
1804         (JSC::B3::MemoryValue::MemoryValue):
1805         * b3/B3MemoryValue.h:
1806         * b3/B3MemoryValueInlines.h:
1807         (JSC::B3::MemoryValue::isLegalOffsetImpl):
1808         * b3/B3MoveConstants.cpp:
1809         * b3/B3ReduceStrength.cpp:
1810         * b3/B3StackmapSpecial.cpp:
1811         (JSC::B3::StackmapSpecial::repForArg):
1812         * b3/B3Value.h:
1813         * b3/air/AirArg.cpp:
1814         (JSC::B3::Air::Arg::stackAddrImpl):
1815         * b3/air/AirArg.h:
1816         (JSC::B3::Air::Arg::addr):
1817         (JSC::B3::Air::Arg::stack):
1818         (JSC::B3::Air::Arg::callArg):
1819         (JSC::B3::Air::Arg::stackAddr):
1820         (JSC::B3::Air::Arg::index):
1821         (JSC::B3::Air::Arg::offset):
1822         (JSC::B3::Air::Arg::isValidAddrForm):
1823         (JSC::B3::Air::Arg::isValidIndexForm):
1824         (JSC::B3::Air::Arg::asTrustedImm32):
1825         (JSC::B3::Air::Arg::asAddress):
1826         (JSC::B3::Air::Arg::asBaseIndex):
1827         * b3/air/AirLowerStackArgs.cpp:
1828         (JSC::B3::Air::lowerStackArgs):
1829         * b3/testb3.cpp:
1830         (JSC::B3::testMulArgStore):
1831         (JSC::B3::testStore32):
1832         (JSC::B3::testStoreConstant):
1833         (JSC::B3::testStoreConstantPtr):
1834         (JSC::B3::testStoreAddLoad32):
1835         (JSC::B3::testStoreAddLoadImm32):
1836         (JSC::B3::testStoreAddLoad8):
1837         (JSC::B3::testStoreAddLoadImm8):
1838         (JSC::B3::testStoreAddLoad16):
1839         (JSC::B3::testStoreAddLoadImm16):
1840         (JSC::B3::testStoreAddLoad64):
1841         (JSC::B3::testStoreAddLoadImm64):
1842         (JSC::B3::testStoreAddLoad32Index):
1843         (JSC::B3::testStoreAddLoadImm32Index):
1844         (JSC::B3::testStoreAddLoad64Index):
1845         (JSC::B3::testStoreAddLoadImm64Index):
1846         (JSC::B3::testStoreSubLoad):
1847         (JSC::B3::testStoreAddLoadInterference):
1848         (JSC::B3::testStoreAddAndLoad):
1849         (JSC::B3::testStoreNegLoad32):
1850         (JSC::B3::testStoreNegLoadPtr):
1851         (JSC::B3::testLoadOffset):
1852         (JSC::B3::testLoadOffsetNotConstant):
1853         (JSC::B3::testLoadOffsetUsingAdd):
1854         (JSC::B3::testLoadOffsetUsingAddInterference):
1855         (JSC::B3::testLoadOffsetUsingAddNotConstant):
1856         (JSC::B3::testStoreLoadStackSlot):
1857         (JSC::B3::testLoad):
1858         (JSC::B3::testInterpreter):
1859         (JSC::B3::testTrappingStore):
1860         (JSC::B3::testTrappingLoadAddStore):
1861         (JSC::B3::testWasmAddress):
1862         * wasm/WasmB3IRGenerator.cpp:
1863         (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
1864         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
1865         (JSC::Wasm::B3IRGenerator::emitLoadOp):
1866         (JSC::Wasm::B3IRGenerator::emitStoreOp):
1867
1868 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
1869
1870         test262: test262/test/built-ins/Object/prototype/toLocaleString/primitive_this_value.js
1871         https://bugs.webkit.org/show_bug.cgi?id=170882
1872
1873         Reviewed by Saam Barati.
1874
1875         * runtime/ObjectPrototype.cpp:
1876         (JSC::objectProtoFuncToLocaleString):
1877         We should be using the this value without ToObject conversion both when
1878         getting the potential accessor and calling it. In strict mode, the this
1879         value will remain its simple value, in non-strict it is still converted.
1880
1881 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
1882
1883         test262: test262/test/built-ins/isNaN/toprimitive-not-callable-throws.js
1884         https://bugs.webkit.org/show_bug.cgi?id=170888
1885
1886         Reviewed by Saam Barati.
1887
1888         * runtime/ExceptionHelpers.h:
1889         * runtime/ExceptionHelpers.cpp:
1890         (JSC::createInvalidInstanceofParameterErrorHasInstanceValueNotFunction):
1891         Fix up this function name.
1892
1893         * runtime/JSObject.cpp:
1894         (JSC::callToPrimitiveFunction):
1895         When called with @@isPrimitive, bail on undefined or null and
1896         throw a type error if the value is not callable.
1897
1898         (JSC::JSObject::toPrimitive):
1899         Use throw scope to check for exception.
1900
1901 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
1902
1903         test262: test262/test/language/expressions/tagged-template/template-object.js
1904         https://bugs.webkit.org/show_bug.cgi?id=170878
1905
1906         Reviewed by Saam Barati.
1907
1908         * runtime/JSArray.cpp:
1909         (JSC::JSArray::put):
1910         The fast path for setting an Array's length should check if length is
1911         writable before checking for and possibly throwing a RangeError.
1912
1913 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
1914
1915         test262: test262/test/built-ins/Object/getOwnPropertyNames/15.2.3.4-4-44.js
1916         https://bugs.webkit.org/show_bug.cgi?id=170879
1917
1918         Reviewed by Saam Barati.
1919
1920         * runtime/StringObject.h:
1921         * runtime/StringObject.cpp:
1922         (JSC::StringObject::getOwnPropertyNames):
1923         (JSC::StringObject::getOwnNonIndexPropertyNames):
1924         Ensure 'length' comes after all indexed properties by moving
1925         it out to the getOwnNonIndexPropertyNames method which is called
1926         inside of getOwnPropertyNames after JSObject handles indices.
1927
1928 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
1929
1930         test262: test262/test/built-ins/Date/prototype/Symbol.toPrimitive/name.js
1931         https://bugs.webkit.org/show_bug.cgi?id=170884
1932
1933         Reviewed by Yusuke Suzuki.
1934
1935         * runtime/DatePrototype.cpp:
1936         (JSC::DatePrototype::finishCreation):
1937         * runtime/FunctionPrototype.cpp:
1938         (JSC::FunctionPrototype::addFunctionProperties):
1939         * runtime/RegExpPrototype.cpp:
1940         (JSC::RegExpPrototype::finishCreation):
1941         * runtime/SymbolPrototype.cpp:
1942         (JSC::SymbolPrototype::finishCreation):
1943         Give symbol property functions proper function names.
1944         This addresses function.name but not function.toString().
1945
1946 2017-04-15  Joseph Pecoraro  <pecoraro@apple.com>
1947
1948         test262: test262/test/language/global-code/new.target-arrow.js
1949         https://bugs.webkit.org/show_bug.cgi?id=170872
1950
1951         Reviewed by Saam Barati.
1952
1953         * parser/Parser.cpp:
1954         (JSC::Parser<LexerType>::Parser):
1955         Mark the global code scope.
1956
1957         (JSC::Parser<LexerType>::parseMemberExpression):
1958         If new.target is detected in an arrow function defined in global scope
1959         throw a SyntaxError.
1960
1961         * parser/Parser.h:
1962         (JSC::Scope::Scope):
1963         (JSC::Scope::setIsGlobalCodeScope):
1964         (JSC::Scope::isGlobalCodeScope):
1965         Marker for a global code scope.
1966
1967         * parser/ParserModes.h:
1968         (JSC::isModuleParseMode):
1969         (JSC::isProgramParseMode):
1970         (JSC::isProgramOrModuleParseMode):
1971         Helper for detecting global code based on parse mode.
1972
1973 2017-04-14  Nikita Vasilyev  <nvasilyev@apple.com>
1974
1975         Web Inspector: WebSockets: messages with non-latin letters are displayed incorrectly
1976         https://bugs.webkit.org/show_bug.cgi?id=170760
1977
1978         Reviewed by Joseph Pecoraro.
1979
1980         Add payloadLength property, which is used to display size. When payloadLength is unavailable,
1981         it is calculated from payloadData by Web Inspector frontend.
1982
1983         This fixes <webkit.org/b/170609> Web Inspector: WebSockets: Transferred size is incorrect.
1984
1985         * inspector/protocol/Network.json:
1986
1987 2017-04-14  Saam Barati  <sbarati@apple.com>
1988
1989         ParseInt intrinsic in DFG backend doesn't properly flush its operands
1990         https://bugs.webkit.org/show_bug.cgi?id=170865
1991
1992         Reviewed by Mark Lam and Geoffrey Garen.
1993
1994         The DFG backend code needed to first call .gpr()/.jsValueRegs()
1995         before calling flushRegisters(), or the input JSValueOperand would
1996         not be flushed.
1997
1998         * dfg/DFGSpeculativeJIT.cpp:
1999         (JSC::DFG::SpeculativeJIT::compileParseInt):
2000
2001 2017-04-14  Mark Lam  <mark.lam@apple.com>
2002
2003         Update architectures in xcconfig files.
2004         https://bugs.webkit.org/show_bug.cgi?id=170867
2005         <rdar://problem/31628104>
2006
2007         Reviewed by Joseph Pecoraro.
2008
2009         * Configurations/Base.xcconfig:
2010         * Configurations/FeatureDefines.xcconfig:
2011         * Configurations/JavaScriptCore.xcconfig:
2012         * Configurations/ToolExecutable.xcconfig:
2013
2014 2017-04-14  Keith Miller  <keith_miller@apple.com>
2015
2016         WebAssembly: B3IRGenerator should use phis for result types
2017         https://bugs.webkit.org/show_bug.cgi?id=170863
2018
2019         Reviewed by Filip Pizlo.
2020
2021         Currently, we use variables for the result types of control flow in
2022         Wasm. We did this originally since we weren't sure that the phis we
2023         generated would be optimal. Since then, we have verified that the edges
2024         in wasm control flow ensure that each upsilon will dominate its phi
2025         so we don't need to use variables.
2026
2027         * wasm/WasmB3IRGenerator.cpp:
2028         (JSC::Wasm::B3IRGenerator::ControlData::ControlData):
2029         (JSC::Wasm::B3IRGenerator::addTopLevel):
2030         (JSC::Wasm::B3IRGenerator::addBlock):
2031         (JSC::Wasm::B3IRGenerator::addLoop):
2032         (JSC::Wasm::B3IRGenerator::unify):
2033
2034 2017-04-14  Alex Christensen  <achristensen@webkit.org>
2035
2036         Fix Windows build after r215368.
2037         https://bugs.webkit.org/show_bug.cgi?id=170641
2038
2039         * CMakeLists.txt:
2040         Add new directory containing files needed in WebCore.
2041
2042 2017-04-14  Caitlin Potter  <caitp@igalia.com>
2043
2044         [JSC] use ExpressionErrorClassifier for AwaitExpression operand
2045         https://bugs.webkit.org/show_bug.cgi?id=170844
2046
2047         Reviewed by Saam Barati.
2048
2049         In parseAssignmentExpression(), several cover grammars are handled, and
2050         use ExpressionErrorClassifier to record hints about which grammars to
2051         try.
2052
2053         In parseAwaitExpression(), the hints recorded during parsing of the
2054         operand need to be discarded, because if they propagate to the outer
2055         parseAssignmentExpression(), the hints will lead the parser down invalid
2056         branches that should be skipped.
2057
2058         This change adds an additional ExpressionErrorClassifier to
2059         parseAwaitExpression(), in order to discard hints recorded trying to
2060         parse the operand.
2061
2062         * parser/Parser.cpp:
2063         (JSC::Parser<LexerType>::parseAwaitExpression):
2064
2065 2017-04-14  Saam Barati  <sbarati@apple.com>
2066
2067         WebAssembly: There is a short window of time where a CodeBlock could be destroyed before all of its async compilation callbacks are called
2068         https://bugs.webkit.org/show_bug.cgi?id=170641
2069
2070         Reviewed by Keith Miller.
2071
2072         There is an unlikely race when a CodeBlock compilation fails,
2073         the module compiles a new CodeBlock for that memory mode, all while
2074         the CodeBlock is notifying its callbacks that it has finished.
2075         There is a chance that the Module could deref its failed CodeBlock 
2076         at that point, destroying it, before the callbacks were able to
2077         grab a Ref to the CodeBlock. This patch fixes the race by having the
2078         callbacks ref the CodeBlock.
2079
2080         This patch also has the Plan clear out all of its callbacks
2081         once it gets completed. This adds an extra defense to anybody
2082         that grabs refs to the Plan in the callback.
2083
2084         * wasm/WasmCodeBlock.cpp:
2085         (JSC::Wasm::CodeBlock::CodeBlock):
2086         (JSC::Wasm::CodeBlock::compileAsync):
2087         * wasm/WasmPlan.cpp:
2088         (JSC::Wasm::Plan::complete):
2089
2090 2017-04-13  Filip Pizlo  <fpizlo@apple.com>
2091
2092         Air::RegLiveness should be constraint-based
2093         https://bugs.webkit.org/show_bug.cgi?id=170817
2094
2095         Reviewed by Saam Barati.
2096         
2097         Previously, I changed the Air liveness analyses based on Air::Liveness<> to be
2098         constraint-based and this was a significant speed-up. Now I'm adding the same
2099         functionality to RegLiveness.
2100         
2101         This is a 1% speed-up on wasm B3 -O1 compile times.
2102         
2103         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
2104         * b3/air/AirLivenessAdapter.h:
2105         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
2106         (JSC::B3::Air::LivenessAdapter::prepareToCompute):
2107         (JSC::B3::Air::LivenessAdapter::actionsAt):
2108         * b3/air/AirRegLiveness.cpp:
2109         (JSC::B3::Air::RegLiveness::RegLiveness):
2110         (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::LocalCalcForUnifiedTmpLiveness):
2111         (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::execute):
2112         (JSC::B3::Air::RegLiveness::LocalCalc::execute): Deleted.
2113         * b3/air/AirRegLiveness.h:
2114         (JSC::B3::Air::RegLiveness::Actions::Actions):
2115         (JSC::B3::Air::RegLiveness::LocalCalcBase::LocalCalcBase):
2116         (JSC::B3::Air::RegLiveness::LocalCalcBase::live):
2117         (JSC::B3::Air::RegLiveness::LocalCalcBase::isLive):
2118         (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
2119         (JSC::B3::Air::RegLiveness::LocalCalc::execute):
2120         (JSC::B3::Air::RegLiveness::LocalCalc::live): Deleted.
2121         (JSC::B3::Air::RegLiveness::LocalCalc::isLive): Deleted.
2122
2123 2017-04-13  JF Bastien  <jfbastien@apple.com>
2124
2125         WebAssembly: fix windows build
2126         https://bugs.webkit.org/show_bug.cgi?id=170832
2127
2128         Reviewed by Mark Lam.
2129
2130         My previous patch re-declared isIOS which AssemblerCommon.h
2131         already provided, and which was already included by Options.cpp.
2132
2133         * runtime/Options.cpp:
2134
2135 2017-04-13  Saam Barati  <sbarati@apple.com>
2136
2137         WebAssembly: We should be able to postMessage a JSWebAssemblyModule
2138         https://bugs.webkit.org/show_bug.cgi?id=170573
2139
2140         Reviewed by Filip Pizlo.
2141
2142         This patch adds a callback to JSRunLoopTimer to notify
2143         clients that a timer has been set. This is used inside
2144         WorkerRunLoop in WebCore so that its RunLoop can perform
2145         an iteration when it sees that a timer got set.
2146
2147         * JavaScriptCore.xcodeproj/project.pbxproj:
2148         * runtime/JSRunLoopTimer.cpp:
2149         (JSC::JSRunLoopTimer::scheduleTimer):
2150         (JSC::JSRunLoopTimer::addTimerSetNotification):
2151         (JSC::JSRunLoopTimer::removeTimerSetNotification):
2152         * runtime/JSRunLoopTimer.h:
2153         * wasm/WasmCodeBlock.cpp:
2154         (JSC::Wasm::CodeBlock::~CodeBlock):
2155         * wasm/WasmCodeBlock.h:
2156         * wasm/WasmModule.cpp:
2157         (JSC::Wasm::Module::~Module):
2158         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
2159         (JSC::Wasm::makeValidationCallback):
2160         (JSC::Wasm::Module::validateSync):
2161         (JSC::Wasm::Module::validateAsync):
2162         (JSC::Wasm::Module::validateSyncImpl): Deleted.
2163         (JSC::Wasm::Module::makeValidationCallback): Deleted.
2164         * wasm/WasmModule.h:
2165         (JSC::Wasm::Module::validateSync): Deleted.
2166         (JSC::Wasm::Module::validateAsync): Deleted.
2167         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): Deleted.
2168         (JSC::Wasm::Module::nonNullCodeBlock): Deleted.
2169         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2170         (JSC::JSWebAssemblyCodeBlock::create):
2171         * wasm/js/JSWebAssemblyCodeBlock.h:
2172         (JSC::JSWebAssemblyCodeBlock::create): Deleted.
2173         * wasm/js/JSWebAssemblyModule.cpp:
2174         (JSC::JSWebAssemblyModule::source):
2175         * wasm/js/JSWebAssemblyModule.h:
2176         (JSC::JSWebAssemblyModule::source): Deleted.
2177         * wasm/js/WebAssemblyFunction.cpp:
2178         (JSC::callWebAssemblyFunction):
2179         * wasm/js/WebAssemblyModulePrototype.cpp:
2180
2181 2017-04-13  Mark Lam  <mark.lam@apple.com>
2182
2183         Should use flushDirect() when flushing the scopeRegister due to needsScopeRegister().
2184         https://bugs.webkit.org/show_bug.cgi?id=170661
2185         <rdar://problem/31579046>
2186
2187         Reviewed by Filip Pizlo.
2188
2189         Previously, we were using flush() to flush the outermost frame's scopeRegister.
2190         This is incorrect because flush() expects the VirtualRegister value passed to
2191         it to be that of the top most inlined frame.  In the event that we reach a
2192         terminal condition while inside an inlined frame, flush() will end up flushing
2193         the wrong register.  The fix is simply to use flushDirect() instead.
2194
2195         * dfg/DFGByteCodeParser.cpp:
2196         (JSC::DFG::ByteCodeParser::flush):
2197
2198 2017-04-13  Andy VanWagoner  <thetalecrafter@gmail.com>
2199
2200         Change Intl prototypes to plain objects
2201         https://bugs.webkit.org/show_bug.cgi?id=168178
2202
2203         Reviewed by JF Bastien.
2204
2205         * builtins/StringPrototype.js:
2206         (localeCompare): Create default Collator once instead of using prototype.
2207         * runtime/IntlCollatorPrototype.cpp:
2208         (JSC::IntlCollatorPrototype::IntlCollatorPrototype):
2209         * runtime/IntlCollatorPrototype.h:
2210         * runtime/IntlDateTimeFormatPrototype.cpp:
2211         (JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype):
2212         * runtime/IntlDateTimeFormatPrototype.h:
2213         * runtime/IntlNumberFormatPrototype.cpp:
2214         (JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype):
2215         * runtime/IntlNumberFormatPrototype.h:
2216         * runtime/IntlObject.cpp:
2217         (JSC::IntlObject::finishCreation): Don't set constructor on each prototype.
2218
2219 2017-04-13  Oliver Hunt  <oliver@apple.com>
2220
2221         allocationSize should use safe arithmetic by default
2222         https://bugs.webkit.org/show_bug.cgi?id=170804
2223
2224         Reviewed by JF Bastien.
2225
2226         Make all allocationSize() functions work in terms
2227         of Checked<size_t>
2228
2229         * runtime/DirectArguments.h:
2230         (JSC::DirectArguments::offsetOfSlot):
2231         (JSC::DirectArguments::allocationSize):
2232         * runtime/HashMapImpl.h:
2233         (JSC::HashMapBuffer::allocationSize):
2234         * runtime/JSArray.h:
2235         (JSC::JSArray::allocationSize):
2236         * runtime/JSArrayBufferView.h:
2237         (JSC::JSArrayBufferView::allocationSize):
2238         * runtime/JSAsyncFunction.h:
2239         (JSC::JSAsyncFunction::allocationSize):
2240         * runtime/JSFixedArray.h:
2241         (JSC::JSFixedArray::allocationSize):
2242         * runtime/JSFunction.h:
2243         (JSC::JSFunction::allocationSize):
2244         * runtime/JSGeneratorFunction.h:
2245         (JSC::JSGeneratorFunction::allocationSize):
2246         * runtime/JSModuleNamespaceObject.h:
2247         * runtime/JSObject.h:
2248         (JSC::JSFinalObject::allocationSize):
2249         * runtime/JSWrapperObject.h:
2250         (JSC::JSWrapperObject::allocationSize):
2251         * runtime/ScopedArguments.h:
2252         (JSC::ScopedArguments::allocationSize):
2253         * runtime/VM.h:
2254         (JSC::ScratchBuffer::allocationSize):
2255         * wasm/js/JSWebAssemblyCodeBlock.h:
2256         (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
2257         (JSC::JSWebAssemblyCodeBlock::allocationSize):
2258         * wasm/js/JSWebAssemblyInstance.h:
2259         (JSC::JSWebAssemblyInstance::allocationSize):
2260
2261 2017-04-13  JF Bastien  <jfbastien@apple.com>
2262
2263         WebAssembly: manage memory better
2264         https://bugs.webkit.org/show_bug.cgi?id=170628
2265
2266         Reviewed by Keith Miller, Michael Saboff.
2267
2268         WebAssembly fast memories weren't managed very well. This patch
2269         refactors it and puts us in a good position to further improve our
2270         fast memory handling in the future.
2271
2272         We now cache fast memories at a process granularity, but make sure
2273         that they don't consume dirty pages. We add a cap to the total
2274         number of allocated fast memories to avoid ASLR degradation.
2275
2276         We teach the GC about memories as a kind of resource it should
2277         care about because it didn't have visibility into the amount of
2278         memory each represented. This allows benchmarks which allocate
2279         memories back-to-back to reliably get fast memories 100% of the
2280         time, even on a system under load, which wasn't the case
2281         before. This reliability yields roughly 8% perf bump on x86-64
2282         WasmBench.
2283
2284         The GC heuristic is as follows: each time we allocate a fast
2285         memory we notify the GC, which then keeps track of the total
2286         number of fast memories allocated since it last GC'd. We
2287         separately keep track of the total number of fast memories which
2288         have ever existed at any point in time (cached + allocated). This
2289         is a monotonically-increasing high watermark. The GC will force a
2290         full collection if, since it last ran, half or more of the high
2291         watermark of fast memories was allocated.
2292
2293         At the same time, if we fail obtaining a fast memory from the
2294         cache we do a GC to try to find one. If that fails we'll allocate
2295         a new one (this can also fail, then we go to slow memory). This
2296         can also be improved, but it's a good start.
2297
2298         This currently disables fast memories on iOS because getting fast
2299         memories isn't a guaranteed thing. Rather, we get quite a few of
2300         them and achieve significant speedups, but benchmarks which
2301         allocate memories back-to-back end up falling behind because the
2302         GC can conservatively hold onto memories, which then yields a perf
2303         cliff. That cliff isn't reliable, WasmBench gets roughly 10 of 18
2304         fast memories when in theory it should get all of them fast (as
2305         MacOS does). The patch significantly improves the state of iOS
2306         though, and in a follow-up we could re-enable fast memories.
2307
2308         Part of this good positioning is a facility to pre-allocate fast
2309         memories very early at startup, before any fragmentation
2310         occurs. This is currently disabled but worked extremely reliably
2311         on iOS. Once we fix the above issues we'll want to re-visit and
2312         turn on pre-allocation.
2313
2314         We also avoid locking for fast memory identification when
2315         performing signal handling. I'm very nervous about acquiring locks
2316         in a signal handler because in general signals can happen when
2317         we've messed up. This isn't the case with fast memories: we're
2318         raising a signal on purpose and handling it. However this doesn't
2319         mean we won't mess up elsewhere! This will get more complicated
2320         once we add support for multiple threads sharing memories and
2321         being able to grow their memories. One example: the code calls
2322         CRASH(), which executes the following code in release:
2323
2324             *(int *)(uintptr_t)0xbbadbeef = 0;
2325
2326         This is a segfault, which our fast memory signal handler tries to
2327         handle. It does so by first figuring out whether 0xbbadbeef is in
2328         a fast memory region, reqiring a lock. If we CRASH() while holding
2329         the lock then our thread self-deadlocks, giving us no crash report
2330         and a bad user experience.
2331
2332         Avoiding a lock therefore it's not about speed or reduced
2333         contention. In fact, I'd use something else than a FIFO if these
2334         were a concern. We're also doing syscalls, which dwarf any locking
2335         cost.
2336
2337         We now only allocate 4GiB + redzone of 64k * 128 for fast memories
2338         instead of 8GiB. This patch reuses the logic from
2339         B3::WasmBoundsCheck to perform bounds checks when accesses could
2340         exceed the redzone. We'll therefore benefit from CSE goodness when
2341         it reaches WasmBoundsCheck. See bug #163469.
2342
2343         * b3/B3LowerToAir.cpp: fix a baaaaddd bug where unsigned->signed
2344         conversion allowed out-of-bounds reads by -2GiB. I'll follow-up in
2345         bug #170692 to prevent this type of bug once and for all.
2346         (JSC::B3::Air::LowerToAir::lower):
2347         * b3/B3Validate.cpp: update WasmBoundsCheck validation.
2348         * b3/B3Value.cpp:
2349         (JSC::B3::Value::effects): update WasmBoundsCheck effects.
2350         * b3/B3WasmBoundsCheckValue.cpp:
2351         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
2352         (JSC::B3::WasmBoundsCheckValue::redzoneLimit):
2353         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
2354         * b3/B3WasmBoundsCheckValue.h:
2355         (JSC::B3::WasmBoundsCheckValue::maximum):
2356         * b3/air/AirCustom.cpp:
2357         (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
2358         * b3/testb3.cpp:
2359         (JSC::B3::testWasmBoundsCheck):
2360         * heap/Heap.cpp:
2361         (JSC::Heap::Heap):
2362         (JSC::Heap::reportWebAssemblyFastMemoriesAllocated):
2363         (JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold):
2364         (JSC::Heap::updateAllocationLimits):
2365         (JSC::Heap::didAllocateWebAssemblyFastMemories):
2366         (JSC::Heap::shouldDoFullCollection):
2367         (JSC::Heap::collectIfNecessaryOrDefer):
2368         * heap/Heap.h:
2369         * runtime/InitializeThreading.cpp:
2370         (JSC::initializeThreading):
2371         * runtime/Options.cpp:
2372         * runtime/Options.h:
2373         * wasm/WasmB3IRGenerator.cpp:
2374         (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
2375         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2376         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
2377         (JSC::Wasm::B3IRGenerator::emitLoadOp):
2378         (JSC::Wasm::B3IRGenerator::emitStoreOp):
2379         (JSC::Wasm::createJSToWasmWrapper):
2380         * wasm/WasmFaultSignalHandler.cpp:
2381         (JSC::Wasm::trapHandler):
2382         * wasm/WasmMemory.cpp: Rewrite.
2383         (JSC::Wasm::makeString):
2384         (JSC::Wasm::Memory::initializePreallocations):
2385         (JSC::Wasm::Memory::createImpl):
2386         (JSC::Wasm::Memory::create):
2387         (JSC::Wasm::Memory::~Memory):
2388         (JSC::Wasm::Memory::fastMappedRedzoneBytes):
2389         (JSC::Wasm::Memory::fastMappedBytes):
2390         (JSC::Wasm::Memory::maxFastMemoryCount):
2391         (JSC::Wasm::Memory::addressIsInActiveFastMemory):
2392         (JSC::Wasm::Memory::grow):
2393         * wasm/WasmMemory.h:
2394         (Memory::maxFastMemoryCount):
2395         (Memory::addressIsInActiveFastMemory):
2396         * wasm/js/JSWebAssemblyInstance.cpp:
2397         (JSC::JSWebAssemblyInstance::finishCreation):
2398         (JSC::JSWebAssemblyInstance::visitChildren):
2399         (JSC::JSWebAssemblyInstance::globalMemoryByteSize):
2400         * wasm/js/JSWebAssemblyInstance.h:
2401         * wasm/js/JSWebAssemblyMemory.cpp:
2402         (JSC::JSWebAssemblyMemory::grow):
2403         (JSC::JSWebAssemblyMemory::finishCreation):
2404         (JSC::JSWebAssemblyMemory::visitChildren):
2405
2406 2017-04-13  Yusuke Suzuki  <utatane.tea@gmail.com>
2407
2408         [JSC] Use proper ifdef guard for code using MachineContext
2409         https://bugs.webkit.org/show_bug.cgi?id=170800
2410
2411         Reviewed by Carlos Alberto Lopez Perez.
2412
2413         This patch drops MachineContext use if it is not available.
2414         This situation can be considered like, building WebKit with musl.
2415         In that case, we simply disable features that rely on MachineContext.
2416         Examples are wasm fast memory, sampling profiler, and code profiling.
2417
2418         * runtime/Options.cpp:
2419         (JSC::overrideDefaults):
2420         * tools/CodeProfiling.cpp:
2421         (JSC::CodeProfiling::begin):
2422         (JSC::CodeProfiling::end):
2423         Previously, PLATFORM(GTK) is excluded. But it is not obvious why it is excluded.
2424         This patch just includes such platforms.
2425
2426         * wasm/WasmFaultSignalHandler.cpp:
2427         (JSC::Wasm::enableFastMemory):
2428
2429 2017-04-12  Dan Bernstein  <mitz@apple.com>
2430
2431         [Mac] Future-proof .xcconfig files
2432         https://bugs.webkit.org/show_bug.cgi?id=170802
2433
2434         Reviewed by Tim Horton.
2435
2436         * Configurations/Base.xcconfig:
2437         * Configurations/DebugRelease.xcconfig:
2438         * Configurations/FeatureDefines.xcconfig:
2439         * Configurations/Version.xcconfig:
2440
2441 2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>
2442
2443         test262: test262/test/built-ins/NativeErrors/EvalError/proto.js
2444         https://bugs.webkit.org/show_bug.cgi?id=170668
2445
2446         Reviewed by Keith Miller.
2447
2448         * runtime/JSGlobalObject.cpp:
2449         (JSC::JSGlobalObject::init):
2450         The [[Prototype]] of NativeError Constructor's should be the %Error%.
2451         https://tc39.github.io/ecma262/#sec-properties-of-the-nativeerror-constructors
2452
2453 2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>
2454
2455         test262: test262/test/language/literals/regexp/u-dec-esc.js
2456         https://bugs.webkit.org/show_bug.cgi?id=170687
2457
2458         Reviewed by Michael Saboff.
2459
2460         * yarr/YarrParser.h:
2461         (JSC::Yarr::Parser::parseEscape):
2462         * yarr/YarrPattern.cpp:
2463         (JSC::Yarr::YarrPattern::errorMessage):
2464         (JSC::Yarr::YarrPattern::compile):
2465         * yarr/YarrPattern.h:
2466         In unicoe patterns, invalid backreferences are an error.
2467
2468 2017-04-12  Filip Pizlo  <fpizlo@apple.com>
2469
2470         Move common stack allocation utilities out of AirAllocateStackByGraphColoring.cpp
2471         https://bugs.webkit.org/show_bug.cgi?id=170799
2472
2473         Reviewed by Michael Saboff and Keith Miller.
2474         
2475         When I added stack allocation to allocateRegistersByLinearScan, I reused a handful of
2476         utility functions from AirAllocateStackByGraphColoring.cpp. I accomplished this by
2477         putting their declarations in AirAllocateStackByGraphColoring.h.
2478         
2479         That was pretty weird.
2480         
2481         This patch moves a family of stack allocation helper functions out of
2482         AirAllocateStackByGraphColoring.cpp and into the new AirStackAllocation.h|cpp. The
2483         linear scan stack allocator no longer has to include the other stack allocator's
2484         header, which addresses my OCD.
2485         
2486         I moved the functions transitively reachable from the two functions that the linear
2487         scan allocator needed. This forced me to give them better names (i.e. no "fooBarImpl")
2488         and short descriptive comments. I think that such comments are useful in code that is
2489         doing a convoluted version of some theoretical concept.
2490         
2491         No behavior change.
2492
2493         * CMakeLists.txt:
2494         * JavaScriptCore.xcodeproj/project.pbxproj:
2495         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
2496         * b3/air/AirAllocateStackByGraphColoring.cpp:
2497         (JSC::B3::Air::allocateStackByGraphColoring):
2498         (JSC::B3::Air::allocateEscapedStackSlots): Deleted.
2499         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): Deleted.
2500         * b3/air/AirAllocateStackByGraphColoring.h:
2501         * b3/air/AirStackAllocation.cpp: Added.
2502         (JSC::B3::Air::attemptAssignment):
2503         (JSC::B3::Air::assign):
2504         (JSC::B3::Air::allocateAndGetEscapedStackSlotsWithoutChangingFrameSize):
2505         (JSC::B3::Air::allocateEscapedStackSlots):
2506         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
2507         * b3/air/AirStackAllocation.h: Added.
2508
2509 2017-04-12  Filip Pizlo  <fpizlo@apple.com>
2510
2511         B3 -O1 should not allocateStackByGraphColoring
2512         https://bugs.webkit.org/show_bug.cgi?id=170742
2513
2514         Reviewed by Keith Miller.
2515         
2516         One of B3 -O1's longest running phases is allocateStackByGraphColoring. One approach to
2517         this would be to make that phase cheaper. But it's weird that this phase reruns
2518         liveness after register allocation already ran liveness. If only it could reuse the
2519         liveness computed by register allocation then it would run a lot faster. At -O2, we do
2520         not want this, since we run phases between register allocation and stack allocation,
2521         and those phases are free to change the liveness of spill slots (in fact,
2522         fixObviousSpills will both shorten and lengthen live ranges because of load and store
2523         elimination, respectively). But at -O1, we don't really need to run any phases between
2524         register and stack allocation.
2525         
2526         This changes Air's backend in the following ways:
2527         
2528         - Linear scan does stack allocation. This means that we don't need to run
2529           allocateStackByGraphColoring at all. In reality, we reuse some of its innards, but
2530           we don't run the expensive part of it (liveness->interference->coalescing->coloring).
2531           This is a speed-up because we only run liveness once and reuse it for both register
2532           and stack allocation.
2533         
2534         - Phases that previously ran between register and stack allocation are taken care of,
2535           each in its own special way:
2536           
2537           -> handleCalleSaves: this is now a utility function called by both
2538              allocateStackByGraphColoring and allocateRegistersAndStackByLinearScan.
2539           
2540           -> fixObviousSpills: we didn't run this at -O1, so nothing needs to be done.
2541           
2542           -> lowerAfterRegAlloc: this needed to be able to run before stack allocation because
2543              it could change register usage (vis a vis callee saves) and it could introduce
2544              spill slots. I changed this phase to have a secondary mode for when it runs after
2545              stack allocation.
2546         
2547         - The part of allocateStackByGraphColoring that lowered stack addresses and took care
2548           of the call arg area is now a separate phase called lowerStackArgs. We run this phase
2549           regardless of optimization level. It's a cheap and general lowering.
2550         
2551         This also removes spillEverything, because we never use that phase, we never test it,
2552         and it got in the way in this refactoring.
2553         
2554         This is a 21% speed-up on wasm -O1 compile times. This does not significantly change
2555         -O1 throughput. We had already disabled allocateStack's most important optimization
2556         (spill coalescing). This probably regresses average stack frame size, but I didn't
2557         measure by how much. Stack frame size is really not that important. The algorithm in
2558         allocateStackByGraphColoring is about much more than optimal frame size; it also
2559         tries to avoid having to zero-extend 32-bit spills, it kills dead code, and of course
2560         it coalesces.
2561
2562         * CMakeLists.txt:
2563         * JavaScriptCore.xcodeproj/project.pbxproj:
2564         * b3/B3Procedure.cpp:
2565         (JSC::B3::Procedure::calleeSaveRegisterAtOffsetList):
2566         (JSC::B3::Procedure::calleeSaveRegisters): Deleted.
2567         * b3/B3Procedure.h:
2568         * b3/B3StackmapGenerationParams.cpp:
2569         (JSC::B3::StackmapGenerationParams::unavailableRegisters):
2570         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.cpp.
2571         (JSC::B3::Air::allocateRegistersAndStackByLinearScan):
2572         (JSC::B3::Air::allocateRegistersByLinearScan): Deleted.
2573         * b3/air/AirAllocateRegistersAndStackByLinearScan.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.h.
2574         * b3/air/AirAllocateRegistersByLinearScan.cpp: Removed.
2575         * b3/air/AirAllocateRegistersByLinearScan.h: Removed.
2576         * b3/air/AirAllocateStackByGraphColoring.cpp:
2577         (JSC::B3::Air::allocateEscapedStackSlots):
2578         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
2579         (JSC::B3::Air::allocateStackByGraphColoring):
2580         * b3/air/AirAllocateStackByGraphColoring.h:
2581         * b3/air/AirArg.cpp:
2582         (JSC::B3::Air::Arg::stackAddr):
2583         * b3/air/AirArg.h:
2584         (JSC::B3::Air::Arg::stackAddr): Deleted.
2585         * b3/air/AirCode.cpp:
2586         (JSC::B3::Air::Code::addStackSlot):
2587         (JSC::B3::Air::Code::setCalleeSaveRegisterAtOffsetList):
2588         (JSC::B3::Air::Code::calleeSaveRegisterAtOffsetList):
2589         (JSC::B3::Air::Code::dump):
2590         * b3/air/AirCode.h:
2591         (JSC::B3::Air::Code::setStackIsAllocated):
2592         (JSC::B3::Air::Code::stackIsAllocated):
2593         (JSC::B3::Air::Code::calleeSaveRegisters):
2594         * b3/air/AirGenerate.cpp:
2595         (JSC::B3::Air::prepareForGeneration):
2596         (JSC::B3::Air::generate):
2597         * b3/air/AirHandleCalleeSaves.cpp:
2598         (JSC::B3::Air::handleCalleeSaves):
2599         * b3/air/AirHandleCalleeSaves.h:
2600         * b3/air/AirLowerAfterRegAlloc.cpp:
2601         (JSC::B3::Air::lowerAfterRegAlloc):
2602         * b3/air/AirLowerStackArgs.cpp: Added.
2603         (JSC::B3::Air::lowerStackArgs):
2604         * b3/air/AirLowerStackArgs.h: Added.
2605         * b3/testb3.cpp:
2606         (JSC::B3::testPinRegisters):
2607         * ftl/FTLCompile.cpp:
2608         (JSC::FTL::compile):
2609         * jit/RegisterAtOffsetList.h:
2610         * wasm/WasmB3IRGenerator.cpp:
2611         (JSC::Wasm::parseAndCompile):
2612
2613 2017-04-12  Michael Saboff  <msaboff@apple.com>
2614
2615         Implement Object.isFrozen() and Object.isSealed() per ECMA spec
2616         https://bugs.webkit.org/show_bug.cgi?id=170753
2617
2618         Reviewed by Mark Lam.
2619
2620         * runtime/ObjectConstructor.cpp:
2621         (JSC::testIntegrityLevel): Added local helper as described in the ECMA standard.
2622
2623         (JSC::objectConstructorSeal):
2624         (JSC::objectConstructorFreeze):
2625         Eliminated incomplete special handling of JSFinalObjects.
2626
2627         (JSC::objectConstructorIsSealed):
2628         (JSC::objectConstructorIsFrozen):
2629         Refactored to use the new testIntegrityLevel() helper.
2630
2631 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2632
2633         Use HAVE(MACHINE_CONTEXT) instead of USE(MACHINE_CONTEXT)
2634         https://bugs.webkit.org/show_bug.cgi?id=170770
2635
2636         Rubber stamped by Mark Lam.
2637
2638         * heap/MachineStackMarker.cpp:
2639         (JSC::MachineThreads::MachineThread::Registers::framePointer):
2640         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
2641         (JSC::MachineThreads::MachineThread::Registers::llintPC):
2642         * runtime/MachineContext.h:
2643         (JSC::MachineContext::stackPointer):
2644         (JSC::MachineContext::framePointer):
2645         (JSC::MachineContext::instructionPointer):
2646         (JSC::MachineContext::argumentPointer<1>):
2647         (JSC::MachineContext::llintInstructionPointer):
2648
2649 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2650
2651         [JSC] Clean up heap/MachineStackMarker by introducing USE(MACHINE_CONTEXT)
2652         https://bugs.webkit.org/show_bug.cgi?id=170770
2653
2654         Reviewed by Mark Lam.
2655
2656         We use USE(MACHINE_CONTEXT) to clean up runtime/MachineContext.h. And
2657         we clean up heap/MachineStackMarker.cpp by using MachineContext functions.
2658
2659         * heap/MachineStackMarker.cpp:
2660         (JSC::MachineThreads::MachineThread::Registers::stackPointer):
2661         (JSC::MachineThreads::MachineThread::Registers::framePointer):
2662         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
2663         (JSC::MachineThreads::MachineThread::Registers::llintPC):
2664         * heap/MachineStackMarker.h:
2665         * runtime/MachineContext.h:
2666         (JSC::MachineContext::stackPointer):
2667         (JSC::MachineContext::framePointer):
2668         (JSC::MachineContext::instructionPointer):
2669         (JSC::MachineContext::argumentPointer<1>):
2670         (JSC::MachineContext::llintInstructionPointer):
2671
2672 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2673
2674         [WTF] Introduce Thread class and use RefPtr<Thread> and align Windows Threading implementation semantics to Pthread one
2675         https://bugs.webkit.org/show_bug.cgi?id=170502
2676
2677         Reviewed by Mark Lam.
2678
2679         * API/tests/CompareAndSwapTest.cpp:
2680         (testCompareAndSwap):
2681         * JavaScriptCore.xcodeproj/project.pbxproj:
2682         * b3/air/testair.cpp:
2683         * b3/testb3.cpp:
2684         (JSC::B3::run):
2685         * bytecode/SuperSampler.cpp:
2686         (JSC::initializeSuperSampler):
2687         * dfg/DFGWorklist.cpp:
2688         * disassembler/Disassembler.cpp:
2689         * heap/Heap.cpp:
2690         (JSC::Heap::lastChanceToFinalize):
2691         (JSC::Heap::notifyIsSafeToCollect):
2692         * heap/Heap.h:
2693         * heap/MachineStackMarker.cpp:
2694         (JSC::MachineThreads::~MachineThreads):
2695         (JSC::MachineThreads::addCurrentThread):
2696         (JSC::MachineThreads::removeThread):
2697         (JSC::MachineThreads::removeThreadIfFound):
2698         (JSC::MachineThreads::MachineThread::MachineThread):
2699         (JSC::MachineThreads::MachineThread::getRegisters):
2700         (JSC::MachineThreads::MachineThread::Registers::stackPointer):
2701         (JSC::MachineThreads::MachineThread::Registers::framePointer):
2702         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
2703         (JSC::MachineThreads::MachineThread::Registers::llintPC):
2704         (JSC::MachineThreads::MachineThread::captureStack):
2705         (JSC::MachineThreads::tryCopyOtherThreadStack):
2706         (JSC::MachineThreads::tryCopyOtherThreadStacks):
2707         (pthreadSignalHandlerSuspendResume): Deleted.
2708         (JSC::threadData): Deleted.
2709         (JSC::MachineThreads::Thread::Thread): Deleted.
2710         (JSC::MachineThreads::Thread::createForCurrentThread): Deleted.
2711         (JSC::MachineThreads::Thread::operator==): Deleted.
2712         (JSC::MachineThreads::machineThreadForCurrentThread): Deleted.
2713         (JSC::MachineThreads::ThreadData::ThreadData): Deleted.
2714         (JSC::MachineThreads::ThreadData::~ThreadData): Deleted.
2715         (JSC::MachineThreads::ThreadData::suspend): Deleted.
2716         (JSC::MachineThreads::ThreadData::resume): Deleted.
2717         (JSC::MachineThreads::ThreadData::getRegisters): Deleted.
2718         (JSC::MachineThreads::ThreadData::Registers::stackPointer): Deleted.
2719         (JSC::MachineThreads::ThreadData::Registers::framePointer): Deleted.
2720         (JSC::MachineThreads::ThreadData::Registers::instructionPointer): Deleted.
2721         (JSC::MachineThreads::ThreadData::Registers::llintPC): Deleted.
2722         (JSC::MachineThreads::ThreadData::freeRegisters): Deleted.
2723         (JSC::MachineThreads::ThreadData::captureStack): Deleted.
2724         * heap/MachineStackMarker.h:
2725         (JSC::MachineThreads::MachineThread::suspend):
2726         (JSC::MachineThreads::MachineThread::resume):
2727         (JSC::MachineThreads::MachineThread::threadID):
2728         (JSC::MachineThreads::MachineThread::stackBase):
2729         (JSC::MachineThreads::MachineThread::stackEnd):
2730         (JSC::MachineThreads::threadsListHead):
2731         (JSC::MachineThreads::Thread::operator!=): Deleted.
2732         (JSC::MachineThreads::Thread::suspend): Deleted.
2733         (JSC::MachineThreads::Thread::resume): Deleted.
2734         (JSC::MachineThreads::Thread::getRegisters): Deleted.
2735         (JSC::MachineThreads::Thread::freeRegisters): Deleted.
2736         (JSC::MachineThreads::Thread::captureStack): Deleted.
2737         (JSC::MachineThreads::Thread::platformThread): Deleted.
2738         (JSC::MachineThreads::Thread::stackBase): Deleted.
2739         (JSC::MachineThreads::Thread::stackEnd): Deleted.
2740         * jit/ICStats.cpp:
2741         (JSC::ICStats::ICStats):
2742         (JSC::ICStats::~ICStats):
2743         * jit/ICStats.h:
2744         * jsc.cpp:
2745         (functionDollarAgentStart):
2746         (startTimeoutThreadIfNeeded):
2747         * runtime/JSLock.cpp:
2748         (JSC::JSLock::lock):
2749         * runtime/JSLock.h:
2750         (JSC::JSLock::ownerThread):
2751         (JSC::JSLock::currentThreadIsHoldingLock):
2752         * runtime/SamplingProfiler.cpp:
2753         (JSC::FrameWalker::isValidFramePointer):
2754         (JSC::SamplingProfiler::SamplingProfiler):
2755         (JSC::SamplingProfiler::createThreadIfNecessary):
2756         (JSC::SamplingProfiler::takeSample):
2757         * runtime/SamplingProfiler.h:
2758         * runtime/VM.h:
2759         (JSC::VM::ownerThread):
2760         * runtime/VMTraps.cpp:
2761         (JSC::findActiveVMAndStackBounds):
2762         (JSC::VMTraps::SignalSender::send):
2763         (JSC::VMTraps::fireTrap):
2764
2765 2017-04-11  Dean Jackson  <dino@apple.com>
2766
2767         Disable outdated WritableStream API
2768         https://bugs.webkit.org/show_bug.cgi?id=170749
2769         <rdar://problem/31446233>
2770
2771         Reviewed by Tim Horton.
2772
2773         The API we implement is no longer accurate. Disable it until we
2774         are compatible with the new specification
2775
2776         * Configurations/FeatureDefines.xcconfig:
2777
2778 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2779
2780         Unreviewed, build fix for CF ports after r215241
2781         https://bugs.webkit.org/show_bug.cgi?id=170725
2782
2783         * heap/GCActivityCallback.cpp:
2784         (JSC::GCActivityCallback::nextFireTime):
2785
2786 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2787
2788         [WebCore][JSC] ResourceUsageData.{timeOfNextEdenCollection,timeOfNextFullCollection} should be MonotonicTime
2789         https://bugs.webkit.org/show_bug.cgi?id=170725
2790
2791         Reviewed by Sam Weinig.
2792
2793         This patch makes GCActivityCallback return MonotonicTime instead of raw double value.
2794
2795         * heap/GCActivityCallback.cpp:
2796         (JSC::GCActivityCallback::nextFireTime):
2797         * heap/GCActivityCallback.h:
2798
2799 2017-04-11  Guillaume Emont  <guijemont@igalia.com>
2800
2801         [jsc] Add missing MacroAssemblerMIPS::or32() implementation
2802         https://bugs.webkit.org/show_bug.cgi?id=169714
2803
2804         Reviewed by Michael Catanzaro.
2805
2806         * assembler/MacroAssemblerMIPS.h:
2807         (JSC::MacroAssemblerMIPS::or32):
2808         Added or32(TrustedImm32, Address).
2809
2810 2017-04-11  Joseph Pecoraro  <pecoraro@apple.com>
2811
2812         test262: test262/test/annexB/language/comments/multi-line-html-close.js
2813         https://bugs.webkit.org/show_bug.cgi?id=170648
2814
2815         Reviewed by Keith Miller.
2816
2817         * parser/Lexer.cpp:
2818         (JSC::Lexer<T>::lex):
2819         A multi-line comment that contains a line terminator is itself treated
2820         like a line terminator. An HTML Close Comment that comes after it can
2821         therefore treat it like it is at the start of a line, because it was
2822         immediately preceeded by the equivalent of a line terminator.
2823
2824 2017-04-11  Joseph Pecoraro  <pecoraro@apple.com>
2825
2826         test262: test262/test/built-ins/Array/S15.4.3_A2.2.js
2827         https://bugs.webkit.org/show_bug.cgi?id=170652
2828
2829         Reviewed by Michael Saboff.
2830
2831         * runtime/ArrayConstructor.cpp:
2832         (JSC::ArrayConstructor::finishCreation):
2833         * runtime/BooleanConstructor.cpp:
2834         (JSC::BooleanConstructor::finishCreation):
2835         * runtime/DateConstructor.cpp:
2836         (JSC::DateConstructor::finishCreation):
2837         * runtime/FunctionConstructor.cpp:
2838         (JSC::FunctionConstructor::finishCreation):
2839         * runtime/JSArrayBufferConstructor.cpp:
2840         (JSC::JSArrayBufferConstructor::finishCreation):
2841         * runtime/NumberConstructor.cpp:
2842         (JSC::NumberConstructor::finishCreation):
2843         * runtime/ObjectConstructor.cpp:
2844         (JSC::ObjectConstructor::finishCreation):
2845         * runtime/RegExpConstructor.cpp:
2846         (JSC::RegExpConstructor::finishCreation):
2847         * runtime/StringConstructor.cpp:
2848         (JSC::StringConstructor::finishCreation):
2849         * runtime/SymbolConstructor.cpp:
2850         (JSC::SymbolConstructor::finishCreation):
2851         Ensure the "length" property on these native constructors is configurable (deletable).
2852
2853 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2854
2855         Unreviewed, build fix for Windows after r215228 part 2
2856         https://bugs.webkit.org/show_bug.cgi?id=170723
2857
2858         Since GCActivityCallback class is annotated exported, we do not need to annotate each member.
2859
2860         * heap/GCActivityCallback.h:
2861
2862 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2863
2864         [JSC][GTK] Use RunLoop::Timer in GTK port
2865         https://bugs.webkit.org/show_bug.cgi?id=170723
2866
2867         Reviewed by Carlos Garcia Campos.
2868
2869         This patch makes GTK port use RunLoop::Timer for JSRunLoopTimer.
2870         Only Cocoa-based ports use platform-specific Timer because it
2871         has additional feature that changes RunLoop to the WebThread one.
2872
2873         And we enable Heap timers in all the ports including JSCOnly port.
2874
2875         * heap/EdenGCActivityCallback.cpp:
2876         (JSC::EdenGCActivityCallback::lastGCLength):
2877         * heap/EdenGCActivityCallback.h:
2878         * heap/FullGCActivityCallback.cpp:
2879         (JSC::FullGCActivityCallback::lastGCLength):
2880         * heap/FullGCActivityCallback.h:
2881         * heap/GCActivityCallback.cpp:
2882         (JSC::GCActivityCallback::GCActivityCallback):
2883         (JSC::GCActivityCallback::doWork):
2884         (JSC::GCActivityCallback::scheduleTimer):
2885         (JSC::GCActivityCallback::cancelTimer):
2886         (JSC::GCActivityCallback::nextFireTime):
2887         (JSC::GCActivityCallback::didAllocate):
2888         * heap/GCActivityCallback.h:
2889         * heap/IncrementalSweeper.cpp:
2890         (JSC::IncrementalSweeper::doWork):
2891         (JSC::IncrementalSweeper::doSweep):
2892         * heap/IncrementalSweeper.h:
2893         * heap/StopIfNecessaryTimer.cpp:
2894         (JSC::StopIfNecessaryTimer::scheduleSoon):
2895         * runtime/JSRunLoopTimer.cpp:
2896         (JSC::JSRunLoopTimer::setRunLoop):
2897         (JSC::JSRunLoopTimer::scheduleTimer):
2898         (JSC::JSRunLoopTimer::cancelTimer):
2899         (JSC::JSRunLoopTimer::JSRunLoopTimer):
2900         (JSC::JSRunLoopTimer::~JSRunLoopTimer):
2901         (JSC::JSRunLoopTimer::timerDidFireCallback):
2902         * runtime/JSRunLoopTimer.h:
2903         * runtime/PromiseDeferredTimer.cpp:
2904         (JSC::PromiseDeferredTimer::scheduleWorkSoon):
2905
2906 2017-04-11  Guillaume Emont  <guijemont@igalia.com>
2907
2908         [jsc][mips] Add missing MacroAssembler functions after r214187
2909         https://bugs.webkit.org/show_bug.cgi?id=170089
2910
2911         Reviewed by Yusuke Suzuki.
2912
2913         * assembler/MacroAssemblerMIPS.h:
2914         (JSC::MacroAssemblerMIPS::loadFloat): Added.
2915         (JSC::MacroAssemblerMIPS::storeFloat): Added.
2916
2917 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2918
2919         [JSC] Enable JSRunLoopTimer for JSCOnly and Windows
2920         https://bugs.webkit.org/show_bug.cgi?id=170655
2921
2922         Reviewed by Carlos Garcia Campos.
2923
2924         * runtime/JSRunLoopTimer.cpp:
2925         (JSC::JSRunLoopTimer::JSRunLoopTimer):
2926         (JSC::JSRunLoopTimer::scheduleTimer):
2927         (JSC::JSRunLoopTimer::cancelTimer):
2928         * runtime/JSRunLoopTimer.h:
2929
2930 2017-04-10  Alex Christensen  <achristensen@webkit.org>
2931
2932         Revert r215217
2933         https://bugs.webkit.org/show_bug.cgi?id=170703
2934
2935         * Configurations/FeatureDefines.xcconfig:
2936
2937 2017-04-10  Alex Christensen  <achristensen@webkit.org>
2938
2939         Continue enabling WebRTC
2940         https://bugs.webkit.org/show_bug.cgi?id=170703
2941
2942         Reviewed by Youenn Fablet.
2943
2944         * Configurations/FeatureDefines.xcconfig:
2945
2946 2017-04-10  Mark Lam  <mark.lam@apple.com>
2947
2948         Move ProbeContext and ProbeFunction out of AbstractMacroAssembler.
2949         https://bugs.webkit.org/show_bug.cgi?id=170681
2950
2951         Reviewed by Michael Saboff.
2952
2953         This is a refactoring step towards enabling custom probe printers the way printInternal() works for dataLog.
2954
2955         * assembler/AbstractMacroAssembler.h:
2956         (JSC::AbstractMacroAssembler::ProbeContext::gpr): Deleted.
2957         (JSC::AbstractMacroAssembler::ProbeContext::fpr): Deleted.
2958         (JSC::AbstractMacroAssembler::ProbeContext::gprName): Deleted.
2959         (JSC::AbstractMacroAssembler::ProbeContext::fprName): Deleted.
2960         * assembler/MacroAssembler.cpp:
2961         (JSC::stdFunctionCallback):
2962         (JSC::MacroAssembler::probe):
2963         * assembler/MacroAssembler.h:
2964         (JSC::ProbeContext::gpr):
2965         (JSC::ProbeContext::fpr):
2966         (JSC::ProbeContext::gprName):
2967         (JSC::ProbeContext::fprName):
2968         * assembler/MacroAssemblerARM.cpp:
2969         (JSC::MacroAssemblerARM::probe):
2970         * assembler/MacroAssemblerARM64.cpp:
2971         (JSC::arm64ProbeTrampoline):
2972         (JSC::MacroAssemblerARM64::probe):
2973         * assembler/MacroAssemblerARMv7.cpp:
2974         (JSC::MacroAssemblerARMv7::probe):
2975         * assembler/MacroAssemblerPrinter.cpp:
2976         * assembler/MacroAssemblerPrinter.h:
2977         * assembler/MacroAssemblerX86Common.cpp:
2978         (JSC::MacroAssemblerX86Common::probe):
2979         * ftl/FTLLowerDFGToB3.cpp:
2980         (JSC::FTL::DFG::LowerDFGToB3::abstractStructure):
2981         (JSC::FTL::DFG::LowerDFGToB3::probe): Deleted.
2982         - Deleted because this became a useless place-holder after the transition to B3.
2983
2984 2017-04-10  Keith Miller  <keith_miller@apple.com>
2985
2986         WebAssembly: Fix B3IRGenerator for BrTable
2987         https://bugs.webkit.org/show_bug.cgi?id=170685
2988
2989         Reviewed by JF Bastien.
2990
2991         For some reason this didn't get included in r215141.
2992
2993         This fixes an issue with BrTable and loops where we would use the loop's return type
2994         as the branch target type.
2995
2996         * wasm/WasmB3IRGenerator.cpp:
2997         (JSC::Wasm::B3IRGenerator::ControlData::resultForBranch):
2998         (JSC::Wasm::B3IRGenerator::unifyValuesWithBlock):
2999
3000 2017-04-08  Oliver Hunt  <oliver@apple.com>
3001
3002         Remove use of strcpy from JSC
3003         https://bugs.webkit.org/show_bug.cgi?id=170646
3004
3005         Reviewed by Mark Lam.
3006
3007         Replace the use of strcpy with memcpy as strcpy keeps
3008         on tripping various analyser warnings even though its
3009         trivially safe in this case.
3010
3011         Essentially code hygiene, no change in behaviour, no
3012         perf impact.
3013
3014         * dfg/DFGDisassembler.cpp:
3015         (JSC::DFG::Disassembler::dumpDisassembly):
3016
3017 2017-04-09  Joseph Pecoraro  <pecoraro@apple.com>
3018
3019         test262: test262/test/annexB/language/expressions/object/__proto__-fn-name.js
3020         https://bugs.webkit.org/show_bug.cgi?id=170650
3021
3022         Reviewed by Saam Barati.
3023
3024         * parser/Parser.cpp:
3025         (JSC::Parser<LexerType>::parseClass):
3026         (JSC::Parser<LexerType>::parseProperty):
3027         There needs to be special handling of:
3028         
3029           PropertyDefinition :  PropertyName ':' AssignmentExpression
3030          
3031         When the property name is __proto__. In this case the
3032         SetFunctionName path does not happen, so the name "__proto__"
3033         is not inferred on any anonymous function. See:
3034         https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers
3035
3036         * parser/Parser.h:
3037         * parser/SyntaxChecker.h:
3038         (JSC::SyntaxChecker::createProperty):
3039         * parser/ASTBuilder.h:
3040         (JSC::ASTBuilder::createProperty):
3041         Add an extra parameter to see if inferring / setting names are allowed.
3042
3043 2017-04-09  Joseph Pecoraro  <pecoraro@apple.com>
3044
3045         test262: test262/test/annexB/language/literals/regexp/identity-escape.js
3046         https://bugs.webkit.org/show_bug.cgi?id=170651
3047
3048         Reviewed by Saam Barati.
3049
3050         * yarr/YarrParser.h:
3051         (JSC::Yarr::Parser::parseEscape):
3052         For \8 and \9 match just the number "8" or "9" instead of both "\\" and the number.
3053         See: https://tc39.github.io/ecma262/#sec-decimalescape
3054
3055 2017-04-08  Youenn Fablet  <youenn@apple.com>
3056
3057         WebRTC tests gardening
3058         https://bugs.webkit.org/show_bug.cgi?id=170508
3059
3060         Reviewed by Eric Carlson.
3061
3062         * Configurations/FeatureDefines.xcconfig:
3063
3064 2017-04-07  Keith Miller  <keith_miller@apple.com>
3065
3066         WebAssembly: Fix issue with BrTable targeting a Loop
3067         https://bugs.webkit.org/show_bug.cgi?id=170638
3068
3069         Reviewed by Saam Barati.
3070
3071         This fixes the same issue V8 had in: https://github.com/WebAssembly/spec/pull/456#event-1033547537
3072
3073         * wasm/WasmValidate.cpp:
3074         (JSC::Wasm::Validate::ControlData::branchTargetSignature):
3075
3076 2017-04-07  Keith Miller  <keith_miller@apple.com>
3077
3078         Add a PriorityQueue class
3079         https://bugs.webkit.org/show_bug.cgi?id=170579
3080
3081         Reviewed by Saam Barati.
3082
3083         Update Wasm::Worklist to use WTF::PriorityQueue.
3084
3085         * wasm/WasmWorklist.cpp:
3086         (JSC::Wasm::Worklist::enqueue):
3087         (JSC::Wasm::Worklist::completePlanSynchronously):
3088         (JSC::Wasm::Worklist::stopAllPlansForVM):
3089         (JSC::Wasm::Worklist::~Worklist):
3090         (JSC::Wasm::Worklist::iterate): Deleted.
3091         * wasm/WasmWorklist.h:
3092         (JSC::Wasm::Worklist::isHigherPriority):
3093         (JSC::Wasm::Worklist::Comparator::operator()): Deleted.
3094
3095 2017-04-07  Yuichiro Kikura  <y.kikura@gmail.com>
3096
3097         WebGPU: implement ComputeCommandEncoder and related components
3098         https://bugs.webkit.org/show_bug.cgi?id=170444
3099
3100         Reviewed by Alex Christensen.
3101
3102         I added some identifiers related with WebGPUComputeCommandEncoder based on the proposal.
3103         https://webkit.org/wp-content/uploads/webgpu-api-proposal.html
3104
3105         * runtime/CommonIdentifiers.h:
3106
3107 2017-04-07  Saam Barati  <sbarati@apple.com>
3108
3109         WebAssembly: Module::getOrCreateCodeBlock is wrong
3110         https://bugs.webkit.org/show_bug.cgi?id=170612
3111
3112         Reviewed by Keith Miller.
3113
3114         When we were getting a module's CodeBlock, we were checking if !runnable(),
3115         and if !runnable(), we were re-creating the CodeBlock. This is wrong, since
3116         !runnable() is true while the CodeBlock is compiling. Instead, we should check
3117         if we've finished compiling, and if so, if that compilation failed.
3118
3119         * wasm/WasmModule.cpp:
3120         (JSC::Wasm::Module::getOrCreateCodeBlock):
3121
3122 2017-04-07  Saam Barati  <sbarati@apple.com>
3123
3124         WebAssembly: Make to a compilation API that allows for multi-VM concurrent compilations of Wasm Modules
3125         https://bugs.webkit.org/show_bug.cgi?id=170488
3126
3127         Reviewed by JF Bastien.
3128
3129         This patch adds a class called Wasm::Module. It contains the bits from
3130         JSWebAssemblyModule that were not VM specific. JSWebAssemblyModule
3131         now has a Ref<Wasm::Module>. Similarly, there is now a Wasm::CodeBlock,
3132         which owns the non-VM-specific bits that JSWebAssemblyCodeBlock used
3133         to own.
3134         
3135         This patch also simplifies how we verify and compile code. Wasm::Module
3136         now has an API for both sync/async validation and compilation. This
3137         API abstracts away how Wasm::Plan works.
3138         
3139         This is hopefully the last patch needed before we can implement
3140         window.postMessage for a JSWebAssemblyModule. I think all that's
3141         needed now to implement postMessage is simply creating a new
3142         JSWebAssemblyModule with the underlying Wasm::Module.
3143         
3144         This patch is neutral on WasmBench.
3145         
3146         Finally, this patch changes the promise deferred timer to
3147         allow for new tasks to be added while we're executing
3148         a task. Before, we'd deadlock if this happened.
3149
3150         * CMakeLists.txt:
3151         * JavaScriptCore.xcodeproj/project.pbxproj:
3152         * jsc.cpp:
3153         (functionTestWasmModuleFunctions):
3154         * runtime/PromiseDeferredTimer.cpp:
3155         (JSC::PromiseDeferredTimer::doWork):
3156         (JSC::PromiseDeferredTimer::scheduleWorkSoon):
3157         * runtime/PromiseDeferredTimer.h:
3158         * wasm/WasmB3IRGenerator.cpp:
3159         * wasm/WasmBinding.cpp:
3160         (JSC::Wasm::wasmToJs):
3161         (JSC::Wasm::wasmToWasm):
3162         (JSC::Wasm::exitStubGenerator): Deleted.
3163         * wasm/WasmBinding.h:
3164         * wasm/WasmCodeBlock.cpp: Added.
3165         (JSC::Wasm::CodeBlock::CodeBlock):
3166         (JSC::Wasm::CodeBlock::waitUntilFinished):
3167         (JSC::Wasm::CodeBlock::compileAsync):
3168         (JSC::Wasm::CodeBlock::isSafeToRun):
3169         * wasm/WasmCodeBlock.h: Added.
3170         (JSC::Wasm::CodeBlock::create):
3171         (JSC::Wasm::CodeBlock::compilationFinished):
3172         (JSC::Wasm::CodeBlock::runnable):
3173         (JSC::Wasm::CodeBlock::errorMessage):
3174         (JSC::Wasm::CodeBlock::functionImportCount):
3175         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
3176         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
3177         * wasm/WasmModule.cpp: Added.
3178         (JSC::Wasm::Module::Module):
3179         (JSC::Wasm::makeValidationResult):
3180         (JSC::Wasm::Module::validateSyncImpl):
3181         (JSC::Wasm::Module::getOrCreateCodeBlock):
3182         (JSC::Wasm::Module::compileSync):
3183         (JSC::Wasm::Module::makeValidationCallback):
3184         (JSC::Wasm::Module::compileAsync):
3185         * wasm/WasmModule.h: Added.
3186         (JSC::Wasm::Module::create):
3187         (JSC::Wasm::Module::validateSync):
3188         (JSC::Wasm::Module::validateAsync):
3189         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
3190         (JSC::Wasm::Module::moduleInformation):
3191         (JSC::Wasm::Module::nonNullCodeBlock):
3192         * wasm/WasmPlan.cpp:
3193         (JSC::Wasm::Plan::Plan):
3194         (JSC::Wasm::Plan::addCompletionTask):
3195         (JSC::Wasm::Plan::prepare):
3196         (JSC::Wasm::Plan::compileFunctions):
3197         (JSC::Wasm::Plan::complete):
3198         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
3199         (JSC::Wasm::Plan::cancel): Deleted.
3200         * wasm/WasmPlan.h:
3201         (JSC::Wasm::Plan::dontFinalize):
3202         (JSC::Wasm::Plan::takeWasmToWasmExitStubs):
3203         (JSC::Wasm::Plan::mode):
3204         (JSC::Wasm::Plan::takeWasmExitStubs): Deleted.
3205         (JSC::Wasm::Plan::vm): Deleted.
3206         * wasm/WasmWorklist.cpp:
3207         (JSC::Wasm::Worklist::stopAllPlansForVM):
3208         * wasm/js/JSWebAssemblyCodeBlock.cpp:
3209         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
3210         (JSC::JSWebAssemblyCodeBlock::isSafeToRun):
3211         (JSC::JSWebAssemblyCodeBlock::initialize): Deleted.
3212         * wasm/js/JSWebAssemblyCodeBlock.h:
3213         (JSC::JSWebAssemblyCodeBlock::create):
3214         (JSC::JSWebAssemblyCodeBlock::functionImportCount):
3215         (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
3216         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
3217         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
3218         (JSC::JSWebAssemblyCodeBlock::mode): Deleted.
3219         (JSC::JSWebAssemblyCodeBlock::initialized): Deleted.
3220         (JSC::JSWebAssemblyCodeBlock::plan): Deleted.
3221         (JSC::JSWebAssemblyCodeBlock::runnable): Deleted.
3222         (JSC::JSWebAssemblyCodeBlock::errorMessage): Deleted.
3223         (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee): Deleted.
3224         (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee): Deleted.
3225         * wasm/js/JSWebAssemblyInstance.cpp:
3226         (JSC::JSWebAssemblyInstance::finalizeCreation):
3227         (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): Deleted.
3228         * wasm/js/JSWebAssemblyInstance.h:
3229         (JSC::JSWebAssemblyInstance::initialized): Deleted.
3230         * wasm/js/JSWebAssemblyModule.cpp:
3231         (JSC::JSWebAssemblyModule::createStub):
3232         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
3233         (JSC::JSWebAssemblyModule::finishCreation):
3234         * wasm/js/JSWebAssemblyModule.h:
3235         (JSC::JSWebAssemblyModule::moduleInformation):
3236         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
3237         (JSC::JSWebAssemblyModule::module):
3238         * wasm/js/WebAssemblyFunction.cpp:
3239         (JSC::WebAssemblyFunction::create):
3240         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3241         (JSC::constructJSWebAssemblyInstance):
3242         * wasm/js/WebAssemblyModuleConstructor.cpp:
3243         (JSC::WebAssemblyModuleConstructor::createModule):
3244         * wasm/js/WebAssemblyPrototype.cpp:
3245         (JSC::reject):
3246         (JSC::webAssemblyCompileFunc):
3247         (JSC::resolve):
3248         (JSC::instantiate):
3249         (JSC::compileAndInstantiate):
3250         (JSC::webAssemblyValidateFunc):
3251
3252 2017-04-07  Carlos Garcia Campos  <cgarcia@igalia.com>
3253
3254         [GTK] Update the priorities used in glib main loop sources
3255         https://bugs.webkit.org/show_bug.cgi?id=170457
3256
3257         Reviewed by Žan Doberšek.
3258
3259         * runtime/JSRunLoopTimer.cpp:
3260         (JSC::JSRunLoopTimer::JSRunLoopTimer):
3261
3262 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
3263
3264         Rename allocateStack to allocateStackByGraphColoring.
3265
3266         Rubber stamped by Saam Barati.
3267
3268         * CMakeLists.txt:
3269         * JavaScriptCore.xcodeproj/project.pbxproj:
3270         * b3/air/AirAllocateStack.cpp: Removed.
3271         * b3/air/AirAllocateStack.h: Removed.
3272         * b3/air/AirAllocateStackByGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.cpp.
3273         (JSC::B3::Air::allocateStackByGraphColoring):
3274         (JSC::B3::Air::allocateStack): Deleted.
3275         * b3/air/AirAllocateStackByGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.h.
3276         * b3/air/AirGenerate.cpp:
3277         (JSC::B3::Air::prepareForGeneration):
3278
3279 2017-04-06  Michael Saboff  <msaboff@apple.com>
3280
3281         Cannot Object.seal() or Object.freeze() global "this"
3282         https://bugs.webkit.org/show_bug.cgi?id=170549
3283
3284         Reviewed by Mark Lam.
3285
3286         Needed to implement JSProxy::isExtensible() which returns the results of calling
3287         the same on wrapped object.
3288
3289         Implemented step 11 of Runtime Semantics: EvalDeclarationInstantiation from the ECMAScript
3290         spec to properly return a TypeError object when attempting to add properties to a
3291         non-extensible global object.
3292
3293         * interpreter/Interpreter.cpp:
3294         (JSC::Interpreter::execute):
3295         * runtime/JSProxy.cpp:
3296         (JSC::JSProxy::isExtensible):
3297         * runtime/JSProxy.h:
3298
3299 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
3300
3301         Linear scan should run liveness only once
3302         https://bugs.webkit.org/show_bug.cgi?id=170569
3303
3304         Reviewed by Keith Miller.
3305         
3306         Air has a longstanding design bug that Tmps from different banks are indexed independently. This
3307         means that all of our analyses over Tmps do separate GP and FP passes. This does have some
3308         marginal benefits (the rest of the algorithm is specialized for Bank) but it's probably net bad.
3309         However, I don't want to think about solving that general problem.
3310         
3311         Instead, this just makes linear scan use a UnifiedTmpLiveness that uses a single "linear"
3312         indexing for GP and FP. This lets me avoid the much larger refactoring (which would involve
3313         substantial changes in graph coloring) while getting the bulk of the benefit (liveness runs once,
3314         instead of twice, for linear scan).
3315         
3316         This patch implements a lot of plumbing to make it possible for Liveness<> to view Tmps as having
3317         a unified indexing scheme. Tmp calls this LinearlyIndexed (to match the naming convention of
3318         AbsolutelyIndexed and Indexed), while AirLiveness calls this UnifiedTmpLiveness. With this
3319         change, -O1 never does any liveness analysis that uses separate GP and FP passes. I think this
3320         eliminates any urgency from the larger Tmp indexing bug. We can probably live with graph coloring
3321         doing separate passes.
3322         
3323         This is a ~6% speed-up for wasm -O1 compile times. I think this means that linear scan is no
3324         longer the longest pole in the tent.
3325
3326         * JavaScriptCore.xcodeproj/project.pbxproj:
3327         * b3/B3VariableLiveness.h:
3328         (JSC::B3::VariableLivenessAdapter::prepareToCompute):
3329         * b3/air/AirAllocateRegistersByLinearScan.cpp:
3330         (JSC::B3::Air::allocateRegistersByLinearScan):
3331         * b3/air/AirCode.h:
3332         (JSC::B3::Air::Code::forEachTmp):
3333         * b3/air/AirLiveness.h:
3334         * b3/air/AirLivenessAdapter.h:
3335         (JSC::B3::Air::LivenessAdapter::Actions::Actions):
3336         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
3337         (JSC::B3::Air::LivenessAdapter::adapter):
3338         (JSC::B3::Air::LivenessAdapter::prepareToCompute):
3339         (JSC::B3::Air::LivenessAdapter::actionsAt):
3340         (JSC::B3::Air::LivenessAdapter::forEachUse):
3341         (JSC::B3::Air::LivenessAdapter::forEachDef):
3342         (JSC::B3::Air::TmpLivenessAdapter::numIndices):
3343         (JSC::B3::Air::UnifiedTmpLivenessAdapter::UnifiedTmpLivenessAdapter):
3344         (JSC::B3::Air::UnifiedTmpLivenessAdapter::numIndices):
3345         (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsBank):
3346         (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsRole):
3347         (JSC::B3::Air::UnifiedTmpLivenessAdapter::valueToIndex):
3348         (JSC::B3::Air::UnifiedTmpLivenessAdapter::indexToValue):
3349         * b3/air/AirLivenessConstraints.h: Removed.
3350         * b3/air/AirRegLiveness.h:
3351         (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
3352         * b3/air/AirTmp.cpp:
3353         * b3/air/AirTmp.h:
3354         * b3/air/AirTmpInlines.h:
3355         (JSC::B3::Air::Tmp::LinearlyIndexed::LinearlyIndexed):
3356         (JSC::B3::Air::Tmp::LinearlyIndexed::index):
3357         (JSC::B3::Air::Tmp::linearlyIndexed):
3358         (JSC::B3::Air::Tmp::indexEnd):
3359         (JSC::B3::Air::Tmp::absoluteIndexEnd):
3360         (JSC::B3::Air::Tmp::linearIndexEnd):
3361         (JSC::B3::Air::Tmp::tmpForAbsoluteIndex):
3362         (JSC::B3::Air::Tmp::tmpForLinearIndex):
3363         * b3/air/AirTmpMap.h: Added.
3364         (JSC::B3::Air::TmpMap::TmpMap):
3365         (JSC::B3::Air::TmpMap::resize):
3366         (JSC::B3::Air::TmpMap::clear):
3367         (JSC::B3::Air::TmpMap::operator[]):
3368         (JSC::B3::Air::TmpMap::append):
3369
3370 2017-04-06  Ryan Haddad  <ryanhaddad@apple.com>
3371
3372         Unreviewed, rolling out r215046.
3373
3374         This change broke internal builds.
3375
3376         Reverted changeset:
3377
3378         "WebRTC tests gardening"
3379         https://bugs.webkit.org/show_bug.cgi?id=170508
3380         http://trac.webkit.org/changeset/215046
3381
3382 2017-04-06  Joseph Pecoraro  <pecoraro@apple.com>
3383
3384         Web Inspector: Show all headers in the Request Headers section of the Resource details sidebar
3385         https://bugs.webkit.org/show_bug.cgi?id=16531
3386         <rdar://problem/5712895>
3387
3388         Reviewed by Timothy Hatcher.
3389
3390         * inspector/protocol/Network.json:
3391         Optional refined list of request headers in Metrics.
3392
3393 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
3394
3395         B3 -O1 should generate better code than -O0
3396         https://bugs.webkit.org/show_bug.cgi?id=170563
3397
3398         Reviewed by Michael Saboff.
3399         
3400         Prior to this change, code generated by -O1 ran slower than code generated by -O0. This turned
3401         out to be because of reduceStrength optimizations that increase live ranges and create register
3402         pressure, which then creates problems for linear scan.
3403         
3404         It seemed obvious that canonicalizations that help isel, constant folding, and one-for-one
3405         strength reductions should stay. It also seemed obvious that SSA and CFG simplification are fast
3406         and harmless. So, I focused on removing:
3407         
3408         - CSE, which increases live ranges. This is a risky optimization when we know that we've chosen
3409           to use a bad register allocator.
3410         
3411         - Sophisticated strength reductions that create more code, like the insane division optimization.
3412         
3413         - Anything that inserts basic blocks.
3414         
3415         CSE appeared to be the cause of half of the throughput regression of -O1 but none of the compile
3416         time. This change also reduces the running time of reduceStrength by making it not a fixpoint at
3417         optLevel<2.
3418         
3419         This makes wasm -O1 compile 17% faster. This makes wasm -O1 run 19% faster. This makes -O1 code
3420         run 3% faster than -O0, and compile about 4% slower than -O0. We may yet end up choosing to use
3421         -O0, but at least now -O1 isn't totally useless.
3422
3423         * b3/B3ReduceStrength.cpp:
3424
3425 2017-04-06  Jon Davis  <jond@apple.com>
3426
3427         Updates feature status for recently shipped features
3428         https://bugs.webkit.org/show_bug.cgi?id=170359
3429
3430         Reviewed by Brian Burg.
3431
3432         Changed "Done" status to "Supported".
3433
3434         * features.json:
3435
3436 2017-04-06  Youenn Fablet  <youenn@apple.com>
3437
3438         WebRTC tests gardening
3439         https://bugs.webkit.org/show_bug.cgi?id=170508
3440
3441         Reviewed by Eric Carlson.
3442
3443         * Configurations/FeatureDefines.xcconfig:
3444
3445 2017-04-06  Guillaume Emont  <guijemont@igalia.com>
3446
3447         [JSC][MIPS][DFG] Use x86 generic HasOwnProperty
3448         https://bugs.webkit.org/show_bug.cgi?id=170222
3449
3450         Reviewed by Yusuke Suzuki.
3451
3452         * dfg/DFGFixupPhase.cpp:
3453         (JSC::DFG::FixupPhase::fixupNode):
3454         use the X86 special version for HasOwnProperty on MIPS too.
3455         * dfg/DFGSpeculativeJIT32_64.cpp:
3456         (JSC::DFG::SpeculativeJIT::compile):
3457         use the X86 special version for HasOwnProperty on MIPS too.
3458
3459 2017-04-05  Saam Barati  <sbarati@apple.com>
3460
3461         REGRESSION fix bad isWasm() test by ensuring proper Wasm callee bit pattern
3462         https://bugs.webkit.org/show_bug.cgi?id=170494
3463         <rdar://problem/31446485>
3464
3465         Reviewed by Yusuke Suzuki and Mark Lam.
3466
3467         This patch fixes how we test a 64 bit JSValue pattern to see if it's
3468         a Wasm callee. We now tag Wasm::Callee's with 0b011 in their lower 3 bits.
3469         The new test is for a Wasm Callee is as follows:
3470         isWasm(uint64_t x)
3471         {
3472             return x & 0xffff000000000007 == 3;
3473         }
3474         
3475         This test works because the lower 3 bits of the non-number immediate values are as follows:
3476         undefined: 0b010
3477         null:      0b010
3478         true:      0b111
3479         false:     0b110
3480         The test rejects all of these because none have just the value 3 in their lower 3 bits.
3481         The test also rejects all numbers, because they have non-zero upper 16 bits.
3482         The test also rejects normal cells because they won't have the number 3 as
3483         their lower 3 bits. Note, this bit pattern also allows the normal JSValue isCell(), etc,
3484         predicates to work on a Wasm::Callee because the various tests will fail if you
3485         bit casted a boxed Wasm::Callee* to a JSValue. isCell() would fail since it sees
3486         TagBitTypeOther. The other tests also trivially fail, since it won't be a number,
3487         and it won't be equal to null, undefined, true, or false. The isBoolean() predicate
3488         will fail because we won't have TagBitBool set.
3489
3490         * interpreter/CallFrame.h:
3491         (JSC::ExecState::guaranteedJSValueCallee):
3492         (JSC::ExecState::calleeAsValue): Deleted.
3493         * interpreter/CalleeBits.h:
3494         (JSC::CalleeBits::boxWasm):
3495         (JSC::CalleeBits::isWasm):
3496         (JSC::CalleeBits::asWasmCallee):
3497         * jit/JITOperations.cpp:
3498         * runtime/JSCJSValue.h:
3499
3500 2017-04-05  Keith Miller  <keith_miller@apple.com>
3501
3502         WebAssembly: Plans should be able to have more than one completion task.
3503         https://bugs.webkit.org/show_bug.cgi?id=170516
3504
3505         Reviewed by Saam Barati.
3506
3507         This patch also eliminates the need for blocked tasks on the
3508         PromiseDeferredTimer and pendingPromise on Wasm::Plan.
3509
3510         * runtime/PromiseDeferredTimer.cpp:
3511         (JSC::PromiseDeferredTimer::doWork):
3512         (JSC::PromiseDeferredTimer::cancelPendingPromise):
3513         (JSC::PromiseDeferredTimer::scheduleBlockedTask): Deleted.
3514         * runtime/PromiseDeferredTimer.h:
3515         * wasm/WasmPlan.cpp:
3516         (JSC::Wasm::Plan::Plan):
3517         (JSC::Wasm::Plan::addCompletionTask):
3518         (JSC::Wasm::Plan::complete):
3519         * wasm/WasmPlan.h:
3520         (JSC::Wasm::Plan::setMode):
3521         (JSC::Wasm::Plan::mode):
3522         (JSC::Wasm::Plan::setModeAndPromise): Deleted.
3523         (JSC::Wasm::Plan::pendingPromise): Deleted.
3524         * wasm/WasmWorklist.cpp:
3525         (JSC::Wasm::Worklist::enqueue):
3526         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3527         (JSC::constructJSWebAssemblyInstance):
3528         * wasm/js/WebAssemblyPrototype.cpp:
3529         (JSC::instantiate):
3530
3531 2017-04-05  Guilherme Iscaro  <iscaro@profusion.mobi>
3532
3533         Do not use BLX for immediates (ARM-32)
3534
3535         https://bugs.webkit.org/show_bug.cgi?id=170351
3536
3537         Reviewed by Mark Lam.
3538
3539         Currently the offline asm generator for 32-bit ARM code translates the
3540         'call' meta-instruction (which may be found in LowLevelInterpreter.asm
3541         and friends) to the ARM's BLX instrunction. The BLX instruction may be
3542         used for labels (immediates) and registers and one side effect of BLX
3543         is that it may switch the processor's instruction set.
3544         A 'BLX register' instruction will change/remain the processor state to
3545         ARM if the  register_bit[0] is set to 0 or change/remain to Thumb if
3546         register_bit[0] is set to 1. However, a 'BLX label' instruction will
3547         always switch the processor state. It switches ARM to thumb and vice-versa.
3548         This behaviour is unwanted, since the C++ code and the offlineasm generated code
3549         are both compiled using the same instruction set, thus a instruction
3550         set change will likely produce a crash. In order to fix the problem the
3551         BL instruction can be used for labels. It will branch just like BLX,
3552         but it won't change the instruction set. It's important to note that
3553         Darwin is not affected by this problem, thus to minimize the impact of
3554         this change the BL instruction will only be used on non-darwin targets.
3555
3556         BLX reference: http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHBJCDC.html?resultof=%22%62%6c%78%22%20
3557
3558         * offlineasm/arm.rb:
3559
3560 2017-04-05  Keith Miller  <keith_miller@apple.com>
3561
3562         WebAssembly: We shouldn't need to pin size registers if we have a fast memory.
3563         https://bugs.webkit.org/show_bug.cgi?id=170504
3564
3565         Reviewed by Mark Lam.
3566
3567         * wasm/WasmB3IRGenerator.cpp:
3568         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
3569         (JSC::Wasm::createJSToWasmWrapper):
3570         (JSC::Wasm::parseAndCompile):
3571         * wasm/WasmMemoryInformation.h:
3572         (JSC::Wasm::PinnedRegisterInfo::toSave):
3573
3574 2017-04-05  Yusuke Suzuki  <utatane.tea@gmail.com>
3575
3576         [JSC] Suppress warnings in GCC
3577         https://bugs.webkit.org/show_bug.cgi?id=170501
3578
3579         Reviewed by Keith Miller.
3580
3581         Should use ASSERT_NOT_REACHED since return-type pragma is only
3582         enabled under ASSERT_DISABLED environment. We shoud use
3583         ASSERT_NOTREACHED to emit assertions in debug build. It effectively
3584         catches bugs while keeping performance in release build.
3585
3586         * b3/B3Opcode.cpp:
3587         (JSC::B3::storeOpcode):
3588         * b3/B3Width.h:
3589         (JSC::B3::mask):
3590         * runtime/Options.cpp:
3591         (JSC::parse):
3592         * wasm/WasmSections.h:
3593         (JSC::Wasm::makeString):
3594         * wasm/WasmSignature.cpp:
3595         (JSC::Wasm::SignatureInformation::tryCleanup):
3596         * wasm/generateWasmValidateInlinesHeader.py:
3597
3598 2017-04-05  Carlos Garcia Campos  <cgarcia@igalia.com>
3599
3600         Implement PromiseDeferredTimer for non CF based ports
3601         https://bugs.webkit.org/show_bug.cgi?id=170391
3602
3603         Reviewed by Yusuke Suzuki.
3604
3605         RunLoop handling is only implemented for CF causing several wasm tests to fail for other ports.
3606
3607         * jsc.cpp:
3608         (runJSC): Remove CF ifdefs.
3609         * runtime/PromiseDeferredTimer.cpp:
3610         (JSC::PromiseDeferredTimer::doWork): Add non CF implementation using WTF RunLoop.
3611         (JSC::PromiseDeferredTimer::runRunLoop): Ditto.
3612         * runtime/PromiseDeferredTimer.h:
3613
3614 2017-04-05  Carlos Garcia Campos  <cgarcia@igalia.com>
3615
3616         WebAssembly: several tests added in r214504 crash when building with GCC
3617         https://bugs.webkit.org/show_bug.cgi?id=170390
3618
3619         Reviewed by Saam Barati.
3620
3621         The pattern foo->bar([f = WTFMove(foo)]{}); crashes when building with GCC, I assume the move happens before the
3622         foo is used to invoke the function.
3623
3624         * wasm/js/WebAssemblyPrototype.cpp:
3625         (JSC::webAssemblyCompileFunc): Use p.vm() instead of plan->vm(), because plan is moved by the lambda.
3626         (JSC::instantiate): Ditto.
3627         (JSC::compileAndInstantiate): Ditto.
3628
3629 2017-03-16  Yusuke Suzuki  <utatane.tea@gmail.com>
3630
3631         [JSC] Generate TemplateObjects at linking time
3632         https://bugs.webkit.org/show_bug.cgi?id=169743
3633
3634         Reviewed by Keith Miller.
3635
3636         Currently, the code calls getTemplateObject to get appropriate template objects at runtime.
3637         But this template object is constant value and never changed. So instead of creating it
3638         at runtime, we should create it at linking time and store it in the constant registers.
3639
3640         * builtins/BuiltinNames.h:
3641         * bytecode/CodeBlock.cpp:
3642         (JSC::CodeBlock::finishCreation):
3643         (JSC::CodeBlock::setConstantRegisters):
3644         * bytecode/CodeBlock.h:
3645         * bytecode/UnlinkedCodeBlock.cpp:
3646         (JSC::UnlinkedCodeBlock::shrinkToFit):
3647         * bytecode/UnlinkedCodeBlock.h:
3648         * bytecompiler/BytecodeGenerator.cpp:
3649         (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
3650         (JSC::BytecodeGenerator::emitGetTemplateObject):
3651         * bytecompiler/BytecodeGenerator.h:
3652         * bytecompiler/NodesCodegen.cpp:
3653         (JSC::TaggedTemplateNode::emitBytecode):
3654         * runtime/JSGlobalObject.cpp:
3655         (JSC::JSGlobalObject::init):
3656         (JSC::getTemplateObject): Deleted.
3657         * runtime/JSTemplateRegistryKey.cpp:
3658         * runtime/JSTemplateRegistryKey.h:
3659         (JSC::isTemplateRegistryKey):
3660
3661 2017-04-04  Mark Lam  <mark.lam@apple.com>
3662
3663         On ARM64, DFG::SpeculativeJIT::compileArithMod() failed to ensure result is of DataFormatInt32.
3664         https://bugs.webkit.org/show_bug.cgi?id=170473
3665         <rdar://problem/29912391>
3666
3667         Reviewed by Saam Barati.
3668
3669         In Unchecked mode, when DFG::SpeculativeJIT::compileArithMod() detects that the
3670         divisor is 0, we want it to return 0.  The result is expected to be of
3671         DataFormatIn32.
3672
3673         The ARM implementation just returns the value in the divisor register.  However,
3674         the divisor in this case can be of DataFormatJSInt32.  On ARM64, returning the
3675         divisor register yields the wrong result format because the same register also
3676         holds the upper 32-bit of the JSValue encoding.  The fix is to return an
3677         immediate 0 instead.
3678
3679         Also turned on the assertion in jitAssertIsInt32 for ARM64.  This assertion being
3680         disabled may have contributed to this bug going unnoticed all this time.
3681
3682         * dfg/DFGSpeculativeJIT.cpp:
3683         (JSC::DFG::SpeculativeJIT::compileArithMod):
3684         * jit/AssemblyHelpers.cpp:
3685         (JSC::AssemblyHelpers::jitAssertIsInt32):
3686
3687 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
3688
3689         Air::eliminateDeadCode should not repeatedly process the same live instructions
3690         https://bugs.webkit.org/show_bug.cgi?id=170490
3691
3692         Reviewed by Keith Miller.
3693         
3694         This makes the eliminateDeadCode() fixpoint somewhat worklist-based: we track the set
3695         of Insts that might be dead. Every time we detect that one is live, we remove it from
3696         the set. This is a big (>2x) speed-up because lots of Insts are immediately found to
3697         be live.
3698         
3699         This is a ~1% wasm -O1 compile time progression.
3700
3701         * b3/air/AirEliminateDeadCode.cpp:
3702         (JSC::B3::Air::eliminateDeadCode):
3703
3704 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
3705
3706         Air::eliminateDeadCode() should not use a HashSet
3707         https://bugs.webkit.org/show_bug.cgi?id=170487
3708
3709         Reviewed by Saam Barati.
3710         
3711         Introduce TmpSet, which is like a HashSet<Tmp>. Use this to make eliminateDeadCode()
3712         about 50% faster, resulting in a 1% wasm -O1 compile time progression.
3713
3714         * JavaScriptCore.xcodeproj/project.pbxproj:
3715         * b3/air/AirEliminateDeadCode.cpp:
3716         (JSC::B3::Air::eliminateDeadCode):
3717         * b3/air/AirTmpSet.h: Added.
3718         (JSC::B3::Air::TmpSet::TmpSet):
3719         (JSC::B3::Air::TmpSet::add):
3720         (JSC::B3::Air::TmpSet::remove):
3721         (JSC::B3::Air::TmpSet::contains):
3722         (JSC::B3::Air::TmpSet::size):
3723         (JSC::B3::Air::TmpSet::isEmpty):
3724         (JSC::B3::Air::TmpSet::iterator::iterator):
3725         (JSC::B3::Air::TmpSet::iterator::operator*):
3726         (JSC::B3::Air::TmpSet::iterator::operator++):
3727         (JSC::B3::Air::TmpSet::iterator::operator==):
3728         (JSC::B3::Air::TmpSet::iterator::operator!=):
3729         (JSC::B3::Air::TmpSet::begin):
3730         (JSC::B3::Air::TmpSet::end):
3731
3732 2017-04-04  Keith Miller  <keith_miller@apple.com>
3733
3734         WebAssembly: ModuleInformation should be a ref counted thing that can be shared across threads.
3735         https://bugs.webkit.org/show_bug.cgi?id=170478
3736
3737         Reviewed by Saam Barati.
3738
3739         ModuleInformation has been moved to its own file and is now
3740         ThreadSafeRefCounted.  All the Strings we used to keep in the
3741         ModuleInformation have been switched to Vector<LChar> this has the
3742         advantage that it can be passed across threads. However, this does
3743         mean that we need to decode the utf8 strings in each thread. This
3744         is likely not a problem because:
3745
3746         1) most modules have few imports/exports/custom sections.
3747         2) most of the time they are ascii so the conversion is cheap.
3748         3) we only have to do it once per thread, and there shouldn't be too many.
3749
3750         This patch also removes
3751         moduleSignatureIndicesToUniquedSignatureIndices since that
3752         information can already be recovered from the
3753         SignatureInformation.
3754
3755         * JavaScriptCore.xcodeproj/project.pbxproj:
3756         * jsc.cpp:
3757         (functionTestWasmModuleFunctions):
3758         * runtime/Identifier.h:
3759         (JSC::Identifier::fromString):
3760         * wasm/WasmB3IRGenerator.cpp:
3761         (JSC::Wasm::parseAndCompile):
3762         * wasm/WasmB3IRGenerator.h:
3763         * wasm/WasmFormat.cpp:
3764         (JSC::Wasm::makeString):
3765         (JSC::Wasm::ModuleInformation::~ModuleInformation): Deleted.
3766         * wasm/WasmFormat.h:
3767         (JSC::Wasm::makeString):
3768         (JSC::Wasm::ModuleInformation::functionIndexSpaceSize): Deleted.
3769         (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace): Deleted.
3770         (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace): Deleted.
3771         (JSC::Wasm::ModuleInformation::importFunctionCount): Deleted.
3772         (JSC::Wasm::ModuleInformation::internalFunctionCount): Deleted.
3773         * wasm/WasmFunctionParser.h:
3774         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
3775         * wasm/WasmModuleInformation.cpp: Copied from Source/JavaScriptCore/wasm/WasmValidate.h.
3776         (JSC::Wasm::ModuleInformation::~ModuleInformation):
3777         * wasm/WasmModuleInformation.h: Added.
3778         (JSC::Wasm::ModuleInformation::functionIndexSpaceSize):
3779         (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace):
3780         (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace):
3781         (JSC::Wasm::ModuleInformation::importFunctionCount):
3782         (JSC::Wasm::ModuleInformation::internalFunctionCount):
3783         (JSC::Wasm::ModuleInformation::ModuleInformation):
3784         * wasm/WasmModuleParser.cpp:
3785         * wasm/WasmModuleParser.h:
3786         (JSC::Wasm::ModuleParser::ModuleParser):
3787         * wasm/WasmParser.h:
3788         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
3789         * wasm/WasmPlan.cpp:
3790         (JSC::Wasm::Plan::Plan):
3791         (JSC::Wasm::Plan::parseAndValidateModule):
3792         (JSC::Wasm::Plan::prepare):
3793         (JSC::Wasm::Plan::compileFunctions):
3794         (JSC::Wasm::Plan::complete):
3795         (JSC::Wasm::Plan::cancel):
3796         * wasm/WasmPlan.h:
3797         (JSC::Wasm::Plan::internalFunctionCount):
3798         (JSC::Wasm::Plan::takeModuleInformation):
3799         * wasm/WasmSignature.cpp:
3800         (JSC::Wasm::SignatureInformation::get):
3801         * wasm/WasmSignature.h:
3802         * wasm/WasmValidate.cpp:
3803         (JSC::Wasm::validateFunction):
3804         * wasm/WasmValidate.h:
3805         * wasm/js/JSWebAssemblyHelpers.h:
3806         (JSC::createSourceBufferFromValue):
3807         * wasm/js/JSWebAssemblyModule.cpp:
3808         (JSC::JSWebAssemblyModule::createStub):
3809         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
3810         (JSC::JSWebAssemblyModule::finishCreation):
3811         * wasm/js/JSWebAssemblyModule.h:
3812         (JSC::JSWebAssemblyModule::moduleInformation):
3813         (JSC::JSWebAssemblyModule::source):
3814         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3815         (JSC::constructJSWebAssemblyInstance):
3816         * wasm/js/WebAssemblyModuleConstructor.cpp:
3817         (JSC::WebAssemblyModuleConstructor::createModule):
3818         * wasm/js/WebAssemblyModulePrototype.cpp:
3819         (JSC::webAssemblyModuleProtoCustomSections):
3820         (JSC::webAssemblyModuleProtoImports):
3821         (JSC::webAssemblyModuleProtoExports):
3822         * wasm/js/WebAssemblyModuleRecord.cpp:
3823         (JSC::WebAssemblyModuleRecord::link):
3824         * wasm/js/WebAssemblyModuleRecord.h:
3825         * wasm/js/WebAssemblyPrototype.cpp:
3826         (JSC::webAssemblyCompileFunc):
3827         (JSC::instantiate):
3828         (JSC::compileAndInstantiate):
3829
3830 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
3831
3832         B3::fixSSA() needs a tune-up
3833         https://bugs.webkit.org/show_bug.cgi?id=170485
3834
3835         Reviewed by Saam Barati.
3836         
3837         After the various optimizations to liveness, register allocation, and other phases, the
3838         fixSSA() phase now looks like one of the top offenders. This includes a bunch of
3839         changes to make this phase run faster. This is a ~7% wasm -O1 compile time progression.
3840         
3841         Here's what I did:
3842         
3843         - We now use IndexSparseSet instead of IndexMap for tracking variable values. This
3844           makes it cheaper to chew through small blocks while there is a non-trivial number of
3845           total variables.
3846         
3847         - We now do a "local SSA conversion" pass before anything else. This eliminates
3848           obvious Get's. If we were using temporary Variables, it would eliminate many of
3849           those. That's useful for when we use demoteValues() and duplciateTails(). For wasm
3850           -O1, we mainly care about the fact that it makes a bunch of Set's dead.
3851         
3852         - We now do a Set DCE pass after the local SSA but before SSA conversion. This ensures
3853           that any block-local live intervals of Variables disappear and don't need further
3854           consideration.
3855         
3856         - We now cache the reaching defs calculation.
3857         
3858         - We now perform the reaching defs calculation lazily.
3859
3860         * b3/B3FixSSA.cpp:
3861         (JSC::B3::demoteValues):
3862         (JSC::B3::fixSSA):
3863         * b3/B3SSACalculator.cpp:
3864         (JSC::B3::SSACalculator::reachingDefAtTail):
3865         * b3/B3VariableLiveness.cpp:
3866         (JSC::B3::VariableLiveness::VariableLiveness):
3867         * b3/air/AirLiveness.h:
3868         (JSC::B3::Air::Liveness::Liveness):
3869         * dfg/DFGLivenessAnalysisPhase.cpp:
3870         (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase): Deleted.
3871         (JSC::DFG::LivenessAnalysisPhase::run): Deleted.
3872         (JSC::DFG::LivenessAnalysisPhase::processBlock): Deleted.
3873
3874 2017-04-04  Joseph Pecoraro  <pecoraro@apple.com>
3875
3876         Remove stale LLVM Header Path includes from JavaScriptCore
3877         https://bugs.webkit.org/show_bug.cgi?id=170483
3878
3879         Reviewed by Mark Lam.
3880
3881         * Configurations/Base.xcconfig:
3882
3883 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
3884
3885         B3::LowerToAir incorrectly selects BitXor(AtomicStrongCAS(...), $1)
3886         https://bugs.webkit.org/show_bug.cgi?id=169867
3887
3888         Reviewed by Saam Barati.
3889         
3890         The BitXor(AtomicWeakCAS(...), $1) optimization makes a lot of sense because we an fold the
3891         BitXor into the CAS condition read-out. But there is no version of this that is profitable or
3892         correct for AtomicStrongCAS. The inversion case is handled by Equal(AtomicStrongCAS(...), ...)
3893         becoming NotEqual(AtomicStrongCAS(...), ...), and we alraedy handle that separately.
3894         
3895         So, the fix here is to make the BitXor CAS pattern only recognize AtomicWeakCAS.
3896
3897         * b3/B3LowerToAir.cpp:
3898         (JSC::B3::Air::LowerToAir::lower):
3899         * b3/testb3.cpp:
3900         (JSC::B3::testAtomicStrongCAS):
3901
3902 2017-04-04  Saam Barati  <sbarati@apple.com>
3903
3904         WebAssembly: JSWebAssemblyCallee should not be a JSCell
3905         https://bugs.webkit.org/show_bug.cgi?id=170135
3906
3907         Reviewed by Michael Saboff.
3908
3909         This patch is perhaps the last big change to the design of fundamental
3910         Wasm API to allow for PIC. It changes JSWebAssemblyCallee into a thing
3911         called Wasm::Callee. It serves the same purpose as before, except
3912         Wasm::Callee is not a JSCell. I had to refactor the various parts of the
3913         runtime that will see CallFrame's with Wasm::Callee's in the callee slot.
3914         Thankfully, the parts of the runtime that Wasm touches are limited. The
3915         main refactoring is changing the exception handling code, such as taking
3916         a stack trace, to be friendly to seeing a non JSCell callee.
3917         
3918         The callee() function on ExecState now returns a class I added in this
3919         patch called CalleeBits. CalleeBits will tell you if the callee is a
3920         JSCell or a Wasm::Callee. We tag Wasm::Callee's with a 1 in their lower
3921         bit so we can easily tell what is and isn't a Wasm::Callee.
3922         
3923         The stub that calls out from Wasm to JS still puts a JSCell callee
3924         into the call frame, even though the callee logically represents a
3925         Wasm frame. The reason for this is that we use the call IC infrastructure
3926         to make a call out to JS code, and the code that writes the IC expects
3927         a JSCell as the callee. This is knowingly part of our design. When we
3928         do structured cloning of Wasm Modules, we'll need to regenerate these
3929         JS call stubs.
3930
3931         * API/JSContextRef.cpp:
3932         (BacktraceFunctor::operator()):
3933         * CMakeLists.txt:
3934         * JavaScriptCore.xcodeproj/project.pbxproj:
3935         * debugger/Debugger.cpp:
3936         (JSC::Debugger::pauseIfNeeded):
3937         (JSC::Debugger::currentDebuggerCallFrame):
3938    &