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