Source/JavaScriptCore/ChangeLog

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