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