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