Source/JavaScriptCore/ChangeLog

   1 2016-10-19  Yusuke Suzuki  <utatane.tea@gmail.com>
   2
   3         [JSC] Move InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero to out of line type info flags
   4         https://bugs.webkit.org/show_bug.cgi?id=163716
   5
   6         Reviewed by Saam Barati.
   7
   8         We found that all the accesses to the InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero flag is
   9         done through the Structure. There is no user that accesses this flag in the cell inlined member. And JIT
  10         code does not access it directly. That means that we can move this flag from inlined flags to out of line
  11         flags. This patch moves it to the out of line flags. And make one bit empty in inlined flags. Later this
  12         new empty flag will be used by megamorphic DOMJIT implementation.
  13
  14         * runtime/JSTypeInfo.h:
  15         (JSC::TypeInfo::hasStaticPropertyTable):
  16         (JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero):
  17
  18 2016-10-20  Keith Miller  <keith_miller@apple.com>
  19
  20         Invalid assertion in arguments elimination
  21         https://bugs.webkit.org/show_bug.cgi?id=163740
  22         <rdar://problem/27911462>
  23
  24         Reviewed by Michael Saboff.
  25
  26         The DFGFTL's arguments elimination phase incorrectly asserted that a GetFromArguments' first
  27         child would always be a CreateDirectArguments.  While we only create the
  28         op_get_from_arguments bytecode pointing to a create_direct_arguments, its possible for a
  29         number of reasons that a DFG GetFromArguments may not point to a CreateDirectArguments. For
  30         example, if we are OSR entering in some function with direct arguments the
  31         CreateDirectArguments node might become ExtractOSREntryLocals.
  32
  33         * dfg/DFGArgumentsEliminationPhase.cpp:
  34
  35 2016-10-20  Caitlin Potter  <caitp@igalia.com>
  36
  37         [JSC] throw TypeError when constructing dynamically created JSGeneratorFunction
  38         https://bugs.webkit.org/show_bug.cgi?id=163714
  39
  40         Reviewed by Mark Lam.
  41
  42         According to CreateDynamicFunction() (https://tc39.github.io/ecma262/#sec-createdynamicfunction),
  43         non-normal functions are not constructors. Previously, dynamically created functions would always
  44         be constructible, and so it was possible to evaluate `new  (function*() {}.constructor())`,
  45         and have it return an Iterator object.
  46
  47         This change selects a dynamically created function's ConstructAbility based on its parse mode instead.
  48
  49         * runtime/CodeCache.cpp:
  50         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
  51
  52 2016-10-19  JF Bastien  <jfbastien@apple.com>
  53
  54         create_hash_table: allow empty tables
  55
  56         The Windows build was broken by because I added empty tables and Windows insists that empty tables are horrible. Put in dummy entries in that case.
  57
  58         create_hash_table: allow empty tables
  59         https://bugs.webkit.org/show_bug.cgi?id=163701
  60
  61         Reviewed by Keith Miller.
  62
  63         * create_hash_table:
  64
  65 2016-10-19  JF Bastien  <jfbastien@apple.com>
  66
  67         JavaScript WebAssembly API: baby steps
  68
  69          - Expand WebAssembly constructors into their own files. This requires a lot of
  70            boilerplate, as well as adding the .lut.h files. All of the
  71            JSWebAssembly*.{h,cpp}, as well as Constructor and Prototype files, are
  72            currently the same between the 4 specified WebAssembly constructors. It'll be
  73            easy to implement individual functions on constructed objects as per the
  74            spec, and have each of these files diverge. The error constructors are also
  75            similar, except that their instance derives from ErrorInstance.
  76          - Use constructor macro when initializing the global object.
  77          - Dramatically improve testing of the WebAssembly API by checking for
  78            properties specified in the spec [*].
  79          - Clean up assert.js' exception testing.
  80          - Fix a copy-paste bug in wasm.json: floating-point const return values were
  81            swapped.
  82
  83         [*] https://github.com/WebAssembly/design/blob/master/JS.md
  84
  85         Implement more of the JavaScript WebAssembly API
  86         https://bugs.webkit.org/show_bug.cgi?id=163571
  87
  88         Reviewed by Keith Miller.
  89
  90         * CMakeLists.txt: add .lut.h generation
  91         * DerivedSources.make: ditto
  92         * JavaScriptCore.xcodeproj/project.pbxproj: add .lut.h generation and all the new files
  93         * runtime/JSGlobalObject.cpp:
  94         (JSC::JSGlobalObject::init): use macro to list all constructors
  95         * wasm/WebAssemblyObject.cpp: unboilerplate, all constructors into their own files
  96         * wasm/WebAssemblyObject.h: ditto
  97         * wasm/js/JSWebAssemblyCompileError.cpp: Added.
  98         (JSC::JSWebAssemblyCompileError::create):
  99         (JSC::JSWebAssemblyCompileError::createStructure):
 100         (JSC::JSWebAssemblyCompileError::JSWebAssemblyCompileError):
 101         (JSC::JSWebAssemblyCompileError::finishCreation):
 102         (JSC::JSWebAssemblyCompileError::destroy):
 103         (JSC::JSWebAssemblyCompileError::visitChildren):
 104         * wasm/js/JSWebAssemblyCompileError.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 105         * wasm/js/JSWebAssemblyInstance.cpp: Added.
 106         (JSC::JSWebAssemblyInstance::create):
 107         (JSC::JSWebAssemblyInstance::createStructure):
 108         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
 109         (JSC::JSWebAssemblyInstance::finishCreation):
 110         (JSC::JSWebAssemblyInstance::destroy):
 111         (JSC::JSWebAssemblyInstance::visitChildren):
 112         * wasm/js/JSWebAssemblyInstance.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 113         * wasm/js/JSWebAssemblyMemory.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 114         (JSC::JSWebAssemblyMemory::create):
 115         (JSC::JSWebAssemblyMemory::createStructure):
 116         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
 117         (JSC::JSWebAssemblyMemory::finishCreation):
 118         (JSC::JSWebAssemblyMemory::destroy):
 119         (JSC::JSWebAssemblyMemory::visitChildren):
 120         * wasm/js/JSWebAssemblyMemory.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 121         * wasm/js/JSWebAssemblyModule.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 122         (JSC::JSWebAssemblyModule::create):
 123         (JSC::JSWebAssemblyModule::createStructure):
 124         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
 125         (JSC::JSWebAssemblyModule::finishCreation):
 126         (JSC::JSWebAssemblyModule::destroy):
 127         (JSC::JSWebAssemblyModule::visitChildren):
 128         * wasm/js/JSWebAssemblyModule.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 129         * wasm/js/JSWebAssemblyRuntimeError.cpp: Added.
 130         (JSC::JSWebAssemblyRuntimeError::create):
 131         (JSC::JSWebAssemblyRuntimeError::createStructure):
 132         (JSC::JSWebAssemblyRuntimeError::JSWebAssemblyRuntimeError):
 133         (JSC::JSWebAssemblyRuntimeError::finishCreation):
 134         (JSC::JSWebAssemblyRuntimeError::destroy):
 135         (JSC::JSWebAssemblyRuntimeError::visitChildren):
 136         * wasm/js/JSWebAssemblyRuntimeError.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 137         * wasm/js/JSWebAssemblyTable.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 138         (JSC::JSWebAssemblyTable::create):
 139         (JSC::JSWebAssemblyTable::createStructure):
 140         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
 141         (JSC::JSWebAssemblyTable::finishCreation):
 142         (JSC::JSWebAssemblyTable::destroy):
 143         (JSC::JSWebAssemblyTable::visitChildren):
 144         * wasm/js/JSWebAssemblyTable.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 145         * wasm/js/WebAssemblyCompileErrorConstructor.cpp: Added.
 146         (JSC::constructJSWebAssemblyCompileError):
 147         (JSC::callJSWebAssemblyCompileError):
 148         (JSC::WebAssemblyCompileErrorConstructor::create):
 149         (JSC::WebAssemblyCompileErrorConstructor::createStructure):
 150         (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
 151         (JSC::WebAssemblyCompileErrorConstructor::WebAssemblyCompileErrorConstructor):
 152         (JSC::WebAssemblyCompileErrorConstructor::getConstructData):
 153         (JSC::WebAssemblyCompileErrorConstructor::getCallData):
 154         (JSC::WebAssemblyCompileErrorConstructor::visitChildren):
 155         * wasm/js/WebAssemblyCompileErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 156         (JSC::WebAssemblyCompileErrorConstructor::CompileErrorStructure):
 157         * wasm/js/WebAssemblyCompileErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 158         (JSC::WebAssemblyCompileErrorPrototype::create):
 159         (JSC::WebAssemblyCompileErrorPrototype::createStructure):
 160         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
 161         (JSC::WebAssemblyCompileErrorPrototype::WebAssemblyCompileErrorPrototype):
 162         * wasm/js/WebAssemblyCompileErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 163         * wasm/js/WebAssemblyInstanceConstructor.cpp: Added.
 164         (JSC::constructJSWebAssemblyInstance):
 165         (JSC::callJSWebAssemblyInstance):
 166         (JSC::WebAssemblyInstanceConstructor::create):
 167         (JSC::WebAssemblyInstanceConstructor::createStructure):
 168         (JSC::WebAssemblyInstanceConstructor::finishCreation):
 169         (JSC::WebAssemblyInstanceConstructor::WebAssemblyInstanceConstructor):
 170         (JSC::WebAssemblyInstanceConstructor::getConstructData):
 171         (JSC::WebAssemblyInstanceConstructor::getCallData):
 172         (JSC::WebAssemblyInstanceConstructor::visitChildren):
 173         * wasm/js/WebAssemblyInstanceConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 174         (JSC::WebAssemblyInstanceConstructor::InstanceStructure):
 175         * wasm/js/WebAssemblyInstancePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 176         (JSC::WebAssemblyInstancePrototype::create):
 177         (JSC::WebAssemblyInstancePrototype::createStructure):
 178         (JSC::WebAssemblyInstancePrototype::finishCreation):
 179         (JSC::WebAssemblyInstancePrototype::WebAssemblyInstancePrototype):
 180         * wasm/js/WebAssemblyInstancePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 181         * wasm/js/WebAssemblyMemoryConstructor.cpp: Added.
 182         (JSC::constructJSWebAssemblyMemory):
 183         (JSC::callJSWebAssemblyMemory):
 184         (JSC::WebAssemblyMemoryConstructor::create):
 185         (JSC::WebAssemblyMemoryConstructor::createStructure):
 186         (JSC::WebAssemblyMemoryConstructor::finishCreation):
 187         (JSC::WebAssemblyMemoryConstructor::WebAssemblyMemoryConstructor):
 188         (JSC::WebAssemblyMemoryConstructor::getConstructData):
 189         (JSC::WebAssemblyMemoryConstructor::getCallData):
 190         (JSC::WebAssemblyMemoryConstructor::visitChildren):
 191         * wasm/js/WebAssemblyMemoryConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 192         (JSC::WebAssemblyMemoryConstructor::MemoryStructure):
 193         * wasm/js/WebAssemblyMemoryPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 194         (JSC::WebAssemblyMemoryPrototype::create):
 195         (JSC::WebAssemblyMemoryPrototype::createStructure):
 196         (JSC::WebAssemblyMemoryPrototype::finishCreation):
 197         (JSC::WebAssemblyMemoryPrototype::WebAssemblyMemoryPrototype):
 198         * wasm/js/WebAssemblyMemoryPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 199         * wasm/js/WebAssemblyModuleConstructor.cpp: Added.
 200         (JSC::constructJSWebAssemblyModule):
 201         (JSC::callJSWebAssemblyModule):
 202         (JSC::WebAssemblyModuleConstructor::create):
 203         (JSC::WebAssemblyModuleConstructor::createStructure):
 204         (JSC::WebAssemblyModuleConstructor::finishCreation):
 205         (JSC::WebAssemblyModuleConstructor::WebAssemblyModuleConstructor):
 206         (JSC::WebAssemblyModuleConstructor::getConstructData):
 207         (JSC::WebAssemblyModuleConstructor::getCallData):
 208         (JSC::WebAssemblyModuleConstructor::visitChildren):
 209         * wasm/js/WebAssemblyModuleConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 210         (JSC::WebAssemblyModuleConstructor::ModuleStructure):
 211         * wasm/js/WebAssemblyModulePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 212         (JSC::WebAssemblyModulePrototype::create):
 213         (JSC::WebAssemblyModulePrototype::createStructure):
 214         (JSC::WebAssemblyModulePrototype::finishCreation):
 215         (JSC::WebAssemblyModulePrototype::WebAssemblyModulePrototype):
 216         * wasm/js/WebAssemblyModulePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 217         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: Added.
 218         (JSC::constructJSWebAssemblyRuntimeError):
 219         (JSC::callJSWebAssemblyRuntimeError):
 220         (JSC::WebAssemblyRuntimeErrorConstructor::create):
 221         (JSC::WebAssemblyRuntimeErrorConstructor::createStructure):
 222         (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
 223         (JSC::WebAssemblyRuntimeErrorConstructor::WebAssemblyRuntimeErrorConstructor):
 224         (JSC::WebAssemblyRuntimeErrorConstructor::getConstructData):
 225         (JSC::WebAssemblyRuntimeErrorConstructor::getCallData):
 226         (JSC::WebAssemblyRuntimeErrorConstructor::visitChildren):
 227         * wasm/js/WebAssemblyRuntimeErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 228         (JSC::WebAssemblyRuntimeErrorConstructor::RuntimeErrorStructure):
 229         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 230         (JSC::WebAssemblyRuntimeErrorPrototype::create):
 231         (JSC::WebAssemblyRuntimeErrorPrototype::createStructure):
 232         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
 233         (JSC::WebAssemblyRuntimeErrorPrototype::WebAssemblyRuntimeErrorPrototype):
 234         * wasm/js/WebAssemblyRuntimeErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 235         * wasm/js/WebAssemblyTableConstructor.cpp: Added.
 236         (JSC::constructJSWebAssemblyTable):
 237         (JSC::callJSWebAssemblyTable):
 238         (JSC::WebAssemblyTableConstructor::create):
 239         (JSC::WebAssemblyTableConstructor::createStructure):
 240         (JSC::WebAssemblyTableConstructor::finishCreation):
 241         (JSC::WebAssemblyTableConstructor::WebAssemblyTableConstructor):
 242         (JSC::WebAssemblyTableConstructor::getConstructData):
 243         (JSC::WebAssemblyTableConstructor::getCallData):
 244         (JSC::WebAssemblyTableConstructor::visitChildren):
 245         * wasm/js/WebAssemblyTableConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 246         (JSC::WebAssemblyTableConstructor::TableStructure):
 247         * wasm/js/WebAssemblyTablePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 248         (JSC::WebAssemblyTablePrototype::create):
 249         (JSC::WebAssemblyTablePrototype::createStructure):
 250         (JSC::WebAssemblyTablePrototype::finishCreation):
 251         (JSC::WebAssemblyTablePrototype::WebAssemblyTablePrototype):
 252         * wasm/js/WebAssemblyTablePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
 253
 254 2016-10-19  Caitlin Potter  <caitp@igalia.com>
 255
 256         [JSC] forbid "use strict" directive in generator functions with non-simple parameters
 257         https://bugs.webkit.org/show_bug.cgi?id=163683
 258
 259         Reviewed by Geoffrey Garen.
 260
 261         Because generator functions and async functions both have an implicit
 262         inner function whose arguments are inherited from its parent, "use strict"
 263         directives within these functions did not yield a SyntaxError.
 264
 265         Now, the correct syntax error is reported, fixing several test262 failures
 266         for generators and async functions.
 267
 268         * parser/Parser.cpp:
 269         (JSC::Parser<LexerType>::parseFunctionInfo):
 270
 271 2016-10-19  Ryan Haddad  <ryanhaddad@apple.com>
 272
 273         Unreviewed, rolling out r207557.
 274
 275         This change caused animations/font-variations tests to time
 276         out on pre-Sierra Macs.
 277
 278         Reverted changeset:
 279
 280         "[macOS] [iOS] Disable variation fonts on macOS El Capitan and
 281         iOS 9"
 282         https://bugs.webkit.org/show_bug.cgi?id=163374
 283         http://trac.webkit.org/changeset/207557
 284
 285 2016-10-19  Filip Pizlo  <fpizlo@apple.com>
 286
 287         Baseline JIT should use AutomaticThread
 288         https://bugs.webkit.org/show_bug.cgi?id=163686
 289
 290         Reviewed by Geoffrey Garen.
 291
 292         Change the JITWorklist to use AutomaticThread, so that the Baseline JIT's concurrent
 293         compiler thread shuts down automatically after inactivity.
 294
 295         With this change, all of JSC's threads shut down automatically. If you run splay for a few
 296         seconds (which fires up all threads - compiler and GC) and then go to sleep for a second,
 297         you'll see that the only threads left are the main thread and the bmalloc thread.
 298
 299         * jit/JITWorklist.cpp:
 300         (JSC::JITWorklist::Thread::Thread):
 301         (JSC::JITWorklist::JITWorklist):
 302         (JSC::JITWorklist::completeAllForVM):
 303         (JSC::JITWorklist::poll):
 304         (JSC::JITWorklist::compileLater):
 305         (JSC::JITWorklist::compileNow):
 306         (JSC::JITWorklist::finalizePlans):
 307         (JSC::JITWorklist::runThread): Deleted.
 308         * jit/JITWorklist.h:
 309
 310 2016-10-19  Myles C. Maxfield  <mmaxfield@apple.com>
 311
 312         [macOS] [iOS] Disable variation fonts on macOS El Capitan and iOS 9
 313         https://bugs.webkit.org/show_bug.cgi?id=163374
 314
 315         Reviewed by Darin Adler.
 316
 317         * Configurations/FeatureDefines.xcconfig:
 318
 319 2016-10-19  Aaron Chu  <aaron_chu@apple.com>
 320
 321         Web Inspector: AXI: expose computed tree node and heading level
 322         https://bugs.webkit.org/show_bug.cgi?id=130825
 323         <rdar://problem/16442349>
 324
 325         Reviewed by Joseph Pecoraro.
 326
 327         Exposing two new accessibility properties: Heading Level and Hierarchical Level.
 328
 329         * inspector/protocol/DOM.json:
 330
 331 2016-10-18  Filip Pizlo  <fpizlo@apple.com>
 332
 333         DFG worklist should use AutomaticThread
 334         https://bugs.webkit.org/show_bug.cgi?id=163615
 335
 336         Reviewed by Mark Lam.
 337
 338         AutomaticThread is a new feature in WTF that allows you to easily create worker threads that
 339         shut down automatically. This changes DFG::Worklist to use AutomaticThread, so that its
 340         threads shut down automatically, too. This has the potential to save a lot of memory.
 341
 342         This required some improvements to AutomaticThread: Worklist likes to be able to keep state
 343         around for the whole lifetime of a thread, and so it likes knowing when threads are born and
 344         when they die. I added virtual methods for that. Also, Worklist uses notifyOne() so I added
 345         that, too.
 346
 347         This looks to be perf-neutral.
 348
 349         * dfg/DFGThreadData.cpp:
 350         (JSC::DFG::ThreadData::ThreadData):
 351         * dfg/DFGThreadData.h:
 352         * dfg/DFGWorklist.cpp:
 353         (JSC::DFG::Worklist::ThreadBody::ThreadBody):
 354         (JSC::DFG::Worklist::Worklist):
 355         (JSC::DFG::Worklist::~Worklist):
 356         (JSC::DFG::Worklist::finishCreation):
 357         (JSC::DFG::Worklist::isActiveForVM):
 358         (JSC::DFG::Worklist::enqueue):
 359         (JSC::DFG::Worklist::compilationState):
 360         (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
 361         (JSC::DFG::Worklist::removeAllReadyPlansForVM):
 362         (JSC::DFG::Worklist::completeAllReadyPlansForVM):
 363         (JSC::DFG::Worklist::rememberCodeBlocks):
 364         (JSC::DFG::Worklist::visitWeakReferences):
 365         (JSC::DFG::Worklist::removeDeadPlans):
 366         (JSC::DFG::Worklist::removeNonCompilingPlansForVM):
 367         (JSC::DFG::Worklist::queueLength):
 368         (JSC::DFG::Worklist::dump):
 369         (JSC::DFG::Worklist::runThread): Deleted.
 370         (JSC::DFG::Worklist::threadFunction): Deleted.
 371         * dfg/DFGWorklist.h:
 372
 373 2016-10-19  Dan Bernstein  <mitz@apple.com>
 374
 375         [Xcode] JavaScriptCore fails to build when CLANG_WARN_DOCUMENTATION_COMMENTS is enabled
 376         https://bugs.webkit.org/show_bug.cgi?id=163642
 377
 378         Reviewed by Darin Adler.
 379
 380         * API/JSClassRef.cpp: Removed a bad headerdoc comment inside an implementation file.
 381         * API/JSContext.h: Changed @methodgroup to @functiongroup, because the compiler requires the
 382           former to be followed by a method (and we have a property), but not the latter. Changed
 383           a couple of instances of “method” to “@method”. Removed empty @param entries.
 384         * API/JSContextRefInternal.h: Named a parameter referenced in a @param entry.
 385         * API/JSContextRefPrivate.h: Ditto.
 386         * API/JSManagedValue.h: Removed empty @param entries.
 387         * API/JSObjectRef.h: Corrected parameter name in @param entry.
 388         * API/JSTypedArray.h: Ditto.
 389         * API/JSValue.h: Removed empty @param entries, changed @methodgroup to @functiongroup, and
 390           changed @method to @property where appropriate. Removed empty @param entries.
 391         * API/JSValueRef.h: Named a parameter referenced in a @param entry.
 392         * API/JSWeakObjectMapRefPrivate.h: Ditto.
 393         * Configurations/Base.xcconfig: Enabled CLANG_WARN_DOCUMENTATION_COMMENTS. Made the compiler
 394           treat the icu headers as system headers, to stop it from emitting warnings about headers
 395           we don’t want to change.
 396         * Configurations/ToolExecutable.xcconfig: Made the compiler treat the icu headers as system
 397           headers.
 398
 399 2016-10-19  Csaba Osztrogonác  <ossy@webkit.org>
 400
 401         Unreviewed ARM buildfix after r207475.
 402
 403         * assembler/ARMAssembler.h:
 404         (JSC::ARMAssembler::relinkJumpToNop):
 405
 406 2016-10-18  Mark Lam  <mark.lam@apple.com>
 407
 408         Invoking Object.prototype.__proto__ accessors directly should throw a TypeError.
 409         https://bugs.webkit.org/show_bug.cgi?id=154377
 410         <rdar://problem/27330808>
 411
 412         Reviewed by Filip Pizlo and Saam Barati.
 413
 414         In a scenario where we cache the __proto__ accessors in global variables, and
 415         later explicitly invoke those accessors as functions, the spec for Function Calls
 416         (see https://tc39.github.io/ecma262/#sec-function-calls) states that the function
 417         ref value is of type Reference, and base of ref is an Environment Record.  Then,
 418         it follows that the thisValue should be set to refEnv.WithBaseObject()
 419         (see section 4.b.ii of 12.3.4.1 at
 420         https://tc39.github.io/ecma262/#sec-function-calls-runtime-semantics-evaluation).
 421
 422         refEnv in this case is the environment record that the cached accessors were
 423         found in i.e. the global object.  The WithBaseObject() of the global object is
 424         undefined (see details about WithBaseObject at
 425         https://tc39.github.io/ecma262/#sec-environment-records).
 426
 427         Hence, the __proto__ accessors should see a thisValue of undefined, and throw
 428         TypeErrors.  See https://tc39.github.io/ecma262/#sec-get-object.prototype.__proto__,
 429         https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__,
 430         https://tc39.github.io/ecma262/#sec-toobject, and
 431         https://tc39.github.io/ecma262/#sec-requireobjectcoercible.
 432
 433         In JSC's implementation, the callee needs to do a ToThis operation on the
 434         incoming "this" argument in order to get the specified thisValue.  The
 435         implementations of the __proto__ accessors were not doing this correctly.  This
 436         has now been fixed.
 437
 438         * runtime/JSGlobalObjectFunctions.cpp:
 439         (JSC::globalFuncProtoGetter):
 440         (JSC::globalFuncProtoSetter):
 441
 442 2016-10-18  Sam Weinig  <sam@webkit.org>
 443
 444         Replace std::experimental::variant with WTF::Variant (or similar)
 445         https://bugs.webkit.org/show_bug.cgi?id=163626
 446
 447         Reviewed by Chris Dumez.
 448
 449         Rename std::experimental::variant, Variant. Move helpers get/holds_alternative/etc.
 450         into the WTF namespace.
 451
 452         * domjit/DOMJITReg.h:
 453         (JSC::DOMJIT::Reg::gpr):
 454         (JSC::DOMJIT::Reg::fpr):
 455         (JSC::DOMJIT::Reg::jsValueRegs):
 456
 457 2016-10-18  Keith Miller  <keith_miller@apple.com>
 458
 459         GetByVal to GetById conversion in the DFG is incorrect for getters with control flow
 460         https://bugs.webkit.org/show_bug.cgi?id=163629
 461
 462         Reviewed by Yusuke Suzuki.
 463
 464         This patch fixes a bug in the DFG when attempt to convert a
 465         GetByVal into a GetById. While converting the GetByVal, during
 466         handleGetById in the Bytecode parser, we would mistakenly use the
 467         opcode length of op_get_by_id rather than op_get_by_val. This causes
 468         the new basic block we create to point to the wrong offset. In the
 469         added test this will cause us to infinite loop.
 470
 471         * dfg/DFGByteCodeParser.cpp:
 472         (JSC::DFG::ByteCodeParser::handleGetById):
 473         (JSC::DFG::ByteCodeParser::parseBlock):
 474
 475 2016-10-18  Dean Jackson  <dino@apple.com>
 476
 477         Remove CSS_SHAPES feature definition. This should always be on.
 478         https://bugs.webkit.org/show_bug.cgi?id=163628
 479         <rdar://problem/28834613>
 480         Reviewed by Tim Horton.
 481
 482         * Configurations/FeatureDefines.xcconfig:
 483
 484 2016-10-18  Michael Saboff  <msaboff@apple.com>
 485
 486         Add JSC option to show time spent in each optimization phase
 487         https://bugs.webkit.org/show_bug.cgi?id=163617
 488
 489         Reviewed by Saam Barati.
 490
 491         Added reportDFGPhaseTimes option.  This outputs one line per phase similar to
 492             Phase CPS rethreading took 0.2661 ms
 493
 494         One line is output for each phase run.
 495
 496         * dfg/DFGPhase.h:
 497         (JSC::DFG::runAndLog):
 498         * dfg/DFGPlan.cpp:
 499         (JSC::DFG::Plan::compileInThread):
 500         * runtime/Options.cpp:
 501         (JSC::recomputeDependentOptions):
 502         * runtime/Options.h:
 503
 504 2016-10-18  Filip Pizlo  <fpizlo@apple.com>
 505
 506         WTF should make it easier to create threads that die automatically after inactivity
 507         https://bugs.webkit.org/show_bug.cgi?id=163576
 508
 509         Reviewed by Andreas Kling.
 510
 511         Added a sleepSeconds() function, which made it easier for me to test this change.
 512
 513         The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
 514         shut down automatically after 1 second of inactivity. Maybe this will save some memory.
 515
 516         * jsc.cpp:
 517         (GlobalObject::finishCreation):
 518         (functionSleepSeconds):
 519
 520 2016-10-18  Keith Miller  <keith_miller@apple.com>
 521
 522         Cleanup Wasm memory.
 523         https://bugs.webkit.org/show_bug.cgi?id=163601
 524
 525         Reviewed by Saam Barati.
 526
 527         There were a couple of issues with the original Wasm memory patch.
 528         This is a follow-up patch to fix those issues.
 529
 530         * wasm/WASMMemory.cpp:
 531         (JSC::WASM::Memory::Memory):
 532         * wasm/WASMMemory.h:
 533
 534 2016-10-15  Filip Pizlo  <fpizlo@apple.com>
 535
 536         DFG and FTL should be able to use DirectCall ICs when they proved the callee or its executable
 537         https://bugs.webkit.org/show_bug.cgi?id=163371
 538
 539         Reviewed by Geoffrey Garen and Saam Barati.
 540
 541         This adds a new kind of call inline cache for when the DFG can prove what the callee
 542         executable is. In those cases, we can skip some of the things that the traditional call IC
 543         would do:
 544
 545         - No need to check who the callee is.
 546         - No need to do arity checks.
 547
 548         This case isn't as simple as just emitting a call instruction since the callee may not be
 549         compiled at the time that the caller is compiled. So, we need lazy resolution. Also, the
 550         callee may be jettisoned independently of the caller, so we need to be able to revert the
 551         call to an unlinked state. This means that we need almost all of the things that
 552         CallLinkInfo has. CallLinkInfo already knows about different kinds of calls. This patch
 553         teaches it about new "Direct" call types.
 554
 555         The direct non-tail call IC looks like this:
 556
 557                 set up arguments
 558             FastPath:
 559                 call _SlowPath
 560                 lea -FrameSize(%rbp), %rsp
 561
 562             SlowPath:
 563                 pop
 564                 call operationLinkDirectCall
 565                 check exception
 566                 jmp FastPath
 567
 568         The job of operationLinkDirectCall is to link the fast path's call entrypoint of the callee.
 569         This means that in steady state, a call is just that: a call. There are no extra branches or
 570         checks.
 571
 572         The direct tail call IC is a bit more complicated because the act of setting up arguments
 573         destroys our frame, which would prevent us from being able to throw an exception if we
 574         failed to compile the callee. So, direct tail call ICs look like this:
 575
 576                 jmp _SlowPath
 577             FastPath:
 578                 set up arguments
 579                 jmp 0 // patch to jump to callee
 580
 581             SlowPath:
 582                 silent spill
 583                 call operationLinkDirectCall
 584                 silent fill
 585                 check exception
 586                 jmp FastPath
 587
 588         The jmp to the slow path is patched to be a fall-through jmp when we link the call.
 589
 590         Direct calls mean less code at call sites, fewer checks on the steady state call fast path,
 591         and no need for arity fixup. This looks like a slight speed-up (~0.8%) on both Octane and
 592         AsmBench.
 593
 594         * assembler/ARM64Assembler.h:
 595         (JSC::ARM64Assembler::relinkJumpToNop):
 596         * assembler/ARMv7Assembler.h:
 597         (JSC::ARMv7Assembler::relinkJumpToNop):
 598         (JSC::ARMv7Assembler::relinkJump): Deleted.
 599         * assembler/AbstractMacroAssembler.h:
 600         (JSC::AbstractMacroAssembler::repatchJumpToNop):
 601         (JSC::AbstractMacroAssembler::repatchJump): Deleted.
 602         * assembler/X86Assembler.h:
 603         (JSC::X86Assembler::relinkJumpToNop):
 604         * bytecode/CallLinkInfo.cpp:
 605         (JSC::CallLinkInfo::CallLinkInfo):
 606         (JSC::CallLinkInfo::callReturnLocation):
 607         (JSC::CallLinkInfo::patchableJump):
 608         (JSC::CallLinkInfo::hotPathBegin):
 609         (JSC::CallLinkInfo::slowPathStart):
 610         (JSC::CallLinkInfo::setCallee):
 611         (JSC::CallLinkInfo::clearCallee):
 612         (JSC::CallLinkInfo::callee):
 613         (JSC::CallLinkInfo::setCodeBlock):
 614         (JSC::CallLinkInfo::clearCodeBlock):
 615         (JSC::CallLinkInfo::codeBlock):
 616         (JSC::CallLinkInfo::setLastSeenCallee):
 617         (JSC::CallLinkInfo::clearLastSeenCallee):
 618         (JSC::CallLinkInfo::lastSeenCallee):
 619         (JSC::CallLinkInfo::haveLastSeenCallee):
 620         (JSC::CallLinkInfo::setExecutableDuringCompilation):
 621         (JSC::CallLinkInfo::executable):
 622         (JSC::CallLinkInfo::setMaxNumArguments):
 623         (JSC::CallLinkInfo::visitWeak):
 624         * bytecode/CallLinkInfo.h:
 625         (JSC::CallLinkInfo::specializationKindFor):
 626         (JSC::CallLinkInfo::callModeFor):
 627         (JSC::CallLinkInfo::isDirect):
 628         (JSC::CallLinkInfo::nearCallMode):
 629         (JSC::CallLinkInfo::isLinked):
 630         (JSC::CallLinkInfo::setCallLocations):
 631         (JSC::CallLinkInfo::addressOfMaxNumArguments):
 632         (JSC::CallLinkInfo::maxNumArguments):
 633         (JSC::CallLinkInfo::isTailCall): Deleted.
 634         (JSC::CallLinkInfo::setUpCallFromFTL): Deleted.
 635         (JSC::CallLinkInfo::callReturnLocation): Deleted.
 636         (JSC::CallLinkInfo::hotPathBegin): Deleted.
 637         (JSC::CallLinkInfo::callee): Deleted.
 638         (JSC::CallLinkInfo::setLastSeenCallee): Deleted.
 639         (JSC::CallLinkInfo::clearLastSeenCallee): Deleted.
 640         (JSC::CallLinkInfo::lastSeenCallee): Deleted.
 641         (JSC::CallLinkInfo::haveLastSeenCallee): Deleted.
 642         * bytecode/CallLinkStatus.cpp:
 643         (JSC::CallLinkStatus::computeDFGStatuses):
 644         * bytecode/PolymorphicAccess.cpp:
 645         (JSC::AccessCase::generateImpl):
 646         * bytecode/UnlinkedFunctionExecutable.h:
 647         * bytecode/ValueRecovery.h:
 648         (JSC::ValueRecovery::forEachReg):
 649         * dfg/DFGAbstractInterpreterInlines.h:
 650         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
 651         * dfg/DFGBasicBlock.h:
 652         (JSC::DFG::BasicBlock::findTerminal):
 653         * dfg/DFGByteCodeParser.cpp:
 654         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
 655         (JSC::DFG::ByteCodeParser::handleCall):
 656         * dfg/DFGClobberize.h:
 657         (JSC::DFG::clobberize):
 658         * dfg/DFGDoesGC.cpp:
 659         (JSC::DFG::doesGC):
 660         * dfg/DFGFixupPhase.cpp:
 661         (JSC::DFG::FixupPhase::fixupNode):
 662         * dfg/DFGGraph.cpp:
 663         (JSC::DFG::Graph::parameterSlotsForArgCount):
 664         * dfg/DFGGraph.h:
 665         * dfg/DFGInPlaceAbstractState.cpp:
 666         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
 667         * dfg/DFGJITCompiler.cpp:
 668         (JSC::DFG::JITCompiler::link):
 669         * dfg/DFGJITCompiler.h:
 670         (JSC::DFG::JITCompiler::addJSDirectCall):
 671         (JSC::DFG::JITCompiler::addJSDirectTailCall):
 672         (JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord):
 673         (JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord):
 674         (JSC::DFG::JITCompiler::JSDirectTailCallRecord::JSDirectTailCallRecord):
 675         (JSC::DFG::JITCompiler::currentJSCallIndex): Deleted.
 676         * dfg/DFGNode.cpp:
 677         (JSC::DFG::Node::convertToDirectCall):
 678         * dfg/DFGNode.h:
 679         (JSC::DFG::Node::isTerminal):
 680         (JSC::DFG::Node::hasHeapPrediction):
 681         (JSC::DFG::Node::hasCellOperand):
 682         * dfg/DFGNodeType.h:
 683         * dfg/DFGPredictionPropagationPhase.cpp:
 684         * dfg/DFGSafeToExecute.h:
 685         (JSC::DFG::safeToExecute):
 686         * dfg/DFGSpeculativeJIT.h:
 687         (JSC::DFG::SpeculativeJIT::callOperation):
 688         * dfg/DFGSpeculativeJIT64.cpp:
 689         (JSC::DFG::SpeculativeJIT::emitCall):
 690         (JSC::DFG::SpeculativeJIT::compile):
 691         * dfg/DFGStrengthReductionPhase.cpp:
 692         (JSC::DFG::StrengthReductionPhase::handleNode):
 693         * ftl/FTLCapabilities.cpp:
 694         (JSC::FTL::canCompile):
 695         * ftl/FTLLowerDFGToB3.cpp:
 696         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
 697         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
 698         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
 699         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
 700         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
 701         * interpreter/Interpreter.cpp:
 702         (JSC::Interpreter::execute):
 703         (JSC::Interpreter::executeCall):
 704         (JSC::Interpreter::executeConstruct):
 705         (JSC::Interpreter::prepareForRepeatCall):
 706         * jit/JIT.cpp:
 707         (JSC::JIT::link):
 708         * jit/JITCall.cpp:
 709         (JSC::JIT::compileSetupVarargsFrame):
 710         * jit/JITCall32_64.cpp:
 711         (JSC::JIT::compileSetupVarargsFrame):
 712         * jit/JITOperations.cpp:
 713         * jit/JITOperations.h:
 714         * jit/Repatch.cpp:
 715         (JSC::linkDirectFor):
 716         (JSC::revertCall):
 717         * jit/Repatch.h:
 718         * llint/LLIntSlowPaths.cpp:
 719         (JSC::LLInt::setUpCall):
 720         * runtime/Executable.cpp:
 721         (JSC::ScriptExecutable::prepareForExecutionImpl):
 722         * runtime/Executable.h:
 723         (JSC::ScriptExecutable::prepareForExecution):
 724         * runtime/Options.h:
 725
 726 2016-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
 727
 728         [DOMJIT] Not emit exception case if it is not necessary
 729         https://bugs.webkit.org/show_bug.cgi?id=163589
 730
 731         Reviewed by Sam Weinig.
 732
 733         We should not emit exception case if we do not use the slow path calls.
 734         For example, nodeType accessor does not use the slow path calls.
 735
 736         * bytecode/PolymorphicAccess.cpp:
 737         (JSC::AccessCase::emitDOMJITGetter):
 738
 739 2016-10-18  Caitlin Potter  <caitp@igalia.com>
 740
 741         [JSC] ES6 Method functions should not have prototype
 742         https://bugs.webkit.org/show_bug.cgi?id=162530
 743
 744         Reviewed by Saam Barati.
 745
 746         ECMA-262 only adds "prototype" properties to specific syntactic function forms.
 747         Specific items which do not contain "prototype" include (most) built-in functions (such as Math.pow),
 748         MethodDefinitions which are not either class "constructor" methods or GeneratorMethods, AsyncFunctions,
 749         and ArrowFunctions.
 750
 751         For details, see the following spec text, and the difference between GeneratorMethod evaluation and
 752         the evaluation of other MethodDefinition forms.
 753
 754         - https://tc39.github.io/ecma262/#sec-method-definitions-runtime-semantics-propertydefinitionevaluation
 755         - https://tc39.github.io/ecma262/#sec-arrow-function-definitions-runtime-semantics-evaluation
 756         - https://tc39.github.io/ecmascript-asyncawait/#async-function-instances
 757         - https://tc39.github.io/ecma262/#sec-generator-function-definitions-runtime-semantics-propertydefinitionevaluation
 758
 759
 760         * runtime/Executable.h:
 761         * runtime/JSFunction.cpp:
 762         (JSC::JSFunction::callerGetter):
 763         (JSC::JSFunction::getOwnPropertySlot):
 764         (JSC::JSFunction::deleteProperty):
 765
 766         * bytecompiler/BytecodeGenerator.h:
 767         (JSC::BytecodeGenerator::makeFunction):
 768         * runtime/Executable.h:
 769         * runtime/JSFunction.cpp:
 770         (JSC::JSFunction::getOwnPropertySlot):
 771         (JSC::JSFunction::getOwnNonIndexPropertyNames):
 772         (JSC::JSFunction::put):
 773         (JSC::JSFunction::deleteProperty):
 774         (JSC::JSFunction::defineOwnProperty):
 775         * runtime/JSGlobalObjectFunctions.cpp:
 776         (JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller):
 777
 778 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
 779
 780         [DOMJIT] Use NativeCallFrameTracer for operations used for DOMJIT slow calls
 781         https://bugs.webkit.org/show_bug.cgi?id=163586
 782
 783         Reviewed by Saam Barati.
 784
 785         C functions called from the DOMJIT slow path calls should use NativeCallFrameTracer.
 786         This fixes the debug assertion caused in r207427.
 787
 788         * bytecode/DOMJITAccessCasePatchpointParams.cpp:
 789         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
 790         (JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
 791         * bytecode/DOMJITAccessCasePatchpointParams.h:
 792         * bytecode/PolymorphicAccess.cpp:
 793         (JSC::AccessCase::emitDOMJITGetter):
 794         * jsc.cpp:
 795         (WTF::DOMJITGetter::DOMJITNodeDOMJIT::slowCall):
 796         (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall):
 797
 798 2016-10-17  Keith Miller  <keith_miller@apple.com>
 799
 800         Add support for WASM Memory.
 801         https://bugs.webkit.org/show_bug.cgi?id=161710
 802
 803         Reviewed by Geoffrey Garen.
 804
 805         This patch add initial support for WASM memory operations. First,
 806         it adds the concept of a WASM Module memory management object.
 807         This object currently mmaps a 32-bit address space for WASM use,
 808         although it marks all the memory outside the current breakpoint as
 809         PROT_NONE. For now, we do a range check on each store and load. In
 810         the future, we should change this to be an signal handler that
 811         checks what module the program trapped in.
 812
 813         Additionally, this patch changes the way that our temporary tests
 814         call into WASM code. There is now a true "thunk" that relocates
 815         arguments and calls into WASM. This thunk does not tail call
 816         because we use pinned values to memory base-pointer and
 817         size. We use the new B3 pinned register api to pin the values.
 818
 819         * CMakeLists.txt:
 820         * Configurations/ToolExecutable.xcconfig:
 821         * JavaScriptCore.xcodeproj/project.pbxproj:
 822         * testWASM.cpp:
 823         (runWASMTests):
 824         (main):
 825         * wasm/WASMB3IRGenerator.cpp:
 826         (JSC::WASM::createJSWrapper):
 827         (JSC::WASM::parseAndCompile):
 828         * wasm/WASMB3IRGenerator.h:
 829         * wasm/WASMCallingConvention.h:
 830         (JSC::WASM::CallingConvention::iterate):
 831         (JSC::WASM::CallingConvention::setupCall):
 832         (JSC::WASM::nextJSCOffset):
 833         * wasm/WASMFormat.h:
 834         * wasm/WASMFunctionParser.h:
 835         (JSC::WASM::FunctionParser<Context>::parseExpression):
 836         * wasm/WASMMemory.cpp: Copied from Source/JavaScriptCore/wasm/WASMPlan.cpp.
 837         (JSC::WASM::Memory::Memory):
 838         * wasm/WASMMemory.h: Copied from Source/JavaScriptCore/wasm/WASMModuleParser.h.
 839         (JSC::WASM::Memory::~Memory):
 840         (JSC::WASM::Memory::memory):
 841         (JSC::WASM::Memory::size):
 842         (JSC::WASM::Memory::pinnedRegisters):
 843         (JSC::WASM::Memory::mode):
 844         (JSC::WASM::Memory::growMemory):
 845         (JSC::WASM::Memory::offsetOfSize):
 846         * wasm/WASMModuleParser.cpp:
 847         (JSC::WASM::ModuleParser::parse):
 848         (JSC::WASM::ModuleParser::parseMemory):
 849         * wasm/WASMModuleParser.h:
 850         (JSC::WASM::ModuleParser::functionInformation):
 851         (JSC::WASM::ModuleParser::memory):
 852         * wasm/WASMOps.h:
 853         * wasm/WASMPlan.cpp:
 854         (JSC::WASM::Plan::Plan):
 855         * wasm/WASMPlan.h:
 856         * wasm/WASMSections.h:
 857
 858 2016-10-17  Joseph Pecoraro  <pecoraro@apple.com>
 859
 860         Web Inspector: Add toggles for debugger pauses at console.assert failures
 861         https://bugs.webkit.org/show_bug.cgi?id=139542
 862         <rdar://problem/19281600>
 863
 864         Reviewed by Timothy Hatcher.
 865
 866         * inspector/agents/InspectorDebuggerAgent.h:
 867         * inspector/agents/InspectorDebuggerAgent.cpp:
 868         (Inspector::InspectorDebuggerAgent::disable):
 869         (Inspector::InspectorDebuggerAgent::setPauseOnAssertions):
 870         Toggle pause on assertions state. Default is disabled,
 871         and disable it when frontends disconnect.
 872
 873         (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
 874         Instead of using the PauseOnAllExceptions state, use this
 875         new state specific to assertions.
 876
 877         * inspector/protocol/Debugger.json:
 878         New protocol method to toggle pausing on assertions.
 879
 880 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
 881
 882         [DOMJIT][JSC] Add Option::useDOMJIT
 883         https://bugs.webkit.org/show_bug.cgi?id=163457
 884
 885         Reviewed by Saam Barati.
 886
 887         Add an option to switch the DOMJIT optimization.
 888
 889         * bytecode/PolymorphicAccess.cpp:
 890         (JSC::AccessCase::generateImpl):
 891         * dfg/DFGByteCodeParser.cpp:
 892         (JSC::DFG::ByteCodeParser::handleGetById):
 893         * runtime/Options.cpp:
 894         (JSC::recomputeDependentOptions):
 895         * runtime/Options.h:
 896
 897 2016-10-17  Filip Pizlo  <fpizlo@apple.com>
 898
 899         Air::IRC doesn't need to have a special-case for uncolored Tmps since they all get colored
 900         https://bugs.webkit.org/show_bug.cgi?id=163548
 901         <rdar://problem/28804381>
 902
 903         Reviewed by Geoffrey Garen.
 904
 905         Before r207408, IRC had a mode where it would silently assign the first assignable register (so
 906         %rax, %xmm0, etc) to any tmp that was not colorable due to a pathological interference fencepost.
 907         We reason about interference at instruction boundaries. This means that if you have, for example,
 908         an instruction that clobbers all registers late followed by an instruction that has an early def
 909         in the same register file, then the early def will not be colorable because it interferes with
 910         all registers. This already happens in our tests, but IRC silently returns the first assignable
 911         register to such tmps. For some reason the resulting code works OK - probably because this tends
 912         to only be hit by fuzzing, which may not then stress that code enough to shake out the register
 913         corruption. Also, this can only happen for floating point registers, so it's hard to get an
 914         exciting crash. The worst case is that your numbers get all messed up.
 915
 916         This change fixes the issue:
 917
 918         - IRC will now crash if it can't color a tmp.
 919
 920         - IRC doesn't crash on our tests anymore because I added a padInterference() utility that works
 921           around the interference problem by inserting Nops to pad between those instructions where
 922           conflating their early and late actions into one interference fencepost could create an
 923           uncolorable graph.
 924
 925         See https://bugs.webkit.org/show_bug.cgi?id=163548#c2 for a detailed discussion of how the
 926         problem can arise.
 927
 928         This problem almost made me want to abandon our use of interference at instruction boundaries,
 929         and introduce something more comprehensive, like interference at various stages of an
 930         instruction's execution. The reason why I didn't do this is that this problem only arises in well
 931         confined corner cases: you need an instruction that does a late use or def followed by an
 932         instruction that does an early def. Register clobbers count as defs for this equation.
 933         Fortunately, early defs are rare, and even when they do happen, you still need the previous
 934         instruction to have a late something. Late uses are rare and many instructions don't have defs at
 935         all, which means that it's actually pretty common for an instruction to not have anything late.
 936         This means that the padInterference() strategy is ideal: our algorithms stay simple because they
 937         only have to worry about interference at boundaries, and we rarely insert any Nops in
 938         padInterference() so the IR stays nice and compact. Those Nops get removed by any phase that does
 939         DCE, which includes eliminateDeadCode(), allocateStack(), and reportUsedRegisters(). In practice
 940         allocateStack() kills them.
 941
 942         This also finally refactors our passing of RegisterSet to pass it by value, since it's small
 943         enough that we're not gaining anything by using references. On x86, RegisterSet ought to be
 944         smaller than a pointer.
 945
 946         * CMakeLists.txt:
 947         * JavaScriptCore.xcodeproj/project.pbxproj:
 948         * b3/B3StackmapSpecial.cpp:
 949         (JSC::B3::StackmapSpecial::extraClobberedRegs):
 950         (JSC::B3::StackmapSpecial::extraEarlyClobberedRegs):
 951         * b3/B3StackmapSpecial.h:
 952         * b3/air/AirCCallSpecial.cpp:
 953         (JSC::B3::Air::CCallSpecial::extraEarlyClobberedRegs):
 954         (JSC::B3::Air::CCallSpecial::extraClobberedRegs):
 955         * b3/air/AirCCallSpecial.h:
 956         * b3/air/AirInst.h:
 957         * b3/air/AirInstInlines.h:
 958         (JSC::B3::Air::Inst::extraClobberedRegs):
 959         (JSC::B3::Air::Inst::extraEarlyClobberedRegs):
 960         * b3/air/AirIteratedRegisterCoalescing.cpp:
 961         (JSC::B3::Air::iteratedRegisterCoalescing):
 962         * b3/air/AirPadInterference.cpp: Added.
 963         (JSC::B3::Air::padInterference):
 964         * b3/air/AirPadInterference.h: Added.
 965         * b3/air/AirSpecial.h:
 966         * b3/air/AirSpillEverything.cpp:
 967         (JSC::B3::Air::spillEverything):
 968         * jit/RegisterSet.h:
 969         (JSC::RegisterSet::isEmpty):
 970
 971 2016-10-17  JF Bastien  <jfbastien@apple.com>
 972
 973         WebAssembly JS API: implement basic stub
 974
 975         Implement the global WebAssembly JavaScript object, and its constructor +
 976         function properties as described in:
 977           https://github.com/WebAssembly/design/blob/master/JS.md
 978
 979         These don't do anything at the moment, the parent bug will take care of adding
 980         more functionality and associated tests.
 981
 982         WebAssembly JS API: implement basic stub
 983         https://bugs.webkit.org/show_bug.cgi?id=163404
 984
 985         Reviewed by Keith Miller.
 986
 987         * CMakeLists.txt:
 988         * JavaScriptCore.xcodeproj/project.pbxproj:
 989         * builtins/BuiltinNames.h: register the new WebAssembly object's name and its constructor properties
 990         * jsc.cpp: remove useless include
 991         * runtime/JSGlobalObject.cpp:
 992         (JSC::JSGlobalObject::init): add the WebAssembly global object and its constructor properties, but only if the JSC option enables it
 993         * runtime/Options.h: add the useWebAssembly (alias: enableWebAssembly) option, defaulting to false
 994         * wasm/WebAssemblyObject.cpp: Added.
 995         (JSC::WebAssemblyObject::create): boilerplate
 996         (JSC::WebAssemblyObject::createStructure): boilerplate
 997         (JSC::WebAssemblyObject::finishCreation): boilerplate
 998         (JSC::WebAssemblyObject::WebAssemblyObject): boilerplate
 999         (JSC::wasmObjectFuncvalidate): auto-throws for now
1000         (JSC::wasmObjectFunccompile): auto-throws for now
1001         * wasm/WebAssemblyObject.h: Added.
1002
1003 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1004
1005         Unreviewed, build fix after r207428
1006         https://bugs.webkit.org/show_bug.cgi?id=163223
1007
1008         Previous build fix r207428 broke all the builds.
1009
1010         * bytecode/PolymorphicAccess.h:
1011
1012 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1013
1014         Unreviewed, build fix for GTK and Windows
1015         https://bugs.webkit.org/show_bug.cgi?id=163223
1016
1017         Attempt to fix build failures in GTK port and Windows port.
1018
1019         * bytecode/PolymorphicAccess.cpp:
1020         * bytecode/PolymorphicAccess.h:
1021         (JSC::AccessGenerationState::SpillState::SpillState):
1022
1023 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1024
1025         [DOMJIT] Use DOMJIT::Patchpoint in IC
1026         https://bugs.webkit.org/show_bug.cgi?id=163223
1027
1028         Reviewed by Saam Barati.
1029
1030         This patch uses DOMJIT::Patchpoint to inline DOM accesses even in IC!
1031         It is useful for Baseline JIT cases and GetById cases in DFG and FTL.
1032         In AccessCase, we construct the environment that allows DOMJIT::Patchpoint
1033         to emit code and make DOMJIT accessors inlined in IC.
1034
1035         To allow DOMJIT::Patchpoint to emit code, we create a mechanism to emit calls
1036         required in DOMJIT::Patchpoint. This system is useful when we create the super-
1037         polymorphic support[1] later. And inlining mechanism is useful even after
1038         introducing super-polymorphic support since it can work even after we fire the
1039         watchpoint for super-polymorphic handling.
1040
1041         This patch improves Dromaeo dom-traverse 8% (263.95 runs/s v.s. 244.07 runs/s).
1042
1043         [1]: https://bugs.webkit.org/show_bug.cgi?id=163226
1044
1045         * CMakeLists.txt:
1046         * JavaScriptCore.xcodeproj/project.pbxproj:
1047         * bytecode/DOMJITAccessCasePatchpointParams.cpp: Added.
1048         (JSC::SlowPathCallGeneratorWithArguments::SlowPathCallGeneratorWithArguments):
1049         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
1050         (JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
1051         * bytecode/DOMJITAccessCasePatchpointParams.h: Copied from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h.
1052         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
1053         (JSC::DOMJITAccessCasePatchpointParams::SlowPathCallGenerator::~SlowPathCallGenerator):
1054         * bytecode/PolymorphicAccess.cpp:
1055         (JSC::AccessGenerationState::liveRegistersForCall):
1056         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
1057         (JSC::calleeSaveRegisters):
1058         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
1059         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
1060         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
1061         (JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
1062         (JSC::AccessGenerationState::originalExceptionHandler):
1063         (JSC::AccessCase::generateImpl):
1064         (JSC::AccessCase::emitDOMJITGetter):
1065         (JSC::PolymorphicAccess::regenerate):
1066         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall): Deleted.
1067         * bytecode/PolymorphicAccess.h:
1068         (JSC::AccessGenerationState::SpillState::isEmpty):
1069         (JSC::AccessGenerationState::setSpillStateForJSGetterSetter):
1070         (JSC::AccessGenerationState::spillStateForJSGetterSetter):
1071         (JSC::AccessGenerationState::liveRegistersForCall): Deleted.
1072         (JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation): Deleted.
1073         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite): Deleted.
1074         * dfg/DFGDOMJITPatchpointParams.cpp:
1075         * dfg/DFGDOMJITPatchpointParams.h:
1076         * domjit/DOMJITPatchpoint.h:
1077         * domjit/DOMJITPatchpointParams.h:
1078         (JSC::DOMJIT::PatchpointParams::addSlowPathCall):
1079         * ftl/FTLDOMJITPatchpointParams.cpp:
1080         * ftl/FTLDOMJITPatchpointParams.h:
1081         * jsc.cpp:
1082         (WTF::DOMJITNode::checkDOMJITNode):
1083         (WTF::DOMJITGetterComplex::DOMJITGetterComplex):
1084         (WTF::DOMJITGetterComplex::createStructure):
1085         (WTF::DOMJITGetterComplex::create):
1086         (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
1087         (WTF::DOMJITGetterComplex::domJITNodeGetterSetter):
1088         (WTF::DOMJITGetterComplex::finishCreation):
1089         (WTF::DOMJITGetterComplex::functionEnableException):
1090         (WTF::DOMJITGetterComplex::customGetter):
1091         (GlobalObject::finishCreation):
1092         (functionCreateDOMJITGetterComplexObject):
1093
1094 2016-10-17  Saam Barati  <sbarati@apple.com>
1095
1096         Build fix for HasOwnPropertyCache::Entry caused slowdown by introducing a constructor that doesn't use move semantics for the RefPtr<UniquedStringImpl> parameter
1097         https://bugs.webkit.org/show_bug.cgi?id=163490
1098
1099         Reviewed by Darin Adler.
1100
1101         * runtime/HasOwnPropertyCache.h:
1102         (JSC::HasOwnPropertyCache::Entry::Entry):
1103         (JSC::HasOwnPropertyCache::tryAdd):
1104
1105 2016-10-17  Mark Lam  <mark.lam@apple.com>
1106
1107         Use the reject() helper function for conditionally throwing TypeErrors.
1108         https://bugs.webkit.org/show_bug.cgi?id=163491
1109
1110         Reviewed by Filip Pizlo.
1111
1112         In some places where we may conditionally throw a TypeError (e.g. when in strict
1113         mode), we already use the reject() helper function to conditionally throw the
1114         TypeError.  Doing so makes the code mode compact.  This patch applies this idiom
1115         consistently in all places that throws TypeError where appropriate.
1116
1117         This patch also does the following:
1118         1. Make the reject() helper function take an ASCIILiteral instead of a const char*
1119            because we always pass it a literal string anyway.
1120         2. Change the reject helper() to take a ThrowScope&.  This allows the thrown
1121            error to be attributed to its caller.
1122         3. When an error message string is instantiated repeatedly in more than 1 place,
1123            create a common copy of that literal string in JSObject.cpp (if one doesn't
1124            already exist) and use that common string in all those places.
1125         4. Since I was auditing call sites of throwTypeError() to check if they should be
1126            using the reject() helper instead, I also fixed those up to pass the error
1127            message as an ASCIILiteral where appropriate.
1128         5. In functions that I touched, change the code to not recompute the VM& when it
1129            is already available.
1130
1131         * jit/JITOperations.cpp:
1132         * llint/LLIntSlowPaths.cpp:
1133         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1134         * runtime/ArrayPrototype.cpp:
1135         (JSC::shift):
1136         (JSC::unshift):
1137         (JSC::arrayProtoFuncPop):
1138         (JSC::arrayProtoFuncReverse):
1139         * runtime/CommonSlowPaths.cpp:
1140         (JSC::SLOW_PATH_DECL):
1141         * runtime/GetterSetter.cpp:
1142         (JSC::callSetter):
1143         * runtime/JSArray.cpp:
1144         (JSC::JSArray::defineOwnProperty):
1145         (JSC::JSArray::setLengthWithArrayStorage):
1146         (JSC::JSArray::pop):
1147         * runtime/JSArrayBuffer.cpp:
1148         (JSC::JSArrayBuffer::put):
1149         (JSC::JSArrayBuffer::defineOwnProperty):
1150         * runtime/JSCJSValue.cpp:
1151         (JSC::JSValue::putToPrimitive):
1152         (JSC::JSValue::putToPrimitiveByIndex):
1153         * runtime/JSDataView.cpp:
1154         (JSC::JSDataView::put):
1155         (JSC::JSDataView::defineOwnProperty):
1156         * runtime/JSFunction.cpp:
1157         (JSC::JSFunction::put):
1158         (JSC::JSFunction::defineOwnProperty):
1159         * runtime/JSGenericTypedArrayView.h:
1160         (JSC::JSGenericTypedArrayView::setIndex):
1161         * runtime/JSGenericTypedArrayViewInlines.h:
1162         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
1163         (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
1164         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1165         (JSC::speciesConstruct):
1166         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
1167         * runtime/JSModuleNamespaceObject.cpp:
1168         (JSC::JSModuleNamespaceObject::defineOwnProperty):
1169         * runtime/JSObject.cpp:
1170         (JSC::ordinarySetSlow):
1171         (JSC::JSObject::putInlineSlow):
1172         (JSC::JSObject::setPrototypeWithCycleCheck):
1173         (JSC::JSObject::defineOwnIndexedProperty):
1174         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
1175         (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
1176         (JSC::validateAndApplyPropertyDescriptor):
1177         * runtime/JSObject.h:
1178         * runtime/JSObjectInlines.h:
1179         (JSC::JSObject::putInline):
1180         * runtime/JSProxy.cpp:
1181         (JSC::JSProxy::setPrototype):
1182         * runtime/JSSymbolTableObject.h:
1183         (JSC::symbolTablePut):
1184         * runtime/Lookup.h:
1185         (JSC::putEntry):
1186         * runtime/RegExpObject.cpp:
1187         (JSC::RegExpObject::defineOwnProperty):
1188         * runtime/RegExpObject.h:
1189         (JSC::RegExpObject::setLastIndex):
1190         * runtime/Reject.h:
1191         (JSC::reject):
1192         * runtime/SparseArrayValueMap.cpp:
1193         (JSC::SparseArrayValueMap::putEntry):
1194         (JSC::SparseArrayValueMap::putDirect):
1195         (JSC::SparseArrayEntry::put):
1196         * runtime/StringObject.cpp:
1197         (JSC::StringObject::put):
1198         (JSC::StringObject::putByIndex):
1199         * runtime/SymbolConstructor.cpp:
1200         (JSC::symbolConstructorKeyFor):
1201
1202 2016-10-16  Filip Pizlo  <fpizlo@apple.com>
1203
1204         Air::IRC needs to place all Tmps on some worklist, even if they have no interference edges
1205         https://bugs.webkit.org/show_bug.cgi?id=163509
1206
1207         Reviewed by Mark Lam.
1208
1209         The worklist building function in IRC skips temporaries that have no degree. This doesn't appear
1210         to be necessary. This has been there since the original IRC commit. It hasn't caused bugs because
1211         ordinarily, the only way to have a tmp with no degree is to not have any mention of that tmp. But
1212         while working on bug 163371, I hit a crazy corner case where a temporary would have no
1213         interference edges (i.e. no degree). Here's how it happens:
1214
1215         A spill tmp from a previous iteration of IRC may have no degree: imagine a tmp that is live
1216         everywhere and interferes with everyone, but has one use like:
1217
1218         Move %ourTmp, %someOtherTmp
1219
1220         Where there are no other tmps live.  After spill conversion, this may look like:
1221
1222         Move (ourSpill), %newTmp
1223         Move %newTmp, %someOtherTmp
1224
1225         Of course, we'd rather not get this kind of spill code but it's totally possible because we now
1226         have a bunch of random conditions under which we won't slap the spill address directly into the
1227         Move.
1228
1229         After this happens, assuming that the only thing live was %someOtherTmp, we will have zero degree
1230         for %newTmp because the Move is coalescable and does not contribute to interference.
1231
1232         Then, we might coalesce %someOtherTmp with %newTmp.  Once this happens, if we make the %newTmp be
1233         the master, we're in deep trouble because %newTmp is not on any worklist.
1234
1235         I don't know how to reproduce this except through the patch in bug 163371. Removing the two lines
1236         of code that skipped no-degree tmps causes no regressions, and resolves the problem I was having.
1237
1238         * b3/air/AirIteratedRegisterCoalescing.cpp:
1239
1240 2016-10-15  Mark Lam  <mark.lam@apple.com>
1241
1242         Add a $vm.getpid() method.
1243         https://bugs.webkit.org/show_bug.cgi?id=163493
1244
1245         Reviewed by Saam Barati.
1246
1247         This is especially useful when we need to know the pid of an instance of jsc in
1248         the foreground that we're trying to attach a debugger to while the JSC tests are
1249         running in the background with a gazillion other jsc processes live at the same
1250         time.
1251
1252         Currently, $vm.getpid() is only supported on non-Windows platforms.
1253         According to https://msdn.microsoft.com/en-us/library/ms235372.aspx, getpid() is
1254         deprecated.  According to https://msdn.microsoft.com/en-us/library/t2y34y40.aspx,
1255         _getpid() cannot be used in applications that execute in the Windows Runtime.
1256
1257         Since this is only a debugging tool and is not a required feature, I'll defer
1258         the Windows implementation of this function till the time when someone actually
1259         needs it.
1260
1261         * tools/JSDollarVMPrototype.cpp:
1262         (JSC::functionGetPID):
1263         (JSC::JSDollarVMPrototype::finishCreation):
1264
1265 2016-10-15  Saam Barati  <sbarati@apple.com>
1266
1267         Assertion failed under operationToLowerCase with a rope with zero length
1268         https://bugs.webkit.org/show_bug.cgi?id=163314
1269
1270         Reviewed by Mark Lam.
1271
1272         There are some ways to get JSC to create empty rope strings. ToLowerCase
1273         inside the DFG/FTL goes to the slow path when the argument is a rope.
1274         operationToLowerCase was calling into a WTF string function that
1275         assumed we are passing it a this value that has non-zero length.
1276         However, we were calling it with a string that did have zero length.
1277         To fix this, we make operationToLowerCase return the empty JSString
1278         if it is going to make a string with zero length.
1279
1280         * dfg/DFGOperations.cpp:
1281         * jsc.cpp:
1282         (GlobalObject::finishCreation):
1283         (functionIsRope):
1284
1285 2016-10-14  Benjamin Poulain  <bpoulain@apple.com>
1286
1287         [JSC] op_negate should with any type
1288         https://bugs.webkit.org/show_bug.cgi?id=162587
1289
1290         Reviewed by Saam Barati.
1291
1292         * dfg/DFGAbstractInterpreterInlines.h:
1293         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1294         ArithNegate is quite simple. If the input is double, the output
1295         is double. The other cases are set from the LLInt slow case.
1296
1297         * dfg/DFGByteCodeParser.cpp:
1298         (JSC::DFG::ByteCodeParser::makeSafe):
1299         * dfg/DFGClobberize.h:
1300         (JSC::DFG::clobberize):
1301         * dfg/DFGFixupPhase.cpp:
1302         (JSC::DFG::FixupPhase::fixupNode):
1303
1304         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1305         Tweak a bit the IntegerRangeOptimizationPhase when simplifying
1306         ArithAbs to ArithNegate.
1307         We should not do the conversion if the target nodes OSR Exits
1308         on different input than the source node.
1309
1310         In particular, Checked ArithNegate exits on zero while
1311         ArithAbs has not problem with it.
1312         Unchecked ArithAbs() do not OSR Exit on INT_MIN, ArithNeg
1313         should not either.
1314
1315         * dfg/DFGPredictionPropagationPhase.cpp:
1316         * dfg/DFGSpeculativeJIT.cpp:
1317         (JSC::DFG::SpeculativeJIT::compileArithNegate):
1318         (JSC::DFG::SpeculativeJIT::compileMathIC):
1319         * dfg/DFGSpeculativeJIT.h:
1320         (JSC::DFG::SpeculativeJIT::callOperation):
1321         * ftl/FTLLowerDFGToB3.cpp:
1322         (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
1323         (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
1324
1325         * jit/JITNegGenerator.cpp:
1326         (JSC::JITNegGenerator::generateFastPath):
1327         * jit/JITOperations.cpp:
1328         Add result profiling in baseline to have types we can use
1329         in DFG and FTL.
1330
1331 2016-10-14  Keith Miller  <keith_miller@apple.com>
1332
1333         B3 needs a special WasmAddress Opcode
1334         https://bugs.webkit.org/show_bug.cgi?id=163394
1335
1336         Reviewed by Filip Pizlo.
1337
1338         This patch adds support for WasmAddress. WasmAddress will be used by
1339         Wasm to compute the address of a memory operation from the pinned
1340         base pointer. WasmAddress takes an IntPtr so we can avoid emitting
1341         unnecessary Move32s in Air. This could happen in the following case:
1342
1343         @ptr = Trunc(...)
1344         WasmAddress(@ptr, pinnedGPR)
1345         ...
1346         PatchPoint(...) // Do Wasm call
1347         WasmAddress(@ptr, pinnedGPR)
1348         ...
1349
1350         In this case we will not be able to CSE the WasmAddresses since the
1351         call writes to pinnedGPR. Thus if WasmAddress took an Int32 we would need
1352         to emit an extra Move32 at the second WasmAddress to ensure it saw a proper
1353         32-bit value. If Wasm ensures that there there is a leading ZExt32 then
1354         the duplicated moves become unnecessary.
1355
1356         * CMakeLists.txt:
1357         * JavaScriptCore.xcodeproj/project.pbxproj:
1358         * b3/B3LowerToAir.cpp:
1359         (JSC::B3::Air::LowerToAir::effectiveAddr):
1360         (JSC::B3::Air::LowerToAir::lower):
1361         * b3/B3Opcode.cpp:
1362         (WTF::printInternal):
1363         * b3/B3Opcode.h:
1364         * b3/B3Validate.cpp:
1365         * b3/B3Value.cpp:
1366         (JSC::B3::Value::effects):
1367         * b3/B3WasmAddressValue.cpp: Added.
1368         (JSC::B3::WasmAddressValue::~WasmAddressValue):
1369         (JSC::B3::WasmAddressValue::dumpMeta):
1370         (JSC::B3::WasmAddressValue::cloneImpl):
1371         (JSC::B3::WasmAddressValue::WasmAddressValue):
1372         * b3/B3WasmAddressValue.h: Added.
1373         * b3/testb3.cpp:
1374         (JSC::B3::testWasmAddress):
1375         (JSC::B3::run):
1376
1377 2016-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1378
1379         test262: @isConstructor incorrectly thinks Math.cos is a constructor
1380         https://bugs.webkit.org/show_bug.cgi?id=163437
1381
1382         Reviewed by Saam Barati.
1383
1384         * runtime/JSFunction.cpp:
1385         (JSC::JSFunction::getConstructData):
1386         By default, Host JSFunctions are not constructable. They get
1387         the default callHostFunctionAsConstructor native constructor.
1388         When getting construct data we can return ConstructType::None
1389         in these cases instead of indicating it might be constructable
1390         and later throwing an exception when construction is attempted.
1391
1392 2016-10-14  Ryan Haddad  <ryanhaddad@apple.com>
1393
1394         Unreviewed, rolling out r207322.
1395
1396         This change caused JSC test failures
1397
1398         Reverted changeset:
1399
1400         "Fix Array.prototype.splice ES6 compliance."
1401         https://bugs.webkit.org/show_bug.cgi?id=163372
1402         http://trac.webkit.org/changeset/207322
1403
1404 2016-10-14  Mark Lam  <mark.lam@apple.com>
1405
1406         JSON.parse should not modify frozen objects.
1407         https://bugs.webkit.org/show_bug.cgi?id=163430
1408
1409         Reviewed by Saam Barati.
1410
1411         The ES6 spec for JSON.parse (https://tc39.github.io/ecma262/#sec-json.parse and
1412         https://tc39.github.io/ecma262/#sec-internalizejsonproperty) states that it uses
1413         CreateDataProperty() (https://tc39.github.io/ecma262/#sec-createdataproperty) to
1414         set values returned by a reviver.  The spec for CreateDataPropertyOrThrow states:
1415
1416         "This abstract operation creates a property whose attributes are set to the same
1417         defaults used for properties created by the ECMAScript language assignment
1418         operator. Normally, the property will not already exist. If it does exist and is
1419         not configurable or if O is not extensible, [[DefineOwnProperty]] will return
1420         false."
1421
1422         Note: CreateDataProperty() will not throw a TypeError.
1423
1424         Since the properties of frozen objects are not extensible, not configurable, and
1425         not writeable, JSON.parse should fail to write to any frozen objects.  Similarly,
1426         JSON.parse should fail to delete properties in frozen objects.
1427
1428         In JSON.parse(), we previously write to array elements using the form of
1429         putDirectIndex() that uses mode PutDirectIndexLikePutDirect.  This makes it so
1430         that the write (i.e. put) is always successful.  We've now fixed this to use
1431         PutDirectIndexShouldNotThrow mode instead, which will fail to put the element if
1432         the array is not writeable.
1433
1434         Also changed Walker::walk() to use the version of methodTable() that takes a VM&
1435         since the VM& is already available.
1436
1437         * runtime/JSONObject.cpp:
1438         (JSC::Walker::walk):
1439
1440 2016-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1441
1442         test262: Failure with RegExp.prototype.compile when pattern is undefined
1443         https://bugs.webkit.org/show_bug.cgi?id=163431
1444
1445         Reviewed by Yusuke Suzuki.
1446
1447         If pattern is undefined let P be the empty String.
1448         https://tc39.github.io/ecma262/#sec-regexpinitialize
1449
1450         * runtime/RegExpPrototype.cpp:
1451         (JSC::regExpProtoFuncCompile):
1452
1453 2016-10-13  Joseph Pecoraro  <pecoraro@apple.com>
1454
1455         Exception message for expressions with multiple bracket accesses is inconsistent / incorrect
1456         https://bugs.webkit.org/show_bug.cgi?id=163426
1457
1458         Reviewed by Geoffrey Garen.
1459
1460         * bytecompiler/NodesCodegen.cpp:
1461         (JSC::BracketAccessorNode::emitBytecode):
1462         It matters where emitExpressionInfo is called since it gathers
1463         info about where we are in the instruction stream. We need to
1464         emit it before the bytecode that we want to associate the data
1465         with. In this case, before the getById / getByVal.
1466
1467 2016-10-13  Mark Lam  <mark.lam@apple.com>
1468
1469         Fix Array.prototype.splice ES6 compliance.
1470         https://bugs.webkit.org/show_bug.cgi?id=163372
1471
1472         Reviewed by Geoffrey Garen and Yusuke Suzuki.
1473
1474         Our Array.prototype.splice implementation neglected to set length on the result
1475         array (step 12 of https://tc39.github.io/ecma262/#sec-array.prototype.splice) in
1476         a certain code path.  This is now fixed.
1477
1478         I'm deferring the implementation of step 8 till later because it requires more
1479         careful consideration and the fix is of a lesser value (and therefore, of less
1480         urgency).  See https://bugs.webkit.org/show_bug.cgi?id=163417
1481
1482         Also added some needed exception checks and assertions.
1483
1484         * runtime/ArrayPrototype.cpp:
1485         (JSC::arrayProtoFuncSplice):
1486
1487 2016-10-13  Joseph Pecoraro  <pecoraro@apple.com>
1488
1489         Web Inspector: Stepping highlight for dot/bracket expressions in if statements highlights subset of the expression
1490         https://bugs.webkit.org/show_bug.cgi?id=163378
1491         <rdar://problem/28749376>
1492
1493         Reviewed by Saam Barati.
1494
1495         * parser/Parser.cpp:
1496         (JSC::Parser<LexerType>::parseAssignmentExpression):
1497         Since each expression builds on the previous, always keep the starting
1498         location the first location.
1499
1500 2016-10-13  Per Arne Vollan  <pvollan@apple.com>
1501
1502         [Win64] Compile fix.
1503         https://bugs.webkit.org/show_bug.cgi?id=163384
1504
1505         Reviewed by Brent Fulgham.
1506
1507         Fix use of potentially uninitialized variable.
1508
1509         * dfg/DFGSpeculativeJIT64.cpp:
1510         (JSC::DFG::SpeculativeJIT::compile):
1511
1512 2016-10-12  Chris Dumez  <cdumez@apple.com>
1513
1514         [Web IDL] Drop support for legacy [ConstructorConditional=*]
1515         https://bugs.webkit.org/show_bug.cgi?id=163368
1516
1517         Reviewed by Ryosuke Niwa.
1518
1519         Drop ENABLE_DOM4_EVENTS_CONSTRUCTOR compiler flag.
1520
1521         * Configurations/FeatureDefines.xcconfig:
1522
1523 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
1524
1525         Web Inspector: step-into `console.log(o)` should not step through inspector javascript
1526         https://bugs.webkit.org/show_bug.cgi?id=161656
1527         <rdar://problem/28181123>
1528
1529         Reviewed by Timothy Hatcher.
1530
1531         * debugger/Debugger.h:
1532         * debugger/Debugger.cpp:
1533         (JSC::Debugger::pauseIfNeeded):
1534         If the Script is blacklisted skip checking if we need to pause.
1535
1536         (JSC::Debugger::isBlacklisted):
1537         (JSC::Debugger::addToBlacklist):
1538         (JSC::Debugger::clearBlacklist):
1539         Add the ability to add a Script to a blacklist. Currently the blacklist
1540         only prevents pausing in the Script.
1541
1542         * inspector/agents/InspectorDebuggerAgent.cpp:
1543         (Inspector::isWebKitInjectedScript):
1544         (Inspector::InspectorDebuggerAgent::didParseSource):
1545         Always add Internal InjectedScripts to the Debugger's blacklist.
1546
1547         (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
1548         Clear blacklists when clearing debugger state.
1549
1550 2016-10-12  Keith Miller  <keith_miller@apple.com>
1551
1552         B3 needs a special WasmBoundsCheck Opcode
1553         https://bugs.webkit.org/show_bug.cgi?id=163246
1554
1555         Reviewed by Filip Pizlo.
1556
1557         This patch adds a new Opcode, WasmBoundsCheck, as well as a B3::Value subclass for it,
1558         WasmBoundsCheckValue. WasmBoundsCheckValue takes three pieces of information. The first is
1559         the Int32 pointer value used to be used by the Load.  Next is the pinned register. The
1560         pinned register must be pinned by calling proc.setPinned() prior to compiling the
1561         Procedure. Lastly, the WasmBoundsCheckValue takes an offset. The WasmBoundsCheckValue is
1562         will then emit code that side-exits if the Int64 sum of the offset and pointer is greater
1563         than or equal to the value in the pinnedRegister. Instead of taking a generator for each
1564         value like Check/Patchpoint, WasmBoundsCheck gets its generator directly off Air::Code. In
1565         Air this patch adds a new Custom opcode, WasmBoundsCheck.
1566
1567         In the future we should add WasmBoundsCheck to CSE so it can eliminate redundant bounds
1568         checks. At the first cut, we can remove any WasmBoundsCheck dominated by another
1569         WasmBoundsCheck with the same pointer and pinnedGPR, and a larger offset.
1570
1571         * CMakeLists.txt:
1572         * JavaScriptCore.xcodeproj/project.pbxproj:
1573         * b3/B3LowerToAir.cpp:
1574         (JSC::B3::Air::LowerToAir::imm):
1575         (JSC::B3::Air::LowerToAir::lower):
1576         * b3/B3Opcode.cpp:
1577         (WTF::printInternal):
1578         * b3/B3Opcode.h:
1579         * b3/B3Procedure.cpp:
1580         (JSC::B3::Procedure::setWasmBoundsCheckGenerator):
1581         * b3/B3Procedure.h:
1582         (JSC::B3::Procedure::setWasmBoundsCheckGenerator):
1583         * b3/B3Validate.cpp:
1584         * b3/B3Value.cpp:
1585         (JSC::B3::Value::effects):
1586         (JSC::B3::Value::typeFor):
1587         * b3/B3WasmBoundsCheckValue.cpp: Added.
1588         (JSC::B3::WasmBoundsCheckValue::~WasmBoundsCheckValue):
1589         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
1590         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
1591         * b3/B3WasmBoundsCheckValue.h: Added.
1592         (JSC::B3::WasmBoundsCheckValue::accepts):
1593         (JSC::B3::WasmBoundsCheckValue::pinnedGPR):
1594         (JSC::B3::WasmBoundsCheckValue::offset):
1595         * b3/air/AirCode.h:
1596         (JSC::B3::Air::Code::setWasmBoundsCheckGenerator):
1597         (JSC::B3::Air::Code::wasmBoundsCheckGenerator):
1598         * b3/air/AirCustom.cpp:
1599         (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
1600         * b3/air/AirCustom.h:
1601         (JSC::B3::Air::WasmBoundsCheckCustom::forEachArg):
1602         (JSC::B3::Air::WasmBoundsCheckCustom::isValidFormStatic):
1603         (JSC::B3::Air::WasmBoundsCheckCustom::admitsStack):
1604         (JSC::B3::Air::WasmBoundsCheckCustom::isTerminal):
1605         (JSC::B3::Air::WasmBoundsCheckCustom::hasNonArgNonControlEffects):
1606         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
1607         * b3/air/AirOpcode.opcodes:
1608         * b3/testb3.cpp:
1609         (JSC::B3::testWasmBoundsCheck):
1610         (JSC::B3::run):
1611
1612 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
1613
1614         The blackening of CellState is a bad way of tracking if the object is being marked for the first time
1615         https://bugs.webkit.org/show_bug.cgi?id=163343
1616
1617         Reviewed by Mark Lam.
1618
1619         When I first added the concept of NewGrey/OldGrey, I had the SlotVisitor store the old cell
1620         state in itself, so that it could use it to decide what to do for reportExtraMemoryVisited().
1621
1622         Then I changed it in a recent commit, because I wanted the freedom to have SlotVisitor visit
1623         multiple objects in tandem. But I never ended up using this capability. Still, I liked the
1624         new way better: instead of the SlotVisitor rembemering the state-before-blackening, we would
1625         make the object's state reflect whether it was black for the first time or not. That seemed
1626         convenient.
1627
1628         Unfortunately it's wrong. After we blacken the object, a concurrent barrier could instantly
1629         grey it. Then we would forget that we are visiting this object for the first time.
1630         Subsequent visits will think that they are not the first. So, we will fail to do the right
1631         thing in reportExtraMemoryVisited().
1632
1633         So, this reverts that change. This is a little more than just a revert, though. I've changed
1634         the terminology a bit. For example, I got tired of reading Black and having to remind myself
1635         that it really means that the object has begun being visited, instead of the more strict
1636         meaning that implies that it has already been visited. We want to say that it's Black or
1637         currently being scanned. I'm going to adopt Siebert's term for this: Anthracite [1]. So, our
1638         black CellState is now called AnthraciteOrBlack.
1639
1640         [1] https://pdfs.semanticscholar.org/7ae4/633265aead1f8835cf7966e179d02c2c8a4b.pdf
1641
1642         * heap/CellState.h:
1643         (JSC::isBlack): Deleted.
1644         (JSC::blacken): Deleted.
1645         * heap/Heap.cpp:
1646         (JSC::Heap::addToRememberedSet):
1647         (JSC::Heap::writeBarrierSlowPath):
1648         * heap/Heap.h:
1649         * heap/HeapInlines.h:
1650         (JSC::Heap::reportExtraMemoryVisited):
1651         (JSC::Heap::reportExternalMemoryVisited):
1652         * heap/SlotVisitor.cpp:
1653         (JSC::SlotVisitor::appendToMarkStack):
1654         (JSC::SlotVisitor::visitChildren):
1655         * heap/SlotVisitor.h:
1656         * heap/SlotVisitorInlines.h:
1657         (JSC::SlotVisitor::reportExtraMemoryVisited):
1658         (JSC::SlotVisitor::reportExternalMemoryVisited):
1659         * llint/LLIntData.cpp:
1660         (JSC::LLInt::Data::performAssertions):
1661         * llint/LowLevelInterpreter.asm:
1662
1663 2016-10-12  Mark Lam  <mark.lam@apple.com>
1664
1665         Rename variables in arrayProtoFuncSplice() to match names in the spec.
1666         https://bugs.webkit.org/show_bug.cgi?id=163354
1667
1668         Reviewed by Saam Barati.
1669
1670         This will make it easier to see whether the code matches the spec or not.
1671         Ref: https://tc39.github.io/ecma262/#sec-array.prototype.splice
1672
1673         * runtime/ArrayPrototype.cpp:
1674         (JSC::arrayProtoFuncSplice):
1675
1676 2016-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1677
1678         [DOMJIT][JSC] Explore the way to embed nodeType into JSC::JSType in WebCore
1679         https://bugs.webkit.org/show_bug.cgi?id=163245
1680
1681         Reviewed by Filip Pizlo.
1682
1683         We reserve the highest bit of JSC::JSType for extensions outside JSC.
1684         JSC does not use JSType bits so many: only 52 types are defined.
1685
1686         And we extend CallDOM patchpoint to claim that it does not require a global object.
1687         This global object is used to generate a DOM wrapper. However, nodeType does not require
1688         it since it just returns integer. In the future, we will extend CallDOM to claim
1689         its result type. And we can decide this `requireGlobalObject` condition automatically
1690         according to the result type.
1691
1692         * JavaScriptCore.xcodeproj/project.pbxproj:
1693         * dfg/DFGByteCodeParser.cpp:
1694         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
1695         * dfg/DFGFixupPhase.cpp:
1696         (JSC::DFG::FixupPhase::fixupNode):
1697         * dfg/DFGGraph.h:
1698         * dfg/DFGNode.h:
1699         (JSC::DFG::Node::hasCheckDOMPatchpoint):
1700         (JSC::DFG::Node::checkDOMPatchpoint):
1701         (JSC::DFG::Node::hasCallDOMPatchpoint):
1702         (JSC::DFG::Node::callDOMPatchpoint):
1703         (JSC::DFG::Node::hasDOMJIT): Deleted.
1704         (JSC::DFG::Node::domJIT): Deleted.
1705         * dfg/DFGSpeculativeJIT.cpp:
1706         (JSC::DFG::SpeculativeJIT::compileCallDOM):
1707         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
1708         * domjit/DOMJITCallDOMPatchpoint.h: Copied from Source/JavaScriptCore/domjit/DOMJITGetterSetter.h.
1709         (JSC::DOMJIT::CallDOMPatchpoint::create):
1710         * domjit/DOMJITGetterSetter.h:
1711         * domjit/DOMJITPatchpoint.h:
1712         * ftl/FTLLowerDFGToB3.cpp:
1713         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
1714         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
1715         * jsc.cpp:
1716         * llint/LLIntData.cpp:
1717         (JSC::LLInt::Data::performAssertions):
1718         * llint/LowLevelInterpreter.asm:
1719         * runtime/JSType.h:
1720
1721 2016-10-12  Keith Miller  <keith_miller@apple.com>
1722
1723         Handle non-function, non-undefined comparator in Array.prototype.sort
1724         https://bugs.webkit.org/show_bug.cgi?id=163085
1725
1726         Reviewed by Yusuke Suzuki.
1727
1728         * builtins/ArrayPrototype.js:
1729         (sort.comparatorSort):
1730         (sort.stringSort):
1731         (sort):
1732
1733 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
1734
1735         REGRESSION (r207179): ASSERTION FAILED: node.cell != previousCell
1736         https://bugs.webkit.org/show_bug.cgi?id=163337
1737
1738         Reviewed by Mark Lam.
1739
1740         It turns out that HeapSnapshot was not down with revisiting. The concurrent GC is going to be
1741         built around the idea that we can revisit objects many times. This means that any action that
1742         should only take place once per object must check the object's state. This fixes the snapshot
1743         code to do this.
1744
1745         While writing this code, I realized that we're actually doing this check incorrectly, so I
1746         filed bug 163343. That bug requires a race, so we aren't going to see it yet.
1747
1748         * heap/HeapSnapshot.cpp:
1749         (JSC::HeapSnapshot::finalize):
1750         * heap/SlotVisitor.cpp:
1751         (JSC::SlotVisitor::appendToMarkStack):
1752         (JSC::SlotVisitor::visitChildren):
1753
1754 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
1755
1756         Web Inspector: Improve support for logging Proxy objects in console
1757         https://bugs.webkit.org/show_bug.cgi?id=163323
1758         <rdar://problem/28432553>
1759
1760         Reviewed by Timothy Hatcher.
1761
1762         This is based off of similiar patches in Blink for Proxy handling.
1763
1764         * bindings/ScriptValue.cpp:
1765         (Deprecated::ScriptValue::isEqual):
1766         Use strict equality. This is the intent, and it prevents the possibility of triggering
1767         primitive conversion on objects in previous ConsoleMessage argument lists.
1768
1769         * inspector/InjectedScriptSource.js:
1770         (InjectedScript.prototype._propertyDescriptors):
1771         Bail if the object is a Proxy.
1772
1773         (InjectedScript.prototype._describe):
1774         Provide a friendlier name, "Proxy" instead of "ProxyObject".
1775
1776         (InjectedScript.RemoteObject):
1777         When generating a preview for a Proxy object, generate it from the final target
1778         and mark it as lossy so that the object can always be expanded to get the internal
1779         target/handler properties.
1780
1781         * inspector/JSInjectedScriptHost.h:
1782         * inspector/JSInjectedScriptHost.cpp:
1783         (Inspector::JSInjectedScriptHost::subtype):
1784         New subtype for Proxy objects.
1785
1786         (Inspector::JSInjectedScriptHost::proxyTargetValue):
1787         Resolve the final target value for a Proxy.
1788
1789         * inspector/JSInjectedScriptHostPrototype.cpp:
1790         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1791         (Inspector::jsInjectedScriptHostPrototypeFunctionProxyTargetValue):
1792         Add the new method.
1793
1794         * inspector/ScriptArguments.cpp:
1795         (Inspector::ScriptArguments::getFirstArgumentAsString):
1796         Avoid triggering Proxy traps on a Proxy object when getting a quick
1797         string description for ConsoleMessages.
1798
1799         * inspector/protocol/Runtime.json:
1800         Add new "proxy" subtype.
1801
1802 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
1803
1804         Emit DebugHooks uniformly with pause locations instead of having separate pause locations and op_debug emits
1805         https://bugs.webkit.org/show_bug.cgi?id=162809
1806
1807         Reviewed by Geoffrey Garen.
1808
1809         Change how BytecodeGeneration emits debug hooks to be more consistent.
1810         Previously most nodes individually generated their own debug hook
1811         and we asserted that it matched a breakpoint location identified
1812         by the parser. This could get out of sync, or nodes could forget to
1813         emit debug hooks expected by the parser.
1814
1815         With this change, we always check and emit a debug hook for any
1816         node. The default behavior is for BytecodeGenerator::emitNode
1817         to emit the debug hook when emitting the node itself. This covers
1818         the majority of cases (statements).
1819
1820         There are a few exceptions where we continue to need to customize
1821         emitting debug hooks:
1822
1823             1. Nodes with emitBytecodeInConditionContext
1824                 - non-Expression nodes customize how they emit their children
1825                 - constants conditions may emit nothing, but we had recorded a breakpoint location so emit a debug hook
1826                 - always emit one debug hook in case we recorded a breakpoint location, but avoid emitting multiple
1827                   in nodes which may call up to the ExpressionNode::emitBytecodeInConditionContext base impl.
1828             2. Specialized Debug Hooks
1829                 - such as hooks for Program start/end, debugger statements, etc.
1830             3. Debug Hooks in for..of / for..in that don't correspond to re-emitting nodes
1831                 - such as pausing on the assignment expression inside these loops
1832
1833         The majority of nodes no longer have custom emits.
1834
1835         * bytecompiler/BytecodeGenerator.h:
1836         (JSC::BytecodeGenerator::emitNodeInTailPosition):
1837         (JSC::BytecodeGenerator::emitNodeInConditionContext):
1838         * bytecompiler/BytecodeGenerator.cpp:
1839         (JSC::BytecodeGenerator::emitDebugHook):
1840         (JSC::BytecodeGenerator::emitEnumeration):
1841         By default, when emitting a node check if we should also emit an op_debug for it.
1842         This default DebugHook is WillExecuteStatement, which is a normal pause point.
1843
1844         * bytecompiler/NodesCodegen.cpp:
1845         (JSC::ConstantNode::emitBytecodeInConditionContext):
1846         (JSC::LogicalNotNode::emitBytecodeInConditionContext):
1847         (JSC::BinaryOpNode::emitBytecodeInConditionContext):
1848         (JSC::LogicalOpNode::emitBytecodeInConditionContext):
1849         The parser would have generated a pause location for these conditions
1850         no matter what constant folding and re-writing these nodes may perform.
1851         So, when emitting these nodes in condition context check if they need
1852         emit their own debug hook.
1853
1854         (JSC::EmptyStatementNode::emitBytecode):
1855         (JSC::ExprStatementNode::emitBytecode):
1856         (JSC::DeclarationStatement::emitBytecode):
1857         (JSC::IfElseNode::emitBytecode):
1858         (JSC::DoWhileNode::emitBytecode):
1859         (JSC::WhileNode::emitBytecode):
1860         (JSC::ForNode::emitBytecode):
1861         (JSC::ContinueNode::emitBytecode):
1862         (JSC::BreakNode::emitBytecode):
1863         (JSC::ReturnNode::emitBytecode):
1864         (JSC::WithNode::emitBytecode):
1865         (JSC::SwitchNode::emitBytecode):
1866         (JSC::ThrowNode::emitBytecode):
1867         No longer need to custom emit debug hooks. The default emitNode will handle these.
1868
1869         (JSC::ForInNode::emitBytecode):
1870         Include extra debug hooks the user expects to return back to the assignment
1871         expression in the loop header before starting the body again. The same is done
1872         for for..of with emitEnumeration.
1873
1874         * parser/ASTBuilder.h:
1875         (JSC::ASTBuilder::createExportDefaultDeclaration):
1876         (JSC::ASTBuilder::createExportLocalDeclaration):
1877         These are no longer needed to fake-satisfy assertions. We never wanted to
1878         emit debug hooks for these inner statements because the export statement
1879         will already have the debug hooks.
1880
1881         (JSC::ASTBuilder::createForInLoop):
1882         (JSC::ASTBuilder::createForOfLoop):
1883         Include the correct location where the declaration starts.
1884
1885         (JSC::ASTBuilder::breakpointLocation):
1886         Simplify to a general implementation for Node.
1887
1888         * parser/SyntaxChecker.h:
1889         (JSC::SyntaxChecker::createForInLoop):
1890         (JSC::SyntaxChecker::createForOfLoop):
1891         Ignore the new extra parameter.
1892
1893         * parser/Nodes.h:
1894         (JSC::Node::needsDebugHook):
1895         (JSC::Node::setNeedsDebugHook):
1896         (JSC::ExpressionNode::needsDebugHook): Deleted.
1897         (JSC::ExpressionNode::setNeedsDebugHook): Deleted.
1898         (JSC::StatementNode::isEmptyStatement): Deleted.
1899         (JSC::StatementNode::needsDebugHook): Deleted.
1900         (JSC::StatementNode::setNeedsDebugHook): Deleted.
1901         Move debug hook logic into the base Node class.
1902
1903         (JSC::StatementNode::isDebuggerStatement):
1904         Provide a way to distinguish a debugger statement.
1905
1906         * parser/Parser.cpp:
1907         (JSC::Parser<LexerType>::parseForStatement):
1908         Provide the location before the declaration starts.
1909
1910 2016-10-12  Mark Lam  <mark.lam@apple.com>
1911
1912         Array.prototype.slice should not modify frozen objects.
1913         https://bugs.webkit.org/show_bug.cgi?id=163338
1914
1915         Reviewed by Filip Pizlo.
1916
1917         1. The ES6 spec for Array.prototype.slice
1918            (https://tc39.github.io/ecma262/#sec-array.prototype.slice) states that it uses
1919            the CreateDataPropertyOrThrow()
1920            (https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow) to add items to
1921            the result array.  The spec for CreateDataPropertyOrThrow states:
1922
1923            "This abstract operation creates a property whose attributes are set to the
1924            same defaults used for properties created by the ECMAScript language assignment
1925            operator. Normally, the property will not already exist. If it does exist and
1926            is not configurable or if O is not extensible, [[DefineOwnProperty]] will
1927            return false causing this operation to throw a TypeError exception."
1928
1929         2. Array.prototype.slice also uses a Set function
1930            (https://tc39.github.io/ecma262/#sec-set-o-p-v-throw) to set the "length"
1931            property and passes true for the Throw argument.  Ultimately, it ends up
1932            calling the OrdinarySet function
1933            (https://tc39.github.io/ecma262/#sec-ordinaryset) that will fail if the
1934            property is not writable.  This failure should result in a TypeError being
1935            thrown in Set.
1936
1937            Since the properties of frozen objects are not extensible, not configurable,
1938            and not writeable, Array.prototype.slice should fail to write to the result
1939            array if it is frozen.
1940
1941         If the source array being sliced has 1 or more elements, (1) will take effect
1942         when we try to set the element in the non-writeable result obj.
1943         If the source array being sliced has 0 elements, we will not set any elements and
1944         (1) will not trigger.  Subsequently, (2) will take effect when we will try to
1945         set the length of the result obj.
1946
1947         * runtime/ArrayPrototype.cpp:
1948         (JSC::putLength):
1949         (JSC::setLength):
1950         (JSC::arrayProtoFuncSlice):
1951         (JSC::arrayProtoFuncSplice):
1952
1953 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
1954
1955         Remove JITWriteBarrier.h
1956         https://bugs.webkit.org/show_bug.cgi?id=163334
1957
1958         Reviewed by Mark Lam.
1959
1960         I guess that the idea of JITWriteBarrier was to make sure that if you slap some heap pointer
1961         bits into machine code, then you better execute a barrier on the code block. But it's a
1962         complicated piece of code, and I can never remember how it quite works. These days it looks
1963         vestigial, particularly since only the CallLinkInfo patchable callee immediate uses it. It's
1964         not really necessary to have something like this, since our convention is that any pointer
1965         stored in machine code must always be shadowed in the GC heap. I think that convention has
1966         won by overwhelming majority, so we should finally remove JITWriteBarrier.
1967
1968         A practical outcome of this change is that it makes it easier to implement DirectCall ICs,
1969         which will have to store the callee in the CallLinkInfo but not in the machine code.
1970
1971         * JavaScriptCore.xcodeproj/project.pbxproj:
1972         * assembler/AbstractMacroAssembler.h:
1973         * bytecode/CallLinkInfo.cpp:
1974         (JSC::CallLinkInfo::setCallee):
1975         (JSC::CallLinkInfo::clearCallee):
1976         * bytecode/CallLinkInfo.h:
1977         (JSC::CallLinkInfo::setCallee): Deleted.
1978         (JSC::CallLinkInfo::clearCallee): Deleted.
1979         * heap/SlotVisitor.h:
1980         * jit/JITWriteBarrier.h: Removed.
1981
1982 2016-10-12  Csaba Osztrogonác  <ossy@webkit.org>
1983
1984         Unreviewed buildfix for GCC 4.9 after r207186.
1985         https://bugs.webkit.org/show_bug.cgi?id=163255
1986
1987         * runtime/HasOwnPropertyCache.h:
1988         (JSC::HasOwnPropertyCache::Entry::Entry):
1989
1990 2016-10-11  Saam Barati  <sbarati@apple.com>
1991
1992         HasOwnPropertyCache needs to ref the UniquedStringImpls it sees
1993         https://bugs.webkit.org/show_bug.cgi?id=163255
1994
1995         Reviewed by Geoffrey Garen.
1996
1997         The cache needs to be responsible for ensuring that things
1998         in the cache stay alive. Before, it wasn't doing this, and
1999         that was wrong.
2000
2001         * runtime/HasOwnPropertyCache.h:
2002         (JSC::HasOwnPropertyCache::Entry::operator=):
2003         (JSC::HasOwnPropertyCache::operator delete):
2004         (JSC::HasOwnPropertyCache::create):
2005         (JSC::HasOwnPropertyCache::get):
2006         (JSC::HasOwnPropertyCache::tryAdd):
2007         (JSC::HasOwnPropertyCache::clear):
2008         (JSC::HasOwnPropertyCache::zeroBuffer):
2009
2010 2016-10-06  Filip Pizlo  <fpizlo@apple.com>
2011
2012         MarkedBlock should know what objects are live during marking
2013         https://bugs.webkit.org/show_bug.cgi?id=162309
2014
2015         Reviewed by Geoffrey Garen.
2016
2017         It used to be that we would forget which objects are live the moment we started collection.
2018         That's because the flip at the beginning clears all mark bits.
2019
2020         But we already have a facility for tracking objects that are live-but-not-marked. It's called
2021         newlyAllocated. So, instead of clearing mark bits, we want to just transfer them to
2022         newlyAllocated. Then we want to clear all newlyAllocated after GC.
2023
2024         This implements such an approach, along with a versioning optimization for newlyAllocated.
2025         Instead of walking the whole heap to clear newlyAllocated bits at the end of the GC, we bump
2026         the newlyAllocatedVersion, which causes MarkedBlock to treat newlyAllocated as if it was
2027         clear.
2028
2029         We could have even avoided allocating newlyAllocated in most cases, since empirically most
2030         blocks are either completely empty or completely full. An earlier version of this patch did
2031         this, but it was not better than this patch. In fact, it seemed to actually be worse for PLT
2032         and membuster.
2033
2034         To validate this change, we now run the conservative scan after the beginMarking flip. And it
2035         totally works!
2036
2037         This is a huge step towards concurrent GC. It means that we ought to be able to run the
2038         allocator while marking. Since we already separately made it possible to run the barrier
2039         while marking, this means that we're pretty much ready for some serious concurrency action.
2040
2041         This appears to be perf-neutral and space-neutral.
2042
2043         * JavaScriptCore.xcodeproj/project.pbxproj:
2044         * bytecode/CodeBlock.cpp:
2045         * bytecode/CodeBlock.h:
2046         (JSC::CodeBlockSet::mark): Deleted.
2047         * heap/CodeBlockSet.cpp:
2048         (JSC::CodeBlockSet::writeBarrierCurrentlyExecuting):
2049         (JSC::CodeBlockSet::clearCurrentlyExecuting):
2050         (JSC::CodeBlockSet::writeBarrierCurrentlyExecutingCodeBlocks): Deleted.
2051         * heap/CodeBlockSet.h:
2052         * heap/CodeBlockSetInlines.h: Added.
2053         (JSC::CodeBlockSet::mark):
2054         * heap/ConservativeRoots.cpp:
2055         * heap/Heap.cpp:
2056         (JSC::Heap::markRoots):
2057         (JSC::Heap::beginMarking):
2058         (JSC::Heap::collectImpl):
2059         (JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
2060         (JSC::Heap::clearCurrentlyExecutingCodeBlocks):
2061         * heap/Heap.h:
2062         * heap/HeapUtil.h:
2063         (JSC::HeapUtil::findGCObjectPointersForMarking):
2064         * heap/MarkedAllocator.cpp:
2065         (JSC::MarkedAllocator::isPagedOut):
2066         * heap/MarkedBlock.cpp:
2067         (JSC::MarkedBlock::Handle::Handle):
2068         (JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated):
2069         (JSC::MarkedBlock::Handle::stopAllocating):
2070         (JSC::MarkedBlock::Handle::lastChanceToFinalize):
2071         (JSC::MarkedBlock::Handle::resumeAllocating):
2072         (JSC::MarkedBlock::aboutToMarkSlow):
2073         (JSC::MarkedBlock::Handle::resetAllocated):
2074         (JSC::MarkedBlock::resetMarks):
2075         (JSC::MarkedBlock::setNeedsDestruction):
2076         (JSC::MarkedBlock::Handle::didAddToAllocator):
2077         (JSC::MarkedBlock::Handle::isLive):
2078         (JSC::MarkedBlock::Handle::isLiveCell):
2079         (JSC::MarkedBlock::clearMarks): Deleted.
2080         * heap/MarkedBlock.h:
2081         (JSC::MarkedBlock::Handle::newlyAllocatedVersion):
2082         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated): Deleted.
2083         (JSC::MarkedBlock::Handle::clearNewlyAllocated): Deleted.
2084         * heap/MarkedBlockInlines.h:
2085         (JSC::MarkedBlock::Handle::cellsPerBlock):
2086         (JSC::MarkedBlock::Handle::isLive):
2087         (JSC::MarkedBlock::Handle::isLiveCell):
2088         (JSC::MarkedBlock::Handle::isNewlyAllocatedStale):
2089         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocatedWithSweep):
2090         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
2091         (JSC::MarkedBlock::heap):
2092         (JSC::MarkedBlock::space):
2093         (JSC::MarkedBlock::Handle::space):
2094         (JSC::MarkedBlock::resetMarkingVersion): Deleted.
2095         * heap/MarkedSpace.cpp:
2096         (JSC::MarkedSpace::beginMarking):
2097         (JSC::MarkedSpace::endMarking):
2098         (JSC::MarkedSpace::clearNewlyAllocated): Deleted.
2099         * heap/MarkedSpace.h:
2100         (JSC::MarkedSpace::nextVersion):
2101         (JSC::MarkedSpace::newlyAllocatedVersion):
2102         (JSC::MarkedSpace::markingVersion): Deleted.
2103         * runtime/SamplingProfiler.cpp:
2104
2105 2016-10-11  Mark Lam  <mark.lam@apple.com>
2106
2107         Array.prototype.concat should not modify frozen objects.
2108         https://bugs.webkit.org/show_bug.cgi?id=163302
2109
2110         Reviewed by Filip Pizlo.
2111
2112         The ES6 spec for Array.prototype.concat states that it uses the
2113         CreateDataPropertyOrThrow() to add items to the result array.  The spec for
2114         CreateDataPropertyOrThrow states:
2115
2116         "This abstract operation creates a property whose attributes are set to the same
2117         defaults used for properties created by the ECMAScript language assignment
2118         operator. Normally, the property will not already exist. If it does exist and is
2119         not configurable or if O is not extensible, [[DefineOwnProperty]] will return
2120         false causing this operation to throw a TypeError exception."
2121
2122         Since the properties of frozen objects are not extensible, not configurable, and
2123         not writable, Array.prototype.concat should fail to write to the result array if
2124         it is frozen.
2125
2126         Ref: https://tc39.github.io/ecma262/#sec-array.prototype.concat,
2127         https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow, and
2128         https://tc39.github.io/ecma262/#sec-createdataproperty.
2129
2130         The fix consists of 2 parts:
2131         1. moveElement() should use the PutDirectIndexShouldThrow mode when invoking
2132            putDirectIndex(), and
2133         2. SparseArrayValueMap::putDirect() should check for the case where the property
2134            is read only.
2135
2136         (2) ensures that we don't write into a non-writable property.
2137         (1) ensures that we throw a TypeError for attempts to write to a non-writeable
2138         property.
2139
2140         * runtime/ArrayPrototype.cpp:
2141         (JSC::moveElements):
2142         * runtime/SparseArrayValueMap.cpp:
2143         (JSC::SparseArrayValueMap::putDirect):
2144
2145 2016-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2146
2147         [DOMJIT] DOMJIT::Patchpoint should have a way to receive constant folded arguments
2148         https://bugs.webkit.org/show_bug.cgi?id=163224
2149
2150         Reviewed by Filip Pizlo.
2151
2152         We use the GetGlobalObject DFG node to retrieve a global object from a DOM node.
2153         This global object is necessary to check whether the world is normal before entering
2154         the fast path of looking up the DOM wrapper cache.
2155         We can sometimes constant-fold this GetGlobalObject. For example, if we performed
2156         CheckStructure, the structure can offer the information about the possible result
2157         of GetGlobalObject. By using this constant-folded global object, we can drop some
2158         checks.
2159
2160         This patch introduces the way to tell the constant-folded values to DOMJIT::Patchpoint.
2161         We pass DOMJIT::Value instead of DOMJIT::Reg as a parameter of DOMJIT::PatchpointParams.
2162         This DOMJIT::Value is a pair of DOMJIT::Reg and JSValue. If the given parameter has a
2163         constant value, this JSValue is filled with it.
2164
2165         * JavaScriptCore.xcodeproj/project.pbxproj:
2166         * dfg/DFGDOMJITPatchpointParams.h:
2167         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
2168         * dfg/DFGSpeculativeJIT.cpp:
2169         (JSC::DFG::SpeculativeJIT::compileCallDOM):
2170         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
2171         * domjit/DOMJITPatchpointParams.h:
2172         (JSC::DOMJIT::PatchpointParams::at):
2173         (JSC::DOMJIT::PatchpointParams::operator[]):
2174         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
2175         * domjit/DOMJITValue.h: Copied from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h.
2176         (JSC::DOMJIT::Value::Value):
2177         (JSC::DOMJIT::Value::isGPR):
2178         (JSC::DOMJIT::Value::isFPR):
2179         (JSC::DOMJIT::Value::isJSValueRegs):
2180         (JSC::DOMJIT::Value::gpr):
2181         (JSC::DOMJIT::Value::fpr):
2182         (JSC::DOMJIT::Value::jsValueRegs):
2183         (JSC::DOMJIT::Value::reg):
2184         (JSC::DOMJIT::Value::value):
2185         * ftl/FTLDOMJITPatchpointParams.h:
2186         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
2187         * ftl/FTLLowerDFGToB3.cpp:
2188         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2189         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2190
2191 2016-10-10  Filip Pizlo  <fpizlo@apple.com>
2192
2193         Air should be able to replace constant materializations with adds
2194         https://bugs.webkit.org/show_bug.cgi?id=162749
2195
2196         Reviewed by Yusuke Suzuki.
2197
2198         We have a lot of defenses against emitting code that materializes huge contants. But if we do
2199         end up with such code in the backend, it's better to convert those materializations into add
2200         instructions by checking if other registers are known to contain nearby constants. That's
2201         what this patch does.
2202
2203         * b3/air/AirFixObviousSpills.cpp:
2204         * b3/testb3.cpp:
2205
2206 2016-10-11  Filip Pizlo  <fpizlo@apple.com>
2207
2208         B3->Air lowering needs the same defenses in effectiveAddr() that it has in tryAppendLea()
2209         https://bugs.webkit.org/show_bug.cgi?id=163264
2210
2211         Reviewed by Mark Lam.
2212
2213         When writing the lea patch (r207039), I was very careful about how I convert a Shl into a
2214         BaseIndex scale. But I forgot to check if the older code for creating BaseIndexes for
2215         effectiveAddr() got this right. It turns out that the older code missed the <<32 corner
2216         case.
2217
2218         It's sad that the two paths can't share all of their code, but it's somewhat inevitable due
2219         to how matching an address and matching a lea have to do very different things. Matching a
2220         lea means creating an instruction that is distinct from other instructions to do multiple
2221         math operations at once. Matching an address means making some instruction do extra work
2222         for free. Also, address matching can take advantage of the fact that the offset is already
2223         associated with the memory operation by strength reduction - lea matching can't do this; it
2224         has to figure out Add(@value, $const) on its own. This change makes the situation slightly
2225         more sane by adding a scaleForShl() helper that handles this weird case. It's based on the
2226         new Shl handling from r207039, and exposes it as an API for effectiveAddr() to use.
2227
2228         The testLoadBaseIndexShift32() used to crash. I don't think that this case affects JS
2229         content, since <<32 is such a bizarre outlier. I don't think we even have a path along
2230         which the FTL would emit a 64-bit <<32. It probably won't even affect WebAssembly since
2231         that uses 32-bit pointers, so we won't see 64-bit <<32 in effectiveAddr() there.
2232
2233         * b3/B3LowerToAir.cpp:
2234         (JSC::B3::Air::LowerToAir::scaleForShl):
2235         (JSC::B3::Air::LowerToAir::effectiveAddr):
2236         (JSC::B3::Air::LowerToAir::tryAppendLea):
2237         (JSC::B3::Air::LowerToAir::crossesInterference): Deleted.
2238         * b3/testb3.cpp:
2239         (JSC::B3::testLoadBaseIndexShift2):
2240         (JSC::B3::testLoadBaseIndexShift32):
2241         (JSC::B3::run):
2242
2243 2016-10-11  Saam Barati  <sbarati@apple.com>
2244
2245         ValueAdd should be constant folded if the operands are constant String,Primitive or Primitive,String
2246         https://bugs.webkit.org/show_bug.cgi?id=163182
2247
2248         Reviewed by Filip Pizlo.
2249
2250         This code pattern shows up in Dromaeo, so it's worth optimizing for.
2251         This might also show up in real world JS code due to inlining and other
2252         types of constant folding.
2253
2254         * dfg/DFGByteCodeParser.cpp:
2255         (JSC::DFG::ByteCodeParser::parseBlock):
2256         * dfg/DFGLazyJSValue.cpp:
2257         (JSC::DFG::LazyJSValue::getValue):
2258         * dfg/DFGStrengthReductionPhase.cpp:
2259         (JSC::DFG::StrengthReductionPhase::handleNode):
2260
2261 2016-10-10  Zan Dobersek  <zdobersek@igalia.com>
2262
2263         Add ENABLE_ENCRYPTED_MEDIA configuration option
2264         https://bugs.webkit.org/show_bug.cgi?id=163219
2265
2266         Reviewed by Darin Adler.
2267
2268         * Configurations/FeatureDefines.xcconfig:
2269         Add the ENABLE_ENCRYPTED_MEDIA configuration option. It will be used
2270         to enable or disable the new EME implementation at build-time.
2271
2272 2016-10-10  Filip Pizlo  <fpizlo@apple.com>
2273
2274         B3->Air lowering should be able to emit complex leas on x86
2275         https://bugs.webkit.org/show_bug.cgi?id=163234
2276
2277         Reviewed by Saam Barati.
2278
2279         This adds comprehensive support for emitting lea on x86.
2280
2281         When adding this, I found that it was useful to also finally add more reassociation. That
2282         reduces the amount of patterns that the instruction selector has to deal with.
2283
2284         * assembler/MacroAssembler.h:
2285         (JSC::MacroAssembler::lea32):
2286         (JSC::MacroAssembler::lea64):
2287         (JSC::MacroAssembler::lea): Deleted.
2288         * b3/B3LowerToAir.cpp:
2289         (JSC::B3::Air::LowerToAir::commitInternal):
2290         (JSC::B3::Air::LowerToAir::tryAppendLea):
2291         (JSC::B3::Air::LowerToAir::lower):
2292         (JSC::B3::Air::LowerToAir::createSelect): Deleted.
2293         * b3/B3ReduceStrength.cpp:
2294         * b3/B3Value.h:
2295         * b3/B3ValueInlines.h:
2296         (JSC::B3::Value::isRepresentableAs):
2297         (JSC::B3::Value::representableAs): Deleted.
2298         * b3/air/AirOpcode.opcodes:
2299         * b3/testb3.cpp: Lots of tests for lea and reassociation.
2300
2301 2016-10-10  Mark Lam  <mark.lam@apple.com>
2302
2303         Change ArrayPrototype.cpp's putLength() and setLength() to take a VM& so that we can use vm.propertyNames.
2304         https://bugs.webkit.org/show_bug.cgi?id=163260
2305
2306         Reviewed by Saam Barati.
2307
2308         In all cases where we call these, we already have the VM& anyway.
2309
2310         * runtime/ArrayPrototype.cpp:
2311         (JSC::putLength):
2312         (JSC::setLength):
2313         (JSC::arrayProtoFuncPop):
2314         (JSC::arrayProtoFuncPush):
2315         (JSC::arrayProtoFuncShift):
2316         (JSC::arrayProtoFuncSlice):
2317         (JSC::arrayProtoFuncSplice):
2318         (JSC::arrayProtoFuncUnShift):
2319
2320 2016-10-10  Mark Lam  <mark.lam@apple.com>
2321
2322         Rename the StrictModeReadonlyPropertyWriteError string to ReadonlyPropertyWriteError.
2323         https://bugs.webkit.org/show_bug.cgi?id=163239
2324
2325         Reviewed by Filip Pizlo.
2326
2327         This string is also used for reporting the same error in cases which have nothing
2328         to do with strict mode.
2329
2330         * bytecompiler/BytecodeGenerator.cpp:
2331         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
2332         * runtime/CommonSlowPaths.cpp:
2333         (JSC::SLOW_PATH_DECL):
2334         * runtime/GetterSetter.cpp:
2335         (JSC::callSetter):
2336         * runtime/JSArray.cpp:
2337         (JSC::JSArray::setLengthWithArrayStorage):
2338         (JSC::JSArray::pop):
2339         * runtime/JSCJSValue.cpp:
2340         (JSC::JSValue::putToPrimitive):
2341         (JSC::JSValue::putToPrimitiveByIndex):
2342         * runtime/JSFunction.cpp:
2343         (JSC::JSFunction::put):
2344         * runtime/JSModuleEnvironment.cpp:
2345         (JSC::JSModuleEnvironment::put):
2346         * runtime/JSModuleNamespaceObject.cpp:
2347         (JSC::JSModuleNamespaceObject::put):
2348         (JSC::JSModuleNamespaceObject::putByIndex):
2349         * runtime/JSObject.cpp:
2350         (JSC::ordinarySetSlow):
2351         (JSC::JSObject::putInlineSlow):
2352         (JSC::JSObject::setPrototypeWithCycleCheck):
2353         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
2354         (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
2355         * runtime/JSObject.h:
2356         * runtime/JSObjectInlines.h:
2357         (JSC::JSObject::putInline):
2358         * runtime/JSSymbolTableObject.h:
2359         (JSC::symbolTablePut):
2360         * runtime/Lookup.h:
2361         (JSC::putEntry):
2362         * runtime/RegExpObject.h:
2363         (JSC::RegExpObject::setLastIndex):
2364         * runtime/SparseArrayValueMap.cpp:
2365         (JSC::SparseArrayValueMap::putEntry):
2366         (JSC::SparseArrayEntry::put):
2367         * runtime/StringObject.cpp:
2368         (JSC::StringObject::put):
2369         (JSC::StringObject::putByIndex):
2370
2371 2016-10-10  Saam Barati  <sbarati@apple.com>
2372
2373         compileCheckStringIdent in the FTL is wrong
2374         https://bugs.webkit.org/show_bug.cgi?id=163215
2375
2376         Reviewed by Mark Lam and Filip Pizlo.
2377
2378         lowStringIdent() returns the StringImpl pointer. The compileCheckStringIdent()
2379         was treating its return value as the actual JSString. This is wrong.
2380
2381         * ftl/FTLLowerDFGToB3.cpp:
2382         (JSC::FTL::DFG::LowerDFGToB3::compileCheckStringIdent):
2383
2384 2016-10-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2385
2386         [DOMJIT] Implement Node accessors in DOMJIT
2387         https://bugs.webkit.org/show_bug.cgi?id=163005
2388
2389         Reviewed by Filip Pizlo.
2390
2391         Add some helper methods and offsetOfXXX for JSC::Weak since it is used
2392         for DOM wrapper caching.
2393
2394         And make DOMJIT::Patchpoint in FTL closer to one in DFG. We add resultConstraint
2395         to avoid the situation that the same register is allocated to child and result.
2396
2397         We also extend DOMJIT::Patchpoint to tell useTagTypeNumberRegister / useTagMaskRegister.
2398
2399         * dfg/DFGSpeculativeJIT.h:
2400         (JSC::DFG::SpeculativeJIT::callOperation):
2401         * domjit/DOMJITSlowPathCalls.h:
2402         * ftl/FTLLowerDFGToB3.cpp:
2403         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2404         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2405         * heap/WeakImpl.h:
2406         (JSC::WeakImpl::offsetOfJSValue):
2407         (JSC::WeakImpl::offsetOfWeakHandleOwner):
2408         * jit/AssemblyHelpers.h:
2409         (JSC::AssemblyHelpers::boxCell):
2410         (JSC::AssemblyHelpers::boxInt32): Deleted.
2411         * jit/JITOperations.h:
2412
2413 2016-10-09  Filip Pizlo  <fpizlo@apple.com>
2414
2415         Air should expose API for pinning registers
2416         https://bugs.webkit.org/show_bug.cgi?id=163175
2417
2418         Reviewed by Keith Miller.
2419
2420         You can now call Procedure::pinRegister(), or Code::pinRegister(), and it will make this
2421         register behave as follows:
2422
2423         - B3 and Air will emit no code that modifies the value in this register, except if that
2424           happens via a Patchpoint or stackmap constraint (i.e. the user explicitly asked for it).
2425         - B3 and Air will allow others to modify the register. For example, if the register is not
2426           callee-save, then the compiler knows that the register's value will be trashed by any
2427           C-style call.
2428         - Air will be happy to emit code that reads from this register, including coalescing tmps
2429           with it, so longer as there is no interference (i.e. no chance of the register's value
2430           changing). For example, if we went back to having pinned tag registers, we would tell B3
2431           to use them by (1) excluding them from any clobber set (easy, since they're callee save)
2432           and (2) emitting ArgumentReg to grab their value. There's a test that does this.
2433
2434         This is accomplished by taking regsInPriorityOrder() and making it a method of Code. Air
2435         already used this API when choosing registers in register allocation. Code now also vends a
2436         mutableRegs() set, which is derived from regsInPriorityOrder(), that can quickly tell you if
2437         a register can be mutated. Doing it this way means that most of this is a purely mechanical
2438         change. The calls to mutableRegs() are the places where we had to change logic:
2439
2440         - The register allocators needs to know that coalescing with a precolored pinned tmp is free.
2441         - The callee-save handler needs to know that we're not supposed to save/restore pinned
2442           registers.
2443
2444         Note that in this scheme, pinned registers are simply registers that do not appear in
2445         regsInPriorityOrder(). This means, for example, that we will now say that FP is pinned. So,
2446         this means that you can also pin registers by calling setRegsInPriorityOrder() and passing a
2447         vector that excludes some registers. More generally, this means that clients can now tweak
2448         the register allocator's register preferences, since the ordering in that list reflects the
2449         order in which the allocator will try registers.
2450
2451         * CMakeLists.txt:
2452         * JavaScriptCore.xcodeproj/project.pbxproj:
2453         * b3/B3Procedure.cpp:
2454         (JSC::B3::Procedure::pinRegister):
2455         * b3/B3Procedure.h:
2456         * b3/air/AirCode.cpp:
2457         (JSC::B3::Air::Code::Code):
2458         (JSC::B3::Air::Code::setRegsInPriorityOrder):
2459         (JSC::B3::Air::Code::pinRegister):
2460         * b3/air/AirCode.h:
2461         (JSC::B3::Air::Code::regsInPriorityOrder):
2462         (JSC::B3::Air::Code::mutableRegs):
2463         (JSC::B3::Air::Code::isPinned):
2464         (JSC::B3::Air::Code::regsInPriorityOrderImpl):
2465         (JSC::B3::Air::Code::proc): Deleted.
2466         * b3/air/AirEmitShuffle.cpp:
2467         (JSC::B3::Air::emitShuffle):
2468         * b3/air/AirEmitShuffle.h:
2469         * b3/air/AirHandleCalleeSaves.cpp:
2470         (JSC::B3::Air::handleCalleeSaves):
2471         * b3/air/AirIteratedRegisterCoalescing.cpp:
2472         * b3/air/AirLowerAfterRegAlloc.cpp:
2473         (JSC::B3::Air::lowerAfterRegAlloc):
2474         * b3/air/AirRegisterPriority.cpp: Removed.
2475         * b3/air/AirRegisterPriority.h: Removed.
2476         * b3/air/AirSpillEverything.cpp:
2477         (JSC::B3::Air::spillEverything):
2478         * b3/air/testair.cpp:
2479         (JSC::B3::Air::testShuffleBroadcastAllRegs):
2480         (JSC::B3::Air::testShuffleShiftAllRegs):
2481         (JSC::B3::Air::testShuffleRotateAllRegs):
2482         (JSC::B3::Air::testShuffleShiftMemoryAllRegs):
2483         (JSC::B3::Air::testShuffleShiftMemoryAllRegs64):
2484         (JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth):
2485         (JSC::B3::Air::testShuffleRotateMemoryAllRegs64):
2486         (JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth):
2487         * b3/testb3.cpp:
2488         (JSC::B3::testPinRegisters):
2489         (JSC::B3::run):
2490         * jit/RegisterSet.h:
2491
2492 2016-10-08  Filip Pizlo  <fpizlo@apple.com>
2493
2494         B3 should know about mutable pinned registers
2495         https://bugs.webkit.org/show_bug.cgi?id=163172
2496
2497         Reviewed by Keith Miller.
2498
2499         If we have mutable pinned registers then we need to know which operations mutate them. At
2500         first I considered making this into a heap range thing, but I think that this would be very
2501         confusing. Also, in the future, we might want to make Effects track register sets of
2502         clobbered registers (see bug 163173).
2503
2504         * b3/B3Effects.cpp:
2505         (JSC::B3::Effects::interferes):
2506         (JSC::B3::Effects::operator==):
2507         (JSC::B3::Effects::dump):
2508         * b3/B3Effects.h:
2509         (JSC::B3::Effects::forCall):
2510         (JSC::B3::Effects::mustExecute):
2511
2512 2016-10-08  Saam Barati  <sbarati@apple.com>
2513
2514         HasIndexedProperty clobberize rule is wrong for Array::ForceOSRExit
2515         https://bugs.webkit.org/show_bug.cgi?id=159942
2516         <rdar://problem/27328836>
2517
2518         Reviewed by Filip Pizlo.
2519
2520         When HasIndexedProperty has a ForceOSRExit array mode, it should
2521         report to write to side state, like the ForceOSRExit node, and the
2522         other nodes with ForceOSRExit array mode.
2523
2524         * dfg/DFGClobberize.h:
2525         (JSC::DFG::clobberize):
2526
2527 2016-10-07  Mark Lam  <mark.lam@apple.com>
2528
2529         Object.freeze() and seal() should throw if [[PreventExtensions]]() fails.
2530         https://bugs.webkit.org/show_bug.cgi?id=163160
2531
2532         Reviewed by Saam Barati.
2533
2534         See https://tc39.github.io/ecma262/#sec-object.freeze,
2535         https://tc39.github.io/ecma262/#sec-object.seal, and
2536         https://tc39.github.io/ecma262/#sec-setintegritylevel.  We need to call
2537         preventExtensions first before proceeding to freeze / seal the object.  If
2538         preventExtensions fails, we should throw a TypeError.
2539
2540         * runtime/ObjectConstructor.cpp:
2541         (JSC::setIntegrityLevel):
2542         (JSC::objectConstructorSeal):
2543         (JSC::objectConstructorFreeze):
2544
2545 2016-10-06  Yusuke Suzuki  <utatane.tea@gmail.com>
2546
2547         [DOMJIT] Support slow path call
2548         https://bugs.webkit.org/show_bug.cgi?id=162978
2549
2550         Reviewed by Saam Barati.
2551
2552         One of the most important features required in DOMJIT::Patchpoint is slow path calls.
2553         DOM operation typically returns DOMWrapper object. At that time, if wrapper cache hits, we can go
2554         to the fast path. However, if we cannot use the cache, we need to go to the slow path to call toJS function.
2555         At that time, slow path call functionality is necessary.
2556
2557         This patch expose DOMJIT::PatchpointParams::addSlowPathCall. We can request slow path call code generation
2558         through this interface. DOMJIT::PatchpointParams automatically leverages appropriate slow path call systems
2559         in each tier. In DFG, we use slow path call system. In FTL, we implement slow path call by using addLatePath
2560         to construct slow path call. But these details are completely hidden by DOMJIT::PatchpointParams. Users can
2561         just use addSlowPathCall.
2562
2563         Since DFG and FTL slow path call systems are implemented in variadic templates, directly using this means
2564         that we need to expose core part of DFG and FTL. For example, DFG::SpeculativeJIT need to be exposed in
2565         such a design. That is too bad. Instead, we use magical macro in DOMJITSlowPathCalls.h. We can list up the
2566         call signatures in DOMJIT_SLOW_PATH_CALLS. DOMJIT uses these signatures to generate an interface to request
2567         slow path calls inside DFG and FTL instead of exposing everything.
2568
2569         * CMakeLists.txt:
2570         * JavaScriptCore.xcodeproj/project.pbxproj:
2571         * dfg/DFGCommon.h:
2572         * dfg/DFGDOMJITPatchpointParams.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2573         (JSC::DFG::dispatch):
2574         * dfg/DFGDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2575         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
2576         * dfg/DFGSpeculativeJIT.cpp:
2577         (JSC::DFG::SpeculativeJIT::compileCallDOM):
2578         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
2579         * dfg/DFGSpeculativeJIT.h:
2580         (JSC::DFG::extractResult): Deleted.
2581         * domjit/DOMJITPatchpointParams.h:
2582         (JSC::DOMJIT::PatchpointParams::addSlowPathCall):
2583         * domjit/DOMJITSlowPathCalls.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2584         * ftl/FTLDOMJITPatchpointParams.cpp: Added.
2585         (JSC::FTL::dispatch):
2586         * ftl/FTLDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2587         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
2588         * ftl/FTLLowerDFGToB3.cpp:
2589         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2590         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2591         * jit/GPRInfo.h:
2592         (JSC::extractResult):
2593         * jsc.cpp:
2594
2595 2016-10-06  Saam Barati  <sbarati@apple.com>
2596
2597         HasOwnPropertyCache flattening dictionaries is causing insane memory usage with the uBlock Safari extension
2598         https://bugs.webkit.org/show_bug.cgi?id=163091
2599
2600         Reviewed by Mark Lam.
2601
2602         I'm investigating a real fix for this in:
2603         https://bugs.webkit.org/show_bug.cgi?id=163092
2604         However, it's best to get this out of trunk for now.
2605
2606         * runtime/HasOwnPropertyCache.h:
2607         (JSC::HasOwnPropertyCache::tryAdd):
2608
2609 2016-10-06  Keith Miller  <keith_miller@apple.com>
2610
2611         getInternalObjcObject should validate the JSManagedObject's value.
2612         https://bugs.webkit.org/show_bug.cgi?id=162985
2613
2614         Reviewed by Geoffrey Garen.
2615
2616         Previously, if, for instance, the JSManagedObject's weak value had been
2617         cleared we would call tryUnwrapObjcObject with a nil context and value.
2618         This triggered assertions failures as those functions expect their inputs
2619         to be valid.
2620
2621         * API/JSVirtualMachine.mm:
2622         (getInternalObjcObject):
2623
2624 2016-10-06  Brian Burg  <bburg@apple.com>
2625
2626         Web Inspector: RemoteInspector should cache client capabilities for off-main thread usage
2627         https://bugs.webkit.org/show_bug.cgi?id=163039
2628         <rdar://problem/28571460>
2629
2630         Reviewed by Timothy Hatcher.
2631
2632         The fix in r206797 was incorrect because listings are always pushed out on the XPC connection queue.
2633         Instead of delaying the listing needlessly, RemoteInspector should cache the capabilities of its
2634         client while on the main thread, then use the cached struct data on the XPC connection queue rather
2635         than directly accessing m_client. This is similar to how RemoteConnectionToTarget marshalls listing
2636         information from arbitrary queues into m_targetListingMap, which can then be read from any queue.
2637
2638         * inspector/remote/RemoteInspector.h:
2639         * inspector/remote/RemoteInspector.mm:
2640         (Inspector::RemoteInspector::updateClientCapabilities): Cache the capabilities.
2641         (Inspector::RemoteInspector::setRemoteInspectorClient):
2642         Re-cache the capabilities. Scope the lock to avoid reentrant locking.
2643
2644         (Inspector::RemoteInspector::clientCapabilitiesDidChange): Cache the capabilities.
2645         (Inspector::RemoteInspector::pushListingsNow): Use cached client capabilities.
2646         (Inspector::RemoteInspector::receivedGetListingMessage): Revert the change in r206797.
2647         (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
2648
2649 2016-10-06  Yusuke Suzuki  <utatane.tea@gmail.com>
2650
2651         [WebCore][JSC] Use new @throwTypeError and @throwRangeError intrinsics
2652         https://bugs.webkit.org/show_bug.cgi?id=163001
2653
2654         Reviewed by Keith Miller.
2655
2656         Previously, the argument of @throwXXXError intrinsics must be string literal.
2657         But it is error-prone restriction. This patch relaxes the restriction to accept
2658         arbitrary values. To keep emitted bytecode small, if the argument is string literal,
2659         we generate the same bytecode as before. If the argument is not string literal,
2660         we evaluate it and perform to_string before passing to throw_static_error.
2661
2662         * bytecompiler/BytecodeGenerator.cpp:
2663         (JSC::BytecodeGenerator::emitThrowStaticError):
2664         * bytecompiler/BytecodeGenerator.h:
2665         * bytecompiler/NodesCodegen.cpp:
2666         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
2667         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
2668         * dfg/DFGByteCodeParser.cpp:
2669         (JSC::DFG::ByteCodeParser::parseBlock):
2670
2671 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2672
2673         [JSC] Add @throwXXXError bytecode intrinsic
2674         https://bugs.webkit.org/show_bug.cgi?id=162995
2675
2676         Reviewed by Saam Barati.
2677
2678         Builtin JS code need to check arguments carefully since it is somewhat standard library for JS.
2679         So bunch of `throw new @TypeError("...")` exists while usual code does not have so many.
2680         However the above code bloats 32 instructions per site, enlarges the size of bytecodes of builtins,
2681         and prevent us from inlining. We should have a way to reduce this size.
2682
2683         Fortunately, we already have such a opcode: op_throw_static_error. In this patch,
2684         1. We extends op_throw_static_error to throw arbitrary errors. Previously, only TypeError and ReferenceError are allowed.
2685            We can embed ErrorType enum in op_throw_static_error to throw any types of errors.
2686         2. We introduce several new bytecode intrinsics, `@throwTypeError("...")`, `@throwRangeError("...")`,
2687            and `@throwOutOfMemoryError()`. And use it inside builtin JS instead of `throw new @TypeError("...")` thingy.
2688         3. DFG Node for throw_static_error is incorrectly named as "ThrowReferenceError". This patch renames it to "ThrowStaticError".
2689
2690         * builtins/ArrayConstructor.js:
2691         * builtins/ArrayIteratorPrototype.js:
2692         (next):
2693         * builtins/ArrayPrototype.js:
2694         (values):
2695         (keys):
2696         (entries):
2697         (reduce):
2698         (reduceRight):
2699         (every):
2700         (forEach):
2701         (filter):
2702         (map):
2703         (some):
2704         (fill):
2705         (find):
2706         (findIndex):
2707         (includes):
2708         (sort):
2709         (concatSlowPath):
2710         (copyWithin):
2711         * builtins/DatePrototype.js:
2712         (toLocaleString.toDateTimeOptionsAnyAll):
2713         (toLocaleString):
2714         (toLocaleDateString.toDateTimeOptionsDateDate):
2715         (toLocaleDateString):
2716         (toLocaleTimeString.toDateTimeOptionsTimeTime):
2717         (toLocaleTimeString):
2718         * builtins/FunctionPrototype.js:
2719         (bind):
2720         * builtins/GeneratorPrototype.js:
2721         (globalPrivate.generatorResume):
2722         * builtins/GlobalOperations.js:
2723         (globalPrivate.speciesConstructor):
2724         * builtins/MapPrototype.js:
2725         (forEach):
2726         * builtins/ModuleLoaderPrototype.js:
2727         (provide):
2728         * builtins/ObjectConstructor.js:
2729         (values):
2730         (entries):
2731         (assign):
2732         * builtins/PromiseConstructor.js:
2733         (race):
2734         (reject):
2735         (resolve):
2736         * builtins/PromiseOperations.js:
2737         (globalPrivate.newPromiseCapability.executor):
2738         (globalPrivate.newPromiseCapability):
2739         (globalPrivate.initializePromise):
2740         * builtins/PromisePrototype.js:
2741         * builtins/ReflectObject.js:
2742         (apply):
2743         (deleteProperty):
2744         (has):
2745         * builtins/RegExpPrototype.js:
2746         (globalPrivate.regExpExec):
2747         (match):
2748         (replace):
2749         (search):
2750         (split):
2751         (intrinsic.RegExpTestIntrinsic.test):
2752         * builtins/SetPrototype.js:
2753         (forEach):
2754         * builtins/StringConstructor.js:
2755         (raw):
2756         * builtins/StringIteratorPrototype.js:
2757         (next):
2758         * builtins/StringPrototype.js:
2759         (match):
2760         (globalPrivate.repeatSlowPath):
2761         (repeat):
2762         (padStart):
2763         (padEnd):
2764         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
2765         (localeCompare):
2766         (search):
2767         (split):
2768         * builtins/TypedArrayConstructor.js:
2769         (of):
2770         (from):
2771         * builtins/TypedArrayPrototype.js:
2772         (globalPrivate.typedArraySpeciesConstructor):
2773         (every):
2774         (find):
2775         (findIndex):
2776         (forEach):
2777         (some):
2778         (subarray):
2779         (reduce):
2780         (reduceRight):
2781         (map):
2782         (filter):
2783         * bytecode/BytecodeIntrinsicRegistry.h:
2784         * bytecode/CodeBlock.cpp:
2785         (JSC::CodeBlock::dumpBytecode):
2786         * bytecompiler/BytecodeGenerator.cpp:
2787         (JSC::BytecodeGenerator::emitThrowStaticError):
2788         (JSC::BytecodeGenerator::emitThrowReferenceError):
2789         (JSC::BytecodeGenerator::emitThrowTypeError):
2790         (JSC::BytecodeGenerator::emitThrowRangeError):
2791         (JSC::BytecodeGenerator::emitThrowOutOfMemoryError):
2792         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
2793         * bytecompiler/BytecodeGenerator.h:
2794         * bytecompiler/NodesCodegen.cpp:
2795         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
2796         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
2797         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwOutOfMemoryError):
2798         * dfg/DFGAbstractInterpreterInlines.h:
2799         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2800         * dfg/DFGByteCodeParser.cpp:
2801         (JSC::DFG::ByteCodeParser::parseBlock):
2802         * dfg/DFGClobberize.h:
2803         (JSC::DFG::clobberize):
2804         * dfg/DFGDoesGC.cpp:
2805         (JSC::DFG::doesGC):
2806         * dfg/DFGFixupPhase.cpp:
2807         (JSC::DFG::FixupPhase::fixupNode):
2808         * dfg/DFGNodeType.h:
2809         * dfg/DFGPredictionPropagationPhase.cpp:
2810         * dfg/DFGSafeToExecute.h:
2811         (JSC::DFG::safeToExecute):
2812         * dfg/DFGSpeculativeJIT32_64.cpp:
2813         (JSC::DFG::SpeculativeJIT::compile):
2814         * dfg/DFGSpeculativeJIT64.cpp:
2815         (JSC::DFG::SpeculativeJIT::compile):
2816         * ftl/FTLCapabilities.cpp:
2817         (JSC::FTL::canCompile):
2818         * ftl/FTLLowerDFGToB3.cpp:
2819         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2820         * jit/JITOpcodes.cpp:
2821         (JSC::JIT::emit_op_throw_static_error):
2822         * jit/JITOpcodes32_64.cpp:
2823         (JSC::JIT::emit_op_throw_static_error): Deleted.
2824         * jit/JITOperations.cpp:
2825         * jit/JITOperations.h:
2826         * llint/LLIntSlowPaths.cpp:
2827         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
2828         * llint/LLIntSlowPaths.h:
2829         * llint/LowLevelInterpreter.asm:
2830         * runtime/CommonSlowPaths.cpp:
2831         (JSC::SLOW_PATH_DECL):
2832         * runtime/CommonSlowPaths.h:
2833         * runtime/Error.cpp:
2834         (JSC::createError):
2835         (WTF::printInternal):
2836         * runtime/Error.h:
2837
2838 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2839
2840         Unreviewed, attempt to fix CLoop build after r206846
2841         https://bugs.webkit.org/show_bug.cgi?id=162941
2842
2843         Attempt to fix CLoop build part 2. r206847 was not valid.
2844
2845         * jsc.cpp:
2846
2847 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2848
2849         Unreviewed, build fix after r206846
2850         https://bugs.webkit.org/show_bug.cgi?id=162941
2851
2852         DOMJIT::Patchpoint part should be guarded by ENABLE(JIT).
2853
2854         * jsc.cpp:
2855
2856 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2857
2858         [DOMJIT] Add initial CheckDOM and CallDOM implementations
2859         https://bugs.webkit.org/show_bug.cgi?id=162941
2860
2861         Reviewed by Filip Pizlo.
2862
2863         This patch implements a prototype of DOMJIT accelerated getter.
2864         We add two new DFG nodes, CheckDOM and CallDOM.
2865
2866         CheckDOM is used to filter inappropriate |this| object for DOM getter. Its functionality
2867         is equivalent to jsDynamicCast's Check. You can use like "CheckDOM, @1, JSNode::info()",
2868         and this CheckDOM incurs a BadType exit if the class of the given @1 is not a subclass of
2869         JSNode::info().
2870
2871         CallDOM is used to emit actual DOM operations. It takes GlobalObject and checked DOM
2872         object. And it returns JSValue as its result.
2873
2874         Both CheckDOM and CallDOM can take a DOMJIT::Patchpoint. This is somewhat code snippet
2875         generator, and is injectable to DFG and FTL. DFG and FTL set up registers correctly
2876         according to DOMJIT::Patchpoint's requirement and invoke this patchpoint generator to emit code.
2877         While CallDOM always requires a patchpoint, ideally CheckDOM does not require it since
2878         isSubclassOf check can be implemented in DFG / FTL side. However, some classes have a
2879         faster way to query isSubclassOf. For example, JSNode in WebCore introduces a special
2880         JSType to optimize this query. CheckDOM's patchpoint gives us a chance to emit special
2881         faster code for such a case.
2882
2883         By leveraging above nodes, we can construct DOMJIT accelerated getter. When DFG recognizes the
2884         given getter call is CustomGetter and it has DOMJIT::GetterSetter information, DFG emits the above nodes.
2885         We implemented a prototype in jsc.cpp shell as DOMJITGetter to test the functionality.
2886
2887         Notes about the future extensions.
2888
2889         1. Currently, we do not allow CallDOM to emit any function calls. This will be extended by
2890            adding `addSlowPathCall` functionality to DOMJIT::Patchpoint later. Interesting thing is that
2891            we need to create an abstraction over DFG slow path call and FTL slow path call!
2892
2893         2. CheckDOM is not handled in DFGTypeCheckHoistingPhase yet. And we have a chance to merge several CheckDOM into one.
2894            For example, given CheckDOM A and CheckDOM B to the same target. If A is subclass of B, we can merge them to CheckDOM A.
2895
2896         * JavaScriptCore.xcodeproj/project.pbxproj:
2897         * b3/B3Effects.h:
2898         (JSC::B3::Effects::forCheck):
2899         * b3/B3Value.cpp:
2900         (JSC::B3::Value::effects):
2901         * bytecode/GetByIdStatus.cpp:
2902         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2903         (JSC::GetByIdStatus::makesCalls):
2904         (JSC::GetByIdStatus::dump):
2905         * bytecode/GetByIdStatus.h:
2906         (JSC::GetByIdStatus::GetByIdStatus):
2907         (JSC::GetByIdStatus::isCustom):
2908         (JSC::GetByIdStatus::takesSlowPath):
2909         (JSC::GetByIdStatus::isSimple): Deleted.
2910         * bytecode/SpeculatedType.cpp:
2911         (JSC::speculationFromClassInfo):
2912         * dfg/DFGAbstractInterpreter.h:
2913         (JSC::DFG::AbstractInterpreter::filterClassInfo):
2914         * dfg/DFGAbstractInterpreterInlines.h:
2915         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2916         (JSC::DFG::AbstractInterpreter<AbstractStateType>::filterClassInfo):
2917         * dfg/DFGAbstractValue.cpp:
2918         (JSC::DFG::AbstractValue::filterClassInfo):
2919         * dfg/DFGAbstractValue.h:
2920         * dfg/DFGByteCodeParser.cpp:
2921         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
2922         (JSC::DFG::ByteCodeParser::handleGetById):
2923         * dfg/DFGClobberize.h:
2924         (JSC::DFG::clobberize):
2925         * dfg/DFGConstantFoldingPhase.cpp:
2926         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2927         * dfg/DFGDoesGC.cpp:
2928         (JSC::DFG::doesGC):
2929         * dfg/DFGFixupPhase.cpp:
2930         (JSC::DFG::FixupPhase::fixupNode):
2931         * dfg/DFGNode.h:
2932         (JSC::DFG::Node::hasHeapPrediction):
2933         (JSC::DFG::Node::hasDOMJIT):
2934         (JSC::DFG::Node::domJIT):
2935         (JSC::DFG::Node::hasClassInfo):
2936         (JSC::DFG::Node::classInfo):
2937         (JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper):
2938         (JSC::DFG::Node::OpInfoWrapper::operator=):
2939         * dfg/DFGNodeType.h:
2940         * dfg/DFGOpInfo.h:
2941         (JSC::DFG::OpInfo::OpInfo):
2942         * dfg/DFGPredictionPropagationPhase.cpp:
2943         * dfg/DFGSafeToExecute.h:
2944         (JSC::DFG::safeToExecute):
2945         * dfg/DFGSpeculativeJIT.cpp:
2946         (JSC::DFG::allocateTemporaryRegistersForPatchpoint):
2947         (JSC::DFG::SpeculativeJIT::compileCallDOM):
2948         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
2949         * dfg/DFGSpeculativeJIT.h:
2950         * dfg/DFGSpeculativeJIT32_64.cpp:
2951         (JSC::DFG::SpeculativeJIT::compile):
2952         * dfg/DFGSpeculativeJIT64.cpp:
2953         (JSC::DFG::SpeculativeJIT::compile):
2954         * dfg/DFGStructureAbstractValue.cpp:
2955         (JSC::DFG::StructureAbstractValue::filterClassInfoSlow):
2956         (JSC::DFG::StructureAbstractValue::isSubClassOf):
2957         * dfg/DFGStructureAbstractValue.h:
2958         (JSC::DFG::StructureAbstractValue::filterClassInfo):
2959         (JSC::DFG::StructureAbstractValue::filter): Deleted.
2960         * domjit/DOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/dfg/DFGOpInfo.h.
2961         (JSC::DOMJIT::PatchpointParams::~PatchpointParams):
2962         (JSC::DOMJIT::PatchpointParams::size):
2963         (JSC::DOMJIT::PatchpointParams::at):
2964         (JSC::DOMJIT::PatchpointParams::operator[]):
2965         (JSC::DOMJIT::PatchpointParams::gpScratch):
2966         (JSC::DOMJIT::PatchpointParams::fpScratch):
2967         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
2968         * domjit/DOMJITReg.h: Added.
2969         (JSC::DOMJIT::Reg::Reg):
2970         (JSC::DOMJIT::Reg::isGPR):
2971         (JSC::DOMJIT::Reg::isFPR):
2972         (JSC::DOMJIT::Reg::isJSValueRegs):
2973         (JSC::DOMJIT::Reg::gpr):
2974         (JSC::DOMJIT::Reg::fpr):
2975         (JSC::DOMJIT::Reg::jsValueRegs):
2976         * ftl/FTLCapabilities.cpp:
2977         (JSC::FTL::canCompile):
2978         * ftl/FTLLowerDFGToB3.cpp:
2979         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2980         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2981         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2982         (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable): Deleted.
2983         * jit/AssemblyHelpers.h:
2984         * jsc.cpp:
2985         (WTF::DOMJITNode::DOMJITNode):
2986         (WTF::DOMJITNode::createStructure):
2987         (WTF::DOMJITNode::create):
2988         (WTF::DOMJITNode::value):
2989         (WTF::DOMJITNode::offsetOfValue):
2990         (WTF::DOMJITGetter::DOMJITGetter):
2991         (WTF::DOMJITGetter::createStructure):
2992         (WTF::DOMJITGetter::create):
2993         (WTF::DOMJITGetter::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
2994         (WTF::DOMJITGetter::domJITNodeGetterSetter):
2995         (WTF::DOMJITGetter::finishCreation):
2996         (WTF::DOMJITGetter::customGetter):
2997         (GlobalObject::finishCreation):
2998         (functionCreateDOMJITNodeObject):
2999         (functionCreateDOMJITGetterObject):
3000
3001 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
3002
3003         [JSC] Do not construct Simple GetByIdStatus against self-custom-accessor case
3004         https://bugs.webkit.org/show_bug.cgi?id=162993
3005
3006         Reviewed by Filip Pizlo.
3007
3008         We accidentally created a Simple GetByIdStatus against self-custom-accessor case: the object has own custom accessor property and get_by_id hits.
3009         If we returned such a result, the GetById will be turned to GetByOffset and it looks up incorrect thing like CustomGetterSetter object.
3010         We do not hit this bug before since maybe there is no object that has own custom-accessor and this custom-accessor does not raise an error.
3011         For example, "Node.prototype" has "firstChild" custom accessor. But since "Node.prototype" itself does not have Node::info(), "Node.prototype.firstChild"
3012         access always raises an error. I guess all the custom accessors follow this pattern. This bug is uncovered when testing DOMJIT (This bug causes crash and
3013         it can occur even if we disabled DOMJIT).
3014
3015         But such a assumption is not guaranteed. In this patch, we fix this by not returning Simple GetById.
3016
3017         * bytecode/GetByIdStatus.cpp:
3018         (JSC::GetByIdStatus::computeFromLLInt):
3019         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
3020         (JSC::GetByIdStatus::computeFor):
3021
3022 2016-10-05  Saam Barati  <sbarati@apple.com>
3023
3024         PCToCodeOriginMap builder should use labelIgnoringWatchpoints() inside the DFG
3025         https://bugs.webkit.org/show_bug.cgi?id=162936
3026
3027         Reviewed by Michael Saboff.
3028
3029         label() may insert nops because of an InvalidationPoint. It does that
3030         because we don't want code that comes after an InvalidationPoint that isn't
3031         effected by the invalidation point to be overwritten if we fire the
3032         InvalidationPoint. PCToCodeOriginMap just grabs labels to build
3033         a mapping, it never emits code that actually jumps to those labels.
3034         Therefore, it should never cause us to emit nops.
3035
3036         * dfg/DFGJITCompiler.cpp:
3037         (JSC::DFG::JITCompiler::compile):
3038         (JSC::DFG::JITCompiler::compileFunction):
3039         * dfg/DFGSpeculativeJIT.cpp:
3040         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
3041         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
3042
3043 2016-10-05  Myles C. Maxfield  <mmaxfield@apple.com>
3044
3045         Put variation fonts work behind a compile-time flag
3046         https://bugs.webkit.org/show_bug.cgi?id=162949
3047
3048         Reviewed by Simon Fraser.
3049
3050         * Configurations/FeatureDefines.xcconfig:
3051
3052 2016-10-05  Andy VanWagoner  <thetalecrafter@gmail.com>
3053
3054         [INTL] Implement Intl.getCanonicalLocales
3055         https://bugs.webkit.org/show_bug.cgi?id=162768
3056
3057         Reviewed by Benjamin Poulain.
3058
3059         Implement Intl.getCanonicalLocales from ECMA 402 (3rd edition)
3060         http://ecma-international.org/ecma-402/3.0/index.html#sec-intl.getcanonicallocales
3061
3062         Reuse canonicalizeLocaleList and copy the results into a new JSArray.
3063
3064         * runtime/IntlObject.cpp:
3065         (JSC::IntlObject::finishCreation):
3066         (JSC::intlObjectFuncGetCanonicalLocales):
3067
3068 2016-10-05  Michael Saboff  <msaboff@apple.com>
3069
3070         Bad ASSERT in ClonedArguments::createByCopyingFrom()
3071         https://bugs.webkit.org/show_bug.cgi?id=162988
3072
3073         Reviewed by Keith Miller.
3074
3075         Removed bogus assert.
3076
3077         * runtime/ClonedArguments.cpp:
3078         (JSC::ClonedArguments::createByCopyingFrom):
3079
3080 2016-10-05  Zan Dobersek  <zdobersek@igalia.com>
3081
3082         Rename ENABLE_ENCRYPTED_MEDIA_V2 to ENABLE_LEGACY_ENCRYPTED_MEDIA
3083         https://bugs.webkit.org/show_bug.cgi?id=162903
3084
3085         Reviewed by Alex Christensen.
3086
3087         Rename build guards for the remaining implementation of the legacy EME API
3088         to ENABLE_LEGACY_ENCRYPTED_MEDIA. This will allow for the future implementation
3089         of the near-finished API to be guarded with the simple ENABLE_ENCRYPTED_MEDIA guards.
3090
3091         * Configurations/FeatureDefines.xcconfig:
3092
3093 2016-10-05  Csaba Osztrogonác  <ossy@webkit.org>
3094
3095         ARM EABI buildfix after r206778
3096         https://bugs.webkit.org/show_bug.cgi?id=162964
3097
3098         Unreviewed trivial fix.
3099
3100         * jit/CCallHelpers.h:
3101         (JSC::CCallHelpers::setupArgumentsWithExecState):
3102
3103 2016-10-04  Saam Barati  <sbarati@apple.com>
3104
3105         String.prototype.toLowerCase should be a DFG/FTL intrinsic
3106         https://bugs.webkit.org/show_bug.cgi?id=162887
3107
3108         Reviewed by Filip Pizlo and Yusuke Suzuki.
3109
3110         This patch makes ToLowerCase an intrinsic in the DFG/FTL. On the fast
3111         path, the intrinsic will loop over an 8-bit string ensuring it's already
3112         lower case, and simply return the string. In the slow path, it'll call
3113         into C code to make a new string.
3114
3115         This is a 7-8% speedup on ES6SampleBench/Basic.
3116
3117         * dfg/DFGAbstractInterpreterInlines.h:
3118         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3119         * dfg/DFGByteCodeParser.cpp:
3120         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3121         * dfg/DFGClobberize.h:
3122         (JSC::DFG::clobberize):
3123         * dfg/DFGDoesGC.cpp:
3124         (JSC::DFG::doesGC):
3125         * dfg/DFGFixupPhase.cpp:
3126         (JSC::DFG::FixupPhase::fixupNode):
3127         * dfg/DFGNodeType.h:
3128         * dfg/DFGOperations.cpp:
3129         * dfg/DFGOperations.h:
3130         * dfg/DFGPredictionPropagationPhase.cpp:
3131         * dfg/DFGSafeToExecute.h:
3132         (JSC::DFG::safeToExecute):
3133         * dfg/DFGSpeculativeJIT.cpp:
3134         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
3135         * dfg/DFGSpeculativeJIT.h:
3136         (JSC::DFG::SpeculativeJIT::callOperation):
3137         * dfg/DFGSpeculativeJIT32_64.cpp:
3138         (JSC::DFG::SpeculativeJIT::compile):
3139         * dfg/DFGSpeculativeJIT64.cpp:
3140         (JSC::DFG::SpeculativeJIT::compile):
3141         * ftl/FTLAbstractHeapRepository.h:
3142         * ftl/FTLCapabilities.cpp:
3143         (JSC::FTL::canCompile):
3144         * ftl/FTLLowerDFGToB3.cpp:
3145         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3146         (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
3147         * jit/JITOperations.h:
3148         * runtime/Intrinsic.h:
3149         * runtime/StringPrototype.cpp:
3150         (JSC::StringPrototype::finishCreation):
3151
3152 2016-10-04  Brian Burg  <bburg@apple.com>
3153
3154         Web Inspector: don't synchronously send a listing message if we might need to query _WKAutomationDelegate
3155         https://bugs.webkit.org/show_bug.cgi?id=162810
3156         <rdar://problem/28571460>
3157
3158         Reviewed by Timothy Hatcher.
3159
3160         We shouldn't ever access the _WKAutomationDelegate through RemoteInspector::Client methods
3161         off of the main thread, because it could cause problems. This happens when we pushListingsNow()
3162         in response to a WIRApplicationGetListingMessage XPC message. In this case, just use
3163         pushListingsSoon() since it dispatches on the correct (main) queue to gather listing information.
3164
3165         This may induce a slight update delay when first connecting to the UIProcess through RemoteInspector,
3166         but this is at most 200ms and will coalesce with other updates that happen when UIProcess gets set up.
3167
3168         There are no other code paths through RemoteInspector (for UIProcess) that could cause a call
3169         to pushListingsNow(), so this only needs to be changed in the XPC message handler.
3170
3171         * inspector/remote/RemoteInspector.mm:
3172         (Inspector::RemoteInspector::receivedGetListingMessage):
3173
3174 2016-10-04  JF Bastien  <jfbastien@apple.com>
3175
3176         WebAssembly: handle a few corner cases
3177         https://bugs.webkit.org/show_bug.cgi?id=162884
3178
3179         Reviewed by Keith Miller.
3180
3181         * wasm/JSWASMModule.cpp: missing include broke cmake build
3182         * wasm/WASMFunctionParser.h:
3183         (JSC::WASM::FunctionParser<Context>::parseBlock): check op is valid
3184         (JSC::WASM::FunctionParser<Context>::parseExpression): switch covers all cases
3185         * wasm/WASMOps.h:
3186         (JSC::WASM::isValidOpType): op is valid
3187         * wasm/WASMParser.h:
3188         (JSC::WASM::Parser::consumeString): avoid str[i] being one-past-the-end
3189         (JSC::WASM::Parser::parseUInt32): shift math around to avoid overflow
3190
3191 2016-10-04  Yusuke Suzuki  <utatane.tea@gmail.com>
3192
3193         REGRESSION (r206778): Release JSC test ChakraCore.yaml/ChakraCore/test/Error/validate_line_column.js.default failing
3194         https://bugs.webkit.org/show_bug.cgi?id=162937
3195
3196         Reviewed by Saam Barati.
3197
3198         We dropped expression info accidentally at r206777.
3199
3200         * bytecompiler/BytecodeGenerator.cpp:
3201         (JSC::BytecodeGenerator::emitCallDefineProperty):
3202         * bytecompiler/BytecodeGenerator.h:
3203         * bytecompiler/NodesCodegen.cpp:
3204         (JSC::PropertyListNode::emitPutConstantProperty):
3205         (JSC::ClassExprNode::emitBytecode):
3206
3207 2016-10-04  Yusuke Suzuki  <utatane.tea@gmail.com>
3208
3209         [DOMJIT] Introduce DOMJIT::GetterSetter to tell JIT information
3210         https://bugs.webkit.org/show_bug.cgi?id=162916
3211
3212         Reviewed by Filip Pizlo.
3213
3214         In this patch, we introduce DOMJIT::GetterSetter.
3215         This class maintains information required to emit JIT code in DFG and FTL.
3216         DOMJIT::GetterSetter has 2 virtual functions: checkDOM and callDOM.
3217         These functions can return a DOMJIT::Patchpoint that allows us to inject
3218         appropriate machine code during DFG and FTL phases. DFG and FTL will invoke
3219         these functions to get a patchpoint. And this patchpoint will be used to
3220         emit code corresponding to CheckDOM and CallDOM DFG nodes, which will be added
3221         in subsqeunt patch.
3222
3223         We propagate DOMJIT::GetterSetter through PropertySlot, AccessCase, GetByIdVariant,
3224         and GetByIdStatus along with CustomGetter to teach DFG that this custom access
3225         code has a chance to be inlined with this DOMJIT::GetterSetter information.
3226         Instead of propagating CustomGetterSetter holding DOMJIT::GetterSetter and CustomGetter,
3227         we propagate CustomGetter and DOMJIT::GetterSetter. This is because of the current
3228         CustomGetterSetter design that we reify CustomGetterSetters only when we need to reify
3229         all the properties. This design allows us to avoid frequent CustomGetterSetter allocations
3230         and structure transitions.
3231
3232         Currently, domJIT field is always nullptr since there is no DOMJITAttribute user.
3233         When we add this, we will add code handling this DOMJIT::GetterSetter in DFG::ByteCodeParser.
3234
3235         * CMakeLists.txt:
3236         * JavaScriptCore.xcodeproj/project.pbxproj:
3237         * bytecode/GetByIdStatus.cpp:
3238         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
3239         * bytecode/GetByIdVariant.cpp:
3240         (JSC::GetByIdVariant::GetByIdVariant):
3241         (JSC::GetByIdVariant::operator=):
3242         (JSC::GetByIdVariant::attemptToMerge):
3243         (JSC::GetByIdVariant::dumpInContext):
3244         * bytecode/GetByIdVariant.h:
3245         (JSC::GetByIdVariant::domJIT):
3246         (JSC::GetByIdVariant::intrinsic): Deleted.
3247         * bytecode/PolymorphicAccess.cpp:
3248         (JSC::AccessCase::get):
3249         (JSC::AccessCase::clone):
3250         * bytecode/PolymorphicAccess.h:
3251         (JSC::AccessCase::domJIT):
3252         (JSC::AccessCase::RareData::RareData):
3253         * dfg/DFGNode.h:
3254         * domjit/DOMJITGetterSetter.h: Added.
3255         (JSC::DOMJIT::GetterSetter::GetterSetter):
3256         (JSC::DOMJIT::GetterSetter::~GetterSetter):
3257         (JSC::DOMJIT::GetterSetter::getter):
3258         (JSC::DOMJIT::GetterSetter::setter):
3259         (JSC::DOMJIT::GetterSetter::thisClassInfo):
3260         * domjit/DOMJITPatchpoint.h: Added.
3261         (JSC::DOMJIT::Patchpoint::create):
3262         (JSC::DOMJIT::Patchpoint::setGenerator):
3263         (JSC::DOMJIT::Patchpoint::generator):
3264         * jit/Repatch.cpp:
3265         (JSC::tryCacheGetByID):
3266         * runtime/CustomGetterSetter.h:
3267         * runtime/JSObject.h:
3268         (JSC::JSObject::fillCustomGetterPropertySlot):
3269         * runtime/Lookup.h:
3270         (JSC::HashTableValue::domJIT):
3271         (JSC::getStaticPropertySlotFromTable):
3272         (JSC::putEntry):
3273         (JSC::reifyStaticProperty):
3274         * runtime/PropertySlot.h:
3275         (JSC::PropertySlot::domJIT):
3276         (JSC::PropertySlot::setCacheableCustom):
3277
3278 2016-09-27  Yusuke Suzuki  <utatane.tea@gmail.com>
3279
3280         [JSC] Add a new byte code op_define_property instead of calling defineProperty
3281         https://bugs.webkit.org/show_bug.cgi?id=162108
3282
3283         Reviewed by Saam Barati.
3284
3285         To construct ES6 class, we emitted bytecode that performs the following operations.
3286
3287             1. construct a new object
3288             2. put "configurable", "enumerable" etc. fields
3289             3. call "defineProperty" function
3290
3291         However, this approach has problems. Every time we define a class method, we need to create
3292         a new object to represent property descriptor. This can be removed if we can introduce
3293         a special bytecode or special function.
3294
3295         This patch introduces new bytecodes, op_define_data_property and op_define_accessor_property.
3296         Instead of taking an object, they takes several registers to avoid object allocations.
3297         We're planning to use this bytecode to implement Object.defineProperty in builtin JS next.
3298         This allows us to leverage object allocation sinking. And it also gives us a chance to use
3299         faster ::get and ::hasProperty in JS.
3300
3301         Originally, I attempted to create one bytecode, op_define_property. However, it takes too many
3302         children in DFG and uses so many registers in DFG. This leads tricky program in 32bit platforms.
3303         Furthermore, it does not fit to the number of x64 argument registers. So instead, we introduce
3304         two bytecodes.
3305
3306         And for op_define_accessor_property, we perform CellUse edge filter to getter and setter children.
3307         This edge filter makes us possible to use SpeculateCellOperand and reduce the number of used registers
3308         in comparison with JSValueOperand. To make children Cells even if we do not specify some accessors (for
3309         example, { get: func, set: null } case), we fill registers with special throwTypeErrorFunction.
3310         The attributes bitset keep information like "This property descriptor only has getter slot".
3311
3312         In these two bytecodes, we take attributes (configurable, enumerable, writable, hasGetter etc.) as
3313         register instead of embedding constant int value because we will use these bytecodes to implement
3314         Object.defineProperty next. In Object.defineProperty case, an attributes are not statically defined
3315         at bytecode compiling time.
3316
3317         Run ES6SampleBench/Air 20 times. The result shows ~2% performance improvement.
3318
3319         Baseline:
3320             firstIteration:     84.05 ms +- 4.37 ms
3321             averageWorstCase:   40.54 ms +- 2.81 ms
3322             steadyState:        3317.49 ms +- 48.25 ms
3323             summary:            223.51 ms +- 5.07 ms
3324
3325         Patched:
3326             firstIteration:     84.46 ms +- 4.22 ms
3327             averageWorstCase:   41.48 ms +- 2.33 ms
3328             steadyState:        3253.48 ms +- 29.31 ms
3329             summary:            224.40 ms +- 4.72 ms
3330
3331         * JavaScriptCore.xcodeproj/project.pbxproj:
3332         * bytecode/BytecodeList.json:
3333         * bytecode/BytecodeUseDef.h:
3334         (JSC::computeUsesForBytecodeOffset):
3335         (JSC::computeDefsForBytecodeOffset):
3336         * bytecode/CodeBlock.cpp:
3337         (JSC::CodeBlock::dumpBytecode):
3338         * bytecode/SpecialPointer.h:
3339         * bytecompiler/BytecodeGenerator.cpp:
3340         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant):
3341         (JSC::BytecodeGenerator::emitCallDefineProperty):
3342         * bytecompiler/BytecodeGenerator.h:
3343         * bytecompiler/NodesCodegen.cpp:
3344         (JSC::PropertyListNode::emitPutConstantProperty):
3345         (JSC::BitwiseNotNode::emitBytecode):
3346         (JSC::ClassExprNode::emitBytecode):
3347         (JSC::ObjectPatternNode::bindValue):
3348         * dfg/DFGAbstractInterpreterInlines.h:
3349         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3350         * dfg/DFGByteCodeParser.cpp:
3351         (JSC::DFG::ByteCodeParser::parseBlock):
3352         * dfg/DFGCapabilities.cpp:
3353         (JSC::DFG::capabilityLevel):
3354         * dfg/DFGClobberize.h:
3355         (JSC::DFG::clobberize):
3356         * dfg/DFGDoesGC.cpp:
3357         (JSC::DFG::doesGC):
3358         * dfg/DFGFixupPhase.cpp:
3359         (JSC::DFG::FixupPhase::fixupNode):
3360         * dfg/DFGNodeType.h:
3361         * dfg/DFGOperations.cpp:
3362         * dfg/DFGOperations.h:
3363         * dfg/DFGPredictionPropagationPhase.cpp:
3364         * dfg/DFGSafeToExecute.h:
3365         (JSC::DFG::safeToExecute):
3366         * dfg/DFGSpeculativeJIT.cpp:
3367         (JSC::DFG::SpeculativeJIT::compileDefineDataProperty):
3368         (JSC::DFG::SpeculativeJIT::compileDefineAccessorProperty):
3369         * dfg/DFGSpeculativeJIT.h:
3370         (JSC::DFG::SpeculativeJIT::callOperation):
3371         * dfg/DFGSpeculativeJIT32_64.cpp:
3372         (JSC::DFG::SpeculativeJIT::compile):
3373         * dfg/DFGSpeculativeJIT64.cpp:
3374         (JSC::DFG::SpeculativeJIT::compile):
3375         * ftl/FTLCapabilities.cpp:
3376         (JSC::FTL::canCompile):
3377         * ftl/FTLLowerDFGToB3.cpp:
3378         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3379         (JSC::FTL::DFG::LowerDFGToB3::compileDefineDataProperty):
3380         (JSC::FTL::DFG::LowerDFGToB3::compileDefineAccessorProperty):
3381         (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis): Deleted.
3382         * jit/CCallHelpers.cpp:
3383         (JSC::CCallHelpers::setupFourStubArgsGPR): Deleted.
3384         * jit/CCallHelpers.h:
3385         (JSC::CCallHelpers::setupFourStubArgsGPR):
3386         (JSC::CCallHelpers::setupFiveStubArgsGPR):
3387         (JSC::CCallHelpers::setupArgumentsWithExecState):
3388         (JSC::CCallHelpers::setupStubArgsGPR):
3389         (JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
3390         * jit/JIT.cpp:
3391         (JSC::JIT::privateCompileMainPass):
3392         * jit/JIT.h:
3393         * jit/JITOperations.h:
3394         * jit/JITPropertyAccess.cpp:
3395         (JSC::JIT::emit_op_define_data_property):
3396         (JSC::JIT::emit_op_define_accessor_property):
3397         * llint/LowLevelInterpreter.asm:
3398         * runtime/CommonSlowPaths.cpp:
3399         (JSC::SLOW_PATH_DECL):
3400         * runtime/CommonSlowPaths.h:
3401         * runtime/DefinePropertyAttributes.h: Added.
3402         (JSC::DefinePropertyAttributes::DefinePropertyAttributes):
3403         (JSC::DefinePropertyAttributes::rawRepresentation):
3404         (JSC::DefinePropertyAttributes::hasValue):
3405         (JSC::DefinePropertyAttributes::setValue):
3406         (JSC::DefinePropertyAttributes::hasGet):
3407         (JSC::DefinePropertyAttributes::setGet):
3408         (JSC::DefinePropertyAttributes::hasSet):
3409         (JSC::DefinePropertyAttributes::setSet):
3410         (JSC::DefinePropertyAttributes::writable):
3411         (JSC::DefinePropertyAttributes::configurable):
3412         (JSC::DefinePropertyAttributes::enumerable):
3413         (JSC::DefinePropertyAttributes::setWritable):
3414         (JSC::DefinePropertyAttributes::setConfigurable):
3415         (JSC::DefinePropertyAttributes::setEnumerable):
3416         (JSC::DefinePropertyAttributes::fillWithTriState):
3417         (JSC::DefinePropertyAttributes::extractTriState):
3418         * runtime/JSGlobalObject.cpp:
3419         (JSC::JSGlobalObject::init):
3420         (JSC::JSGlobalObject::visitChildren):
3421         * runtime/JSGlobalObject.h:
3422         (JSC::JSGlobalObject::throwTypeErrorFunction):
3423         (JSC::JSGlobalObject::definePropertyFunction): Deleted.
3424         * runtime/ObjectConstructor.cpp:
3425         (JSC::ObjectConstructor::addDefineProperty): Deleted.
3426         * runtime/ObjectConstructor.h:
3427         * runtime/PropertyDescriptor.h:
3428         (JSC::toPropertyDescriptor):
3429
3430 2016-10-04  Saam Barati  <sbarati@apple.com>
3431
3432         Follow up fix to GetMapBucket and MapHash speculating on child node types.
3433         To fix this, on 32-bit platforms, we do not speculate on the child
3434         type since we just call into C code for these nodes.
3435
3436         * dfg/DFGFixupPhase.cpp:
3437         (JSC::DFG::FixupPhase::fixupNode):
3438
3439 2016-10-03  Saam Barati  <sbarati@apple.com>
3440
3441         GetMapBucket node should speculate on the type of its 'key' child
3442         https://bugs.webkit.org/show_bug.cgi?id=161638
3443
3444         Reviewed by Filip Pizlo.
3445
3446         This eliminates type-check branches when we've already
3447         proven the type of the incoming key. Also, it reduces
3448         the branches we emit when type checking the bucket's key.
3449
3450         This is a 2-3% speedup on ES6SampleBench/Basic.
3451
3452         * dfg/DFGFixupPhase.cpp:
3453         (JSC::DFG::FixupPhase::fixupNode):
3454         * dfg/DFGSpeculativeJIT64.cpp:
3455         (JSC::DFG::SpeculativeJIT::compile):
3456         * ftl/FTLLowerDFGToB3.cpp:
3457         (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
3458
3459 2016-10-03  Christopher Reid  <Christopher.Reid@am.sony.com>
3460
3461         Offline asm should not output masm assembly when using a x86_64 asm backend
3462         https://bugs.webkit.org/show_bug.cgi?id=162705
3463
3464         When cross compiling on windows to Clang, masm was being generated simply because
3465         the os was windows. This change adds a command line parameter --assembler=MASM
3466         to set the output assembly to masm.
3467         The functions isGCC and isCompilingToWindows were removed as they are no longer called.
3468
3469         Reviewed by Mark Lam.
3470
3471         * CMakeLists.txt:
3472         * offlineasm/asm.rb:
3473         * offlineasm/x86.rb:
3474
3475 2016-10-03  JF Bastien  <jfbastien@apple.com>
3476
3477         Auto-generate WASMOps.h, share with testing JSON file
3478         https://bugs.webkit.org/show_bug.cgi?id=162870
3479
3480         Reviewed by Keith Miller.
3481
3482         Add a few new opcodes, but keep this mostly as-is for now. I want
3483         to generate smarter code but will do so in a later update to
3484         reduce disruption.
3485
3486         * wasm/WASMOps.h: auto-generated from ./JSTests/stress/wasm/to-c++.js
3487
3488 2016-10-03  Michael Saboff  <msaboff@apple.com>
3489
3490         Creating pcToOriginMap in FTL shouldn't insert unnecessary NOPs
3491         https://bugs.webkit.org/show_bug.cgi?id=162879
3492
3493         Reviewed by Filip Pizlo.
3494
3495         If there is a recent watchpoint label, using MacroAssembler::label() will pad
3496         the instruction stream with NOPs to provide space for a jump.  This changes
3497         Air::generate() to use labelIgnoringWatchpoints() to create pcToOriginMap
3498         entries to eliminate unneccesary NOPs.
3499
3500         * b3/air/AirGenerate.cpp:
3501         (JSC::B3::Air::generate):
3502         * b3/testb3.cpp:
3503         (JSC::B3::testPCOriginMapDoesntInsertNops): New test.
3504         (JSC::B3::run):
3505
3506 2016-10-03  Saam Barati  <sbarati@apple.com>
3507
3508         MapHash should speculate on the type of its child node
3509         https://bugs.webkit.org/show_bug.cgi?id=161922
3510
3511         Reviewed by Filip Pizlo.
3512
3513         This allows us to remove runtime type checks when we've already
3514         proven the type of the incoming value.
3515
3516         This is a 2-3% speedup on ES6SampleBench/Basic.
3517
3518         * dfg/DFGFixupPhase.cpp:
3519         (JSC::DFG::FixupPhase::fixupNode):
3520         * dfg/DFGSpeculativeJIT64.cpp:
3521         (JSC::DFG::SpeculativeJIT::compile):
3522         * ftl/FTLLowerDFGToB3.cpp:
3523         (JSC::FTL::DFG::LowerDFGToB3::wangsInt64Hash):
3524         (JSC::FTL::DFG::LowerDFGToB3::mapHashString):
3525         (JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
3526
3527 2016-10-03  Filip Pizlo  <fpizlo@apple.com>
3528
3529         B3 trapping memory accesses should be documented
3530         https://bugs.webkit.org/show_bug.cgi?id=162845
3531
3532         Reviewed by Geoffrey Garen.
3533
3534         While writing some documentation, I found some small holes in the code.
3535
3536         * b3/B3Effects.cpp:
3537         (JSC::B3::Effects::operator==): Need this to write tests.
3538         (JSC::B3::Effects::operator!=): Need this to write tests.
3539         * b3/B3Effects.h:
3540         * b3/B3HeapRange.h:
3541         * b3/B3MemoryValue.cpp:
3542         (JSC::B3::MemoryValue::dumpMeta): Sometimes the heap range dump won't show you the memory value's actual range. This makes the dump show you the actual range in that case.
3543         * b3/B3Value.cpp:
3544         (JSC::B3::Value::effects): While documenting this, I remembered that trapping also has to imply reading top. I fixed this.
3545         * b3/testb3.cpp:
3546         (JSC::B3::testTrappingLoad): Added checks for the effects of trapping loads.
3547         (JSC::B3::testTrappingStore): Added checks for the effects of trapping stores.
3548         (JSC::B3::testMoveConstants): Made this not crash with validation.
3549
3550 2016-10-03  Yusuke Suzuki  <utatane.tea@gmail.com>
3551
3552         [ES6] GeneratorFunction (a.k.a. GeneratorWrapperFunction)'s prototype object does not have constructor property
3553         https://bugs.webkit.org/show_bug.cgi?id=162849
3554
3555         Reviewed by Geoffrey Garen.
3556
3557         Since GeneratorFunction is not constructible, GeneratorFunction.prototype does not have "constructor" property.
3558
3559             function* generatorFunction() { }
3560             generatorFunction.prototype.constructor // undefined
3561
3562         * runtime/JSFunction.cpp:
3563         (JSC::JSFunction::getOwnPropertySlot):
3564
3565 2016-10-03  Nicolas Breidinger  <Nicolas.Breidinger@sony.com>
3566
3567         JSStringRef should define JSChar without platform checks
3568         https://bugs.webkit.org/show_bug.cgi?id=162808
3569
3570         Reviewed by Mark Lam.
3571
3572         * API/JSStringRef.h:
3573
3574 2016-10-01  Yusuke Suzuki  <utatane.tea@gmail.com>
3575
3576         [ES6] Align attributes of Generator related properties to spec
3577         https://bugs.webkit.org/show_bug.cgi?id=162839
3578
3579         Reviewed by Saam Barati.
3580
3581         This patch fixes attributes of Generator related properties.
3582         These fixes are covered by test262.
3583
3584         * runtime/GeneratorFunctionConstructor.cpp:
3585         (JSC::GeneratorFunctionConstructor::finishCreation):
3586         * runtime/GeneratorFunctionConstructor.h:
3587         * runtime/GeneratorFunctionPrototype.cpp:
3588         (JSC::GeneratorFunctionPrototype::finishCreation):
3589         * runtime/GeneratorFunctionPrototype.h:
3590         * runtime/GeneratorPrototype.h:
3591         * runtime/JSGlobalObject.cpp:
3592         (JSC::JSGlobalObject::init):
3593
3594 2016-10-01  Yusuke Suzuki  <utatane.tea@gmail.com>
3595
3596         [ES6] GeneratorFunction constructor should instantiate generator function
3597         https://bugs.webkit.org/show_bug.cgi?id=162838
3598
3599         Reviewed by Saam Barati.
3600
3601         GeneratorFunction's constructor should return an instance of JSGeneratorFunction
3602         instead of JSFunction. In this patch, we fix the following 2 things.
3603
3604         1. GeneratorFunction constructor should use JSGeneratorFunction
3605
3606             Previously, we used JSFunction to construct a result. It's wrong. We use JSGeneratorFunction.
3607
3608         2. Pass newTarget into GeneratorFunction constructor to make it subclassible
3609
3610             We did not leverage newTarget when using GeneratorFunction constructor.
3611             Using it correctly to create the subclass Structure and making GeneratorFunction subclassible.
3612
3613         Test262 test covers (1), but (2) is not covered. We add tests that covers both to stress tests.
3614
3615         * runtime/FunctionConstructor.cpp:
3616         (JSC::constructFunctionSkippingEvalEnabledCheck):
3617         * runtime/GeneratorFunctionConstructor.cpp:
3618         (JSC::constructGeneratorFunctionConstructor):
3619         * runtime/JSGeneratorFunction.cpp:
3620         (JSC::JSGeneratorFunction::JSGeneratorFunction):
3621         (JSC::JSGeneratorFunction::createImpl):
3622         (JSC::JSGeneratorFunction::create):
3623         (JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
3624         * runtime/JSGeneratorFunction.h:
3625
3626 2016-10-01  Filip Pizlo  <fpizlo@apple.com>
3627
3628         Get rid of isMarkedOrNewlyAllocated
3629         https://bugs.webkit.org/show_bug.cgi?id=162842
3630
3631         Reviewed by Dan Bernstein.
3632
3633         This function has become dead code. This change removes it.
3634
3635         * heap/CellContainer.h:
3636         * heap/CellContainerInlines.h:
3637         (JSC::CellContainer::isMarkedOrNewlyAllocated): Deleted.
3638         * heap/LargeAllocation.h:
3639         (JSC::LargeAllocation::isLive):
3640         (JSC::LargeAllocation::isMarkedOrNewlyAllocated): Deleted.
3641         * heap/MarkedBlock.cpp:
3642         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated): Deleted.
3643         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Deleted.
3644         * heap/MarkedBlock.h:
3645         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated): Deleted.
3646         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Deleted.
3647
3648 2016-10-01  Joseph Pecoraro  <pecoraro@apple.com>
3649
3650         Rename DebugHookID to DebugHookType
3651         https://bugs.webkit.org/show_bug.cgi?id=162820
3652
3653         Reviewed by Alex Christensen.
3654
3655         * bytecode/CodeBlock.cpp:
3656         (JSC::debugHookName):
3657         (JSC::CodeBlock::dumpBytecode):
3658         * bytecompiler/BytecodeGenerator.cpp:
3659         (JSC::BytecodeGenerator::emitDebugHook):
3660         * bytecompiler/BytecodeGenerator.h:
3661         * interpreter/Interpreter.cpp:
3662         (JSC::Interpreter::debug):
3663         * interpreter/Interpreter.h:
3664         * jit/JITOperations.cpp:
3665         * llint/LLIntSlowPaths.cpp:
3666         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3667
3668 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
3669
3670         Web Inspector: Stepping to a line with an autoContinue breakpoint should still pause
3671         https://bugs.webkit.org/show_bug.cgi?id=161712
3672         <rdar://problem/28193970>
3673
3674         Reviewed by Brian Burg.
3675
3676         * debugger/Debugger.cpp:
3677         (JSC::Debugger::pauseIfNeeded):
3678         If we stepped to an auto-continue breakpoint we should continue
3679         stepping, not just continue.
3680
3681 2016-09-30  Filip Pizlo  <fpizlo@apple.com>
3682
3683         B3 should support trapping memory accesses
3684         https://bugs.webkit.org/show_bug.cgi?id=162689
3685
3686         Reviewed by Geoffrey Garen.
3687
3688         This adds a traps flag to B3::Kind. It also makes B3::Kind work more like Air::Kind, in the
3689         sense that it's a bag of distinct bits - it doesn't need to be a union unless we get enough
3690         things that it would make a difference.
3691
3692         The only analysis that needs to know about traps is effects. It now knows that traps implies
3693         sideExits, which means that this turns off DCE. The only optimization that needs to know
3694         about traps is eliminateCommonSubexpressions(), which needs to pessimize its store
3695         elimination if the store traps.
3696
3697         The hard part of this change is teaching the instruction selector to faithfully carry the
3698         traps flag down to Air. I got this to work by making ArgPromise a non-copyable object that
3699         knows whether you've used it in an instruction. It knows when you call consume(). If you do
3700         this then ArgPromise cannot be destructed without first passing your inst through it. This,
3701         along with a few other hacks, means that all of the load-op and load-op-store fusions
3702         correctly carry the trap bit: if any of the B3 loads or stores involved traps then you get
3703         traps in Air.
3704
3705         This framework also sets us up to do bug 162688, since the ArgPromise::inst() hook is
3706         powerful enough to allow wrapping the instruction with a Patch.
3707
3708         I added some tests to testb3 that verify that optimizations are appropriately inhibited and
3709         that the traps flag survives until the bitter end of Air.
3710
3711         * b3/B3EliminateCommonSubexpressions.cpp:
3712         * b3/B3Kind.cpp:
3713         (JSC::B3::Kind::dump):
3714         * b3/B3Kind.h:
3715         (JSC::B3::Kind::Kind):
3716         (JSC::B3::Kind::hasExtraBits):
3717         (JSC::B3::Kind::isChill):
3718         (JSC::B3::Kind::setIsChill):
3719         (JSC::B3::Kind::hasTraps):
3720         (JSC::B3::Kind::traps):
3721         (JSC::B3::Kind::setTraps):
3722         (JSC::B3::Kind::operator==):
3723         (JSC::B3::Kind::hash):
3724         (JSC::B3::trapping):
3725         * b3/B3LowerToAir.cpp:
3726         (JSC::B3::Air::LowerToAir::ArgPromise::swap):
3727         (JSC::B3::Air::LowerToAir::ArgPromise::ArgPromise):
3728         (JSC::B3::Air::LowerToAir::ArgPromise::operator=):
3729         (JSC::B3::Air::LowerToAir::ArgPromise::~ArgPromise):
3730         (JSC::B3::Air::LowerToAir::ArgPromise::setTraps):
3731         (JSC::B3::Air::LowerToAir::ArgPromise::consume):
3732         (JSC::B3::Air::LowerToAir::ArgPromise::inst):
3733         (JSC::B3::Air::LowerToAir::trappingInst):
3734         (JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode):
3735         (JSC::B3::Air::LowerToAir::appendUnOp):
3736         (JSC::B3::Air::LowerToAir::appendBinOp):
3737         (JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
3738         (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
3739         (JSC::B3::Air::LowerToAir::appendStore):
3740         (JSC::B3::Air::LowerToAir::append):
3741         (JSC::B3::Air::LowerToAir::createGenericCompare):
3742         (JSC::B3::Air::LowerToAir::createBranch):
3743         (JSC::B3::Air::LowerToAir::createCompare):
3744         (JSC::B3::Air::LowerToAir::createSelect):
3745         (JSC::B3::Air::LowerToAir::lower):
3746         * b3/B3Validate.cpp:
3747         * b3/B3Value.cpp:
3748         (JSC::B3::Value::effects):
3749         * b3/B3Value.h:
3750         * b3/air/AirCode.h:
3751         * b3/testb3.cpp:
3752         (JSC::B3::testTrappingLoad):
3753         (JSC::B3::testTrappingStore):
3754         (JSC::B3::testTrappingLoadAddStore):
3755         (JSC::B3::testTrappingLoadDCE):
3756         (JSC::B3::testTrappingStoreElimination):
3757         (JSC::B3::run):
3758
3759 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
3760
3761         Web Inspector: Stepping over/out of a function sometimes resumes instead of taking you to caller
3762         https://bugs.webkit.org/show_bug.cgi?id=162802
3763         <rdar://problem/28569982>
3764
3765         Reviewed by Mark Lam.
3766
3767         * debugger/Debugger.cpp:
3768         (JSC::Debugger::stepOverStatement):
3769         (JSC::Debugger::stepOutOfFunction):
3770         Enable stepping mode when we start stepping.
3771
3772 2016-09-30  Filip Pizlo  <fpizlo@apple.com>
3773
3774         B3::moveConstants should be able to edit code to minimize the number of constants
3775         https://bugs.webkit.org/show_bug.cgi?id=162764
3776
3777         Reviewed by Saam Barati.
3778
3779         There are some interesting cases where we can reduce the number of constant materializations if
3780         we teach moveConstants() how to edit code. The two examples that this patch supports are:
3781
3782             - Loads and stores from a constant pointer. Since loads and stores get an offset for free
3783               and the instruction selector is really good at handling it, and since we can query Air to
3784               see what kinds of offsets are legal, we can sometimes avoid using a constant pointer that
3785               is specific to the absolute address of that load and instead pick some other constant
3786               that is within offset distance of ours.
3787
3788             - Add and Sub by a constant (x + c, x - c). Since x + c = x - -c and x - c = x + -c, we can
3789               flip Add to Sub or vice versa if the negated constant is available.
3790
3791         This change makes moveConstants() pick the most dominant constant that works for an value. In
3792         the case of memory accesses, it uses Air::Arg::isValidAddrForm() to work out what other
3793         constants would work. In the case of Add/Sub, it simply looks for the negated constant. This
3794         should result in something like a minimal number of constants since these rules always pick the
3795         most dominant constant that works - so if an Add's constant is already most dominant then
3796         nothing changes, but if the negated one is more dominant then it becomes a Sub.
3797
3798         This is a 0.5% speed-up on LongSpider and neutral elsewhere. It's a speed-up because the
3799         absolute address thing reduces the number of address materializations that we have to do, while
3800         the add/sub thing prevents us from having to materialize 0x1000000000000 to box doubles.
3801         However, this may introduce a pathology, which I've filed a bug for: bug 162796.
3802
3803         * b3/B3MoveConstants.cpp:
3804         * b3/B3MoveConstants.h:
3805         * b3/B3UseCounts.h:
3806         * b3/air/AirFixObviousSpills.cpp:
3807         * b3/testb3.cpp:
3808         (JSC::B3::testMoveConstants):
3809         (JSC::B3::run):
3810
3811 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
3812
3813         Fix modules tests after r206653 handle breakpoint locations in import/export statements
3814         https://bugs.webkit.org/show_bug.cgi?id=162807
3815
3816         Reviewed by Mark Lam.
3817
3818         * parser/ASTBuilder.h:
3819         (JSC::ASTBuilder::createExportDefaultDeclaration):
3820         (JSC::ASTBuilder::createExportLocalDeclaration):
3821         Don't record an extra breakpoint location for the statement
3822         within an export statement.
3823
3824         * parser/Parser.cpp:
3825         (JSC::Parser<LexerType>::parseModuleSourceElements):
3826         Record a pause location for import/export statements.
3827
3828 2016-09-30  Mark Lam  <mark.lam@apple.com>
3829
3830         Remove the dumping of the stack back trace in VM::verifyExceptionCheckNeedIsSatisfied().
3831         https://bugs.webkit.org/show_bug.cgi?id=162797
3832
3833         Reviewed by Geoffrey Garen.
3834
3835         This is because the RELEASE_ASSERT() that follows immediately after will also
3836         dump the stack back trace.  Hence, the first dump will be redundant.
3837
3838         Also removed an extra space in the dataLog output.
3839
3840         * runtime/VM.cpp:
3841         (JSC::VM::verifyExceptionCheckNeedIsSatisfied):
3842
3843 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
3844
3845         Web Inspector: Stepping through `a(); b(); c();` it is unclear where we are and what is about to execute
3846         https://bugs.webkit.org/show_bug.cgi?id=161658
3847         <rdar://problem/28181254>
3848
3849         Reviewed by Geoffrey Garen.
<