Google Git
Sign in
webkit / WebKit / 9e461e96e78d7f935aa2bf062273de991d8054e7 / . / Source / JavaScriptCore / ChangeLog
blob: e7626558f9d3ab32e99dbc9d233dcf97f40aeee5 [file] [log] [blame]
2016-03-28 Benjamin Poulain <bpoulain@apple.com>
[JSC] ArithSub should not propagate "UsesAsOther"
https://bugs.webkit.org/show_bug.cgi?id=155932
Reviewed by Mark Lam.
The node ArithSub was backpropagating UsesAsOther.
This causes any GetByVal on a Double Array to have an extra
hole check if it flows into an ArithSub.
The definition of ArithSub (12.8.4.1) has both operands go
through ToNumber(). ToNumber() on "undefined" always produces
NaN. It is safe to ignore the NaN marker from hole when
the DAG flows into ArithSub.
This patch also adds this change and test coverage to ArithAdd.
ArithAdd was not a problem in practice because it is only
generated before Fixup if both operands are known to be numerical.
The change to ArithAdd is there to protect us of the ArithSub-like
problems if we ever improve our support of arithmetic operators.
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* tests/stress/arith-add-on-double-array-with-holes.js: Added.
(let.testCase.of.testCases.eval.nonObservableHoleOnLhs):
(let.testCase.of.testCases.observableHoleOnLhs):
(let.testCase.of.testCases.nonObservableHoleOnRhs):
(let.testCase.of.testCases.observableHoleOnRhs):
* tests/stress/arith-sub-on-double-array-with-holes.js: Added.
(let.testCase.of.testCases.eval.nonObservableHoleOnLhs):
(let.testCase.of.testCases.observableHoleOnLhs):
(let.testCase.of.testCases.nonObservableHoleOnRhs):
(let.testCase.of.testCases.observableHoleOnRhs):
* tests/stress/value-add-on-double-array-with-holes.js: Added.
(let.testCase.of.testCases.eval.nonObservableHoleOnLhs):
(let.testCase.of.testCases.observableHoleOnLhs):
(let.testCase.of.testCases.nonObservableHoleOnRhs):
(let.testCase.of.testCases.observableHoleOnRhs):
2016-03-28 Brian Burg <bburg@apple.com>
Web Inspector: protocol generator should generate C++ string-to-enum helper functions
https://bugs.webkit.org/show_bug.cgi?id=155691
<rdar://problem/25258078>
Reviewed by Timothy Hatcher.
There's a lot of code throughout the Inspector agents and automation code
that needs to convert a raw string into a typed protocol enum. Generate
some helpers that do this conversion so clients can move over to using it.
These helpers are necessary for when we eventually switch to calling backend
dispatcher handlers with typed arguments instead of untyped JSON objects.
To correctly generate a conversion function for an anonymous enum, the
generator needs to be able to get the containing object type's declaration.
Since the model's Type object each have only one instance, there is a
one-to-one association between type and its declaration.
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator.generate_output):
(CppProtocolTypesHeaderGenerator._generate_forward_declarations):
Clean up this method to use methodcaller to sort types by raw name.
(_generate_declarations_for_enum_conversion_methods):
(_generate_declarations_for_enum_conversion_methods.return_type_with_export_macro):
(_generate_declarations_for_enum_conversion_methods.type_member_is_anonymous_enum_type):
Added. Generates a new section with an unfilled template and specializations of
the template for every named and anonymous enum in every domain. Guards for
domains wrap the forward declarations. This is added to the end of the header
file so that specializations for both types of enums are in the same place.
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator.generate_output):
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.type_member_is_anonymous_enum_type):
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.generate_conversion_method_body):
Added. Generate a static array of offsets into the enum constant value array.
Then, loop over this array of offsets and do string comparisons against the
provided string and enum constant values at the relevant offsets for this enum.
* inspector/scripts/codegen/generator_templates.py:
(GeneratorTemplates): Update copyright year in generated files.
* inspector/scripts/codegen/models.py:
(AliasedType.__init__):
(EnumType.__init__):
(EnumType.enum_values):
(EnumType.declaration):
(ArrayType.__init__):
(ArrayType.declaration):
(ObjectType.__init__):
(ObjectType.declaration):
(Protocol.resolve_types):
(Protocol.lookup_type_reference):
Pass the type declaration to Type constructors if available. If not,
fill in a placeholder name for the type in the constructor instead of caller.
Rebaseline all the things, mostly for copyright block changes.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-03-25 Joseph Pecoraro <pecoraro@apple.com>
Misc. JavaScriptCore built-ins cleanups
https://bugs.webkit.org/show_bug.cgi?id=155920
Reviewed by Mark Lam.
* builtins/RegExpPrototype.js:
(match):
No need for an else after an if that always returns.
* builtins/TypedArrayConstructor.js:
(of):
Fix error message to use the correct function name.
(allocateInt8Array):
(allocateInt16Array):
(allocateInt32Array):
(allocateUint32Array):
(allocateUint16Array):
(allocateUint8Array):
(allocateUint8ClampedArray):
(allocateFloat32Array):
(allocateFloat64Array):
Cleanup style to be like all the other code.
* tests/stress/typedarray-of.js:
Test the exception message.
2016-03-25 Joseph Pecoraro <pecoraro@apple.com>
Date.prototype.toLocaleDateString uses overridable Object.create
https://bugs.webkit.org/show_bug.cgi?id=155917
Reviewed by Mark Lam.
* builtins/DatePrototype.js:
(toLocaleString.toDateTimeOptionsAnyAll):
(toLocaleDateString.toDateTimeOptionsDateDate):
(toLocaleTimeString.toDateTimeOptionsTimeTime):
Switch from @Object.create to @Object.@create to guarentee we are
using the built-in create method and not user defined code.
* runtime/CommonIdentifiers.h:
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
Setup the @create private symbol.
2016-03-25 Benjamin Poulain <bpoulain@apple.com>
[JSC] Put the x86 Assembler on a binary diet
https://bugs.webkit.org/show_bug.cgi?id=155683
Reviewed by Darin Adler.
The MacroAssemblers are heavily inlined. This is unfortunately
important for baseline JIT where many branches can be eliminated
at compile time.
This inlining causes a lot of binary bloat. The phases
lowering to ASM are massively large.
This patch improves the situation a bit for x86 through
many small improvements:
-Every instruction starts with ensureSpace(). The slow
path realloc the buffer.
From that slow path, only fastRealloc() was a function
call. What is around does not need to be fast, I moved
the whole grow() function out of line for those cases.
-When testing multiple registers for REX requirements,
we had something like this:
byteRegRequiresRex(reg) || byteRegRequiresRex(rm)
regRequiresRex(index) || regRequiresRex(base)
Those were producing multiple test-and-branch. Those branches
are effectively random so we don't have to care about individual
branches being predictable.
The new code effectively does:
byteRegRequiresRex(reg | rm)
regRequiresRex(index | base)
-Change "ModRmMode" to have the value we can OR directly
to the generated ModRm.
This is important because some ModRM code is so large
that is goes out of line;
-Finally, a big change on how we write to the AssemblerBuffer.
Previously, instructions were written byte by byte into
the assembler buffer of the MacroAssembler.
The problem with that is the compiler cannot prove that
the buffer pointer and the AssemblerBuffer are not pointing
to the same memory.
Because of that, before any write, all the local register
were pushed back to the AssemblerBuffer memory, then everything
was read back after the write to compute the next write.
I attempted to use the "restrict" keyword and wrapper types
to help Clang with that but nothing worked.
The current solution is to keep a local copy of the index
and the buffer pointer in the scope of each instruction.
That is done by AssemblerBuffer::LocalWriter.
Since LocalWriter only exists locally, it stays in
register and we don't have all the memory churn between
each byte writing. This also allows clang to combine
obvious cases since there are no longer observable side
effects between bytes.
This patch reduces the binary size by 66k. It is a small
speed-up on Sunspider.
* assembler/AssemblerBuffer.h:
(JSC::AssemblerBuffer::ensureSpace):
(JSC::AssemblerBuffer::LocalWriter::LocalWriter):
(JSC::AssemblerBuffer::LocalWriter::~LocalWriter):
(JSC::AssemblerBuffer::LocalWriter::putByteUnchecked):
(JSC::AssemblerBuffer::LocalWriter::putShortUnchecked):
(JSC::AssemblerBuffer::LocalWriter::putIntUnchecked):
(JSC::AssemblerBuffer::LocalWriter::putInt64Unchecked):
(JSC::AssemblerBuffer::LocalWriter::putIntegralUnchecked):
(JSC::AssemblerBuffer::putIntegral):
(JSC::AssemblerBuffer::outOfLineGrow):
* assembler/MacroAssemblerX86Common.h:
* assembler/X86Assembler.h:
(JSC::X86Assembler::X86InstructionFormatter::byteRegRequiresRex):
(JSC::X86Assembler::X86InstructionFormatter::regRequiresRex):
(JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::LocalBufferWriter):
(JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRex):
(JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexW):
(JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexIf):
(JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexIfNeeded):
(JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::putModRm):
(JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::putModRmSib):
(JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::registerModRM):
(JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::memoryModRM):
(JSC::X86Assembler::X86InstructionFormatter::oneByteOp): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::oneByteOp_disp32): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::oneByteOp_disp8): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::twoByteOp): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::threeByteOp): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::oneByteOp64): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::oneByteOp64_disp32): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::oneByteOp64_disp8): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::twoByteOp64): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::oneByteOp8): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::twoByteOp8): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::emitRex): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::emitRexW): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::emitRexIf): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::emitRexIfNeeded): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::putModRm): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::putModRmSib): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::registerModRM): Deleted.
(JSC::X86Assembler::X86InstructionFormatter::memoryModRM): Deleted.
2016-03-25 Saam barati <sbarati@apple.com>
RegExp.prototype.test should be an intrinsic again
https://bugs.webkit.org/show_bug.cgi?id=155861
Reviewed by Yusuke Suzuki.
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
2016-03-25 Mark Lam <mark.lam@apple.com>
ES6's throwing of TypeErrors on access of RegExp.prototype flag properties breaks websites.
https://bugs.webkit.org/show_bug.cgi?id=155904
Reviewed by Geoffrey Garen.
There exists a JS library XRegExp (see http://xregexp.com) that extends the regexp
implementation. XRegExp does feature testing by comparing RegExp.prototype.sticky
to undefined. See:
Example 1. https://github.com/slevithan/xregexp/blob/28a2b033c5951477bed8c7c867ddf7e89c431cd4/tests/perf/index.html
...
} else if (knownVersion[version]) {
// Hack around ES6 incompatibility in XRegExp versions prior to 3.0.0
if (parseInt(version, 10) < 3) {
delete RegExp.prototype.sticky;
}
...
Example 2. https://github.com/slevithan/xregexp/blob/d0e665d4068cec4d15919215b098b2373f1f12e9/tests/perf/versions/xregexp-all-v2.0.0.js
...
// Check for flag y support (Firefox 3+)
hasNativeY = RegExp.prototype.sticky !== undef,
...
The ES6 spec states that we should throw a TypeError here because RegExp.prototype
is not a RegExp object, and the sticky getter is only allowed to be called on
RegExp objects. See https://tc39.github.io/ecma262/2016/#sec-get-regexp.prototype.sticky.
As a result, websites that uses XRegExp can break (e.g. some Atlassian tools).
As a workaround, we'll return undefined instead of throwing on access of these
flag properties that may be used for feature testing.
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoGetterGlobal):
(JSC::regExpProtoGetterIgnoreCase):
(JSC::regExpProtoGetterMultiline):
(JSC::regExpProtoGetterSticky):
(JSC::regExpProtoGetterUnicode):
2016-03-25 Caitlin Potter <caitp@igalia.com>
[JSC] fix divide-by-zero in String.prototype.padStart/padEnd
https://bugs.webkit.org/show_bug.cgi?id=155903
Reviewed by Filip Pizlo.
* runtime/StringPrototype.cpp:
(JSC::padString):
2016-03-25 Benjamin Poulain <benjamin@webkit.org>
[JSC] materialize-past-butterfly-allocation.js time out in debug
* tests/stress/materialize-past-butterfly-allocation.js:
The test times out on the debug bots. We suspect there is nothing
wrong, just overkill loops.
2016-03-25 Brian Burg <bburg@apple.com>
Web Inspector: protocol generator should prefix C++ filenames with the protocol group
https://bugs.webkit.org/show_bug.cgi?id=155859
<rdar://problem/25349859>
Reviewed by Alex Christensen and Joseph Pecoraro.
Like for generated Objective-C files, we should use the 'protocol group' name
as the prefix for generated C++ files so that headers from different protocol
groups have unambiguous names.
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator):
(CppGenerator.__init__):
(CppGenerator.protocol_name):
Make all C++ code generators extend the CppGenerator python class and use the
protocol_name() instance method. This matches a recent change to the ObjC generator.
* inspector/scripts/codegen/cpp_generator_templates.py:
(CppGeneratorTemplates):
Drive-by cleanup to use #pragma once instead of header guards.
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
(CppAlternateBackendDispatcherHeaderGenerator):
(CppAlternateBackendDispatcherHeaderGenerator.__init__):
(CppAlternateBackendDispatcherHeaderGenerator.output_filename):
(CppAlternateBackendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator):
(CppBackendDispatcherHeaderGenerator.__init__):
(CppBackendDispatcherHeaderGenerator.output_filename):
(CppBackendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator):
(CppBackendDispatcherImplementationGenerator.__init__):
(CppBackendDispatcherImplementationGenerator.output_filename):
(CppBackendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator):
(CppFrontendDispatcherHeaderGenerator.__init__):
(CppFrontendDispatcherHeaderGenerator.output_filename):
(CppFrontendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator):
(CppFrontendDispatcherImplementationGenerator.__init__):
(CppFrontendDispatcherImplementationGenerator.output_filename):
(CppFrontendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator):
(CppProtocolTypesHeaderGenerator.__init__):
(CppProtocolTypesHeaderGenerator.output_filename):
(CppProtocolTypesHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator):
(CppProtocolTypesImplementationGenerator.__init__):
(CppProtocolTypesImplementationGenerator.output_filename):
(CppProtocolTypesImplementationGenerator.generate_output):
Use the protocol_name() instance method to compute generated protocol file names.
* inspector/scripts/codegen/models.py:
Explicitly set the 'protocol_group' for the Inspector protocol.
Rebaseline generator test results.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-03-25 Keith Miller <keith_miller@apple.com>
putByIndexBeyondVectorLengthWithoutAttributes should not crash if it can't ensureLength
https://bugs.webkit.org/show_bug.cgi?id=155730
Reviewed by Saam Barati.
This patch makes ensureLength return a boolean indicating if it was able to set the length.
ensureLength also no longer sets the butterfly to null if the allocation of the butterfly
fails. All of ensureLengths callers including putByIndexBeyondVectorLengthWithoutAttributes
have been adapted to throw an out of memory error if ensureLength fails.
* runtime/JSArray.cpp:
(JSC::JSArray::setLength):
(JSC::JSArray::unshiftCountWithAnyIndexingType):
* runtime/JSObject.cpp:
(JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
(JSC::JSObject::ensureLengthSlow):
* runtime/JSObject.h:
(JSC::JSObject::ensureLength):
2016-03-25 Caitlin Potter <caitp@igalia.com>
[JSC] implement String.prototype.padStart() and String.prototype.padEnd() proposal
https://bugs.webkit.org/show_bug.cgi?id=155795
Reviewed by Darin Adler.
Implements ECMAScript proposal http://tc39.github.io/proposal-string-pad-start-end/
Currently at Stage 3.
* runtime/JSString.h:
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::repeatCharacter):
(JSC::repeatStringPattern):
(JSC::padString):
(JSC::stringProtoFuncPadEnd):
(JSC::stringProtoFuncPadStart):
* tests/es6.yaml:
* tests/es6/String.prototype_methods_String.prototype.padEnd.js: Added.
* tests/es6/String.prototype_methods_String.prototype.padStart.js: Added.
2016-03-24 Alex Christensen <achristensen@webkit.org>
Fix Mac CMake build.
* PlatformMac.cmake:
Link to Security framework.
2016-03-24 Saam barati <sbarati@apple.com>
ES6: Implement IsRegExp function and use where needed in String.prototype.* methods
https://bugs.webkit.org/show_bug.cgi?id=155854
Reviewed by Mark Lam.
This patch is a straight forward implementation of IsRegExp
in the ES6 spec:
https://tc39.github.io/ecma262/#sec-isregexp
We now use this IsRegExp function inside String.prototype.(startsWith | endsWith | includes)
as is dictated by the spec.
* runtime/RegExpConstructor.h:
(JSC::RegExpConstructor::recordMatch):
(JSC::isRegExp):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncStartsWith):
(JSC::stringProtoFuncEndsWith):
(JSC::stringProtoFuncIncludes):
* tests/es6.yaml:
* tests/es6/well-known_symbols_Symbol.match_String.prototype.endsWith.js: Added.
(test):
* tests/es6/well-known_symbols_Symbol.match_String.prototype.includes.js: Added.
(test):
* tests/es6/well-known_symbols_Symbol.match_String.prototype.startsWith.js: Added.
(test):
* tests/stress/string-prototype-methods-endsWith-startsWith-includes-correctness.js: Added.
(assert):
(test):
(test.get let):
(get let):
2016-03-24 Saam barati <sbarati@apple.com>
Web Inspector: Separate Debugger enable state from the debugger breakpoints enabled state
https://bugs.webkit.org/show_bug.cgi?id=152193
<rdar://problem/23867520>
Reviewed by Joseph Pecoraro.
When all breakpoints are disabled, we can recompile all JS
code and remove the necessary debugging code that is emitted.
This allows for the code that is executing to be almost as fast
as it is with the debugger completely disabled. This is in preparation for:
https://bugs.webkit.org/show_bug.cgi?id=155809
which will introduce a high fidelity profiler. That profiler
could be built off the principle that breakpoints are disabled
when we're performing a high fidelity profile. Doing so, for example,
allows the sampling profiler to better measure the real performance
of the JS of a particular application.
* debugger/Debugger.cpp:
(JSC::Debugger::setBreakpointsActivated):
(JSC::Debugger::setPauseOnExceptionsState):
* debugger/Debugger.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
* inspector/JSGlobalObjectScriptDebugServer.cpp:
(Inspector::JSGlobalObjectScriptDebugServer::attachDebugger):
(Inspector::JSGlobalObjectScriptDebugServer::detachDebugger):
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::enable):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
(JSC::JSGlobalObject::createModuleProgramCodeBlock):
(JSC::JSGlobalObject::queueMicrotask):
(JSC::JSGlobalObject::hasDebugger):
(JSC::JSGlobalObject::hasInteractiveDebugger):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::runtimeFlags):
(JSC::JSGlobalObject::hasDebugger): Deleted.
2016-03-24 Michael Saboff <msaboff@apple.com>
Create private builtin helper advanceStringIndexUnicode() for use by RegExp builtins
https://bugs.webkit.org/show_bug.cgi?id=155855
Reviewed by Mark Lam.
Moved advanceStringIndexUnicode() as a separate helper. Added it as a private builtin
to the GlobalObject like other private builtins.
* builtins/RegExpPrototype.js:
(advanceStringIndexUnicode):
(match):
(match.advanceStringIndexUnicode): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2016-03-24 Michael Saboff <msaboff@apple.com>
[ES6] Add Proxy based tests for RegExp.prototype[@@match]
https://bugs.webkit.org/show_bug.cgi?id=155807
Reviewed by Saam Barati.
Added new test that uses Proxy to verify RegExp.prototype[@@match] processing
conforms to the ES6 standard
Modified builtin RegExp.prototype[@@match] to be ES6 spec conformant.
Updated es6.yaml as Proxy_internal_get_calls_RegExp.prototype[Symbol.match].js now passes.
* builtins/RegExpPrototype.js:
(match):
* tests/es6.yaml: Updated.
* tests/stress/regexp-match-proxy.js: Added.
(assert):
(let.getProxyNullExec.new.Proxy):
(let.getSetProxyNullExec.new.Proxy):
(get resetTracking):
(let.getSetProxyMatches_s.new.Proxy):
(set get getSetProxyNullExec):
(let.getSetProxyMatches_tx_Greedy.new.Proxy):
(set get getSetProxyMatches_s):
(let.getSetProxyMatchesUnicode_digit_nonGreedy.new.Proxy):
(set get getSetProxyMatches_tx_Greedy):
2016-03-24 Michael Saboff <msaboff@apple.com>
[ES6] Greedy unicode RegExp's don't properly backtrack past non BMP characters
https://bugs.webkit.org/show_bug.cgi?id=155829
Reviewed by Saam Barati.
When we backup when matching part of a unicode pattern, we can't just backup one character.
Instead we need to save our start position before trying to match a character and
restore the position if the match fails. This was done in other places, but wasn't
done for all greedy types.
Fixed matchGlobal() to properly handle advancing past non BMP characters.
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::matchGlobal):
* runtime/RegExpObjectInlines.h:
(JSC::RegExpObject::advanceStringUnicode):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::matchCharacterClass):
(JSC::Yarr::Interpreter::matchDisjunction):
2016-03-24 Benjamin Poulain <bpoulain@apple.com>
[JSC] In some cases, the integer range optimization phase never converges
https://bugs.webkit.org/show_bug.cgi?id=155828
rdar://problem/25155460
Reviewed by Filip Pizlo.
In certain conditions, the integer range optimization phase continuously
changes the representation of the same truth, preventing it from
converging to a stable state.
The bug starts by having the same ground truth incomming into a block
in different valid forms. For example, you can have x < 42 coming as:
1) x < 42
2) x < 41 + 1
3) x < 43 - 1
Having those 3 alone coming from predecessors would be okay, we would
just accumulate them. The problem is when you have a combination
of rule that filter out the previously obtained truth, then add a new
form of the same truth.
Let's use the test case as an example. We have two incoming blocks:
Block #1:
-i < 42
-i != 41
Block #2:
-i < 41
-i == 42 - 42 (i == 0 refining the rule above).
Let say that our conditions at head are now [i < 41, i < 42 - 1].
If we merge block #2:
-i < 42 and i < 41 -> i < 42
-i < 42 and i < 42 - 1 -> i < 42
-i != 41 and i < 41 -> i < 41
-i != 41 and i < 42 - 1 -> nothing
The new head is: [i < 41, i < 42]
If we merge block #1:
-i < 41 and i < 41 -> i < 41
-i < 41 and i < 42 -> i < 42
-i == 42 - 42 and i < 41 -> (i < 41 and i < 42 - 1)
-i == 42 - 42 and i < 42 -> i < 42
After filter, we are back to [i < 41, i < 42 - 1].
There are several variations of this idea where the same truth
rotate different forms with each merge().
One possible solution is to make filter() more aggressive
to avoid the better form occuring at merge(). I'll probably
do that at some point but that seems fragile since the same
problem could reappear if merge() is later improved.
For this patch, I went with a more generic solution after
merge(): if the generated form is equivalent to one that
previously existed at head, pick the existing form.
In the previous example, what happens is we only have
either [i < 41] or [i < 42 - 1] but never both simultaneously.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* tests/stress/integer-range-optimization-constant-representation-1.js: Added.
* tests/stress/integer-range-optimization-constant-representation-2.js: Added.
Two variation. One timeout in release because of the additional flags.
The other is gets more type of run but only assert in debug.
2016-03-23 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r198582.
https://bugs.webkit.org/show_bug.cgi?id=155812
"It broke debugging in the web inspector" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"We should not disable inlining when the debugger is enabled"
https://bugs.webkit.org/show_bug.cgi?id=155741
http://trac.webkit.org/changeset/198582
2016-03-23 Michael Saboff <msaboff@apple.com>
JavaScriptCore ArrayPrototype::join shouldn't cache butterfly when it makes effectful calls
https://bugs.webkit.org/show_bug.cgi?id=155776
Reviewed by Saam Barati.
Array.join ends up calling toString, possibly on some object. Since these calls
could be effectful and could change the array itself, we can't hold the butterfly
pointer while making effectful calls. Changed the code to fall back to the general
case when an effectful toString() call might be made.
* runtime/ArrayPrototype.cpp:
(JSC::join):
* runtime/JSStringJoiner.h:
(JSC::JSStringJoiner::appendWithoutSideEffects): New helper that doesn't make effectful
toString() calls.
(JSC::JSStringJoiner::append): Built upon appendWithoutSideEffects.
2016-03-23 Keith Miller <keith_miller@apple.com>
Array.prototype native functions' species constructors should work with proxies
https://bugs.webkit.org/show_bug.cgi?id=155798
Reviewed by Mark Lam.
Before native the species constructors were checking if the this value was a JSArray.
Instead they should look check that the this value returns true on Array.isArray.
* runtime/ArrayPrototype.cpp:
(JSC::speciesConstructArray):
* tests/es6.yaml:
* tests/stress/proxy-array-prototype-methods.js:
2016-03-23 Saam barati <sbarati@apple.com>
We should not disable inlining when the debugger is enabled
https://bugs.webkit.org/show_bug.cgi?id=155741
Reviewed by Oliver Hunt.
We can enable inlining when the debugger is enabled as long
as we make sure we still jettison the proper CodeBlocks when
a breakpoint is set. This means that for any optimized CodeBlock,
we must ask if any of its inlinees contain the breakpoint that
is being set. If any inlinees do contain the breakpoint, we must
jettison the machine code block that they are a part of.
* debugger/Debugger.cpp:
(JSC::Debugger::toggleBreakpoint):
(JSC::Debugger::applyBreakpoints):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::ByteCodeParser):
(JSC::DFG::ByteCodeParser::setLocal):
(JSC::DFG::ByteCodeParser::flush):
(JSC::DFG::ByteCodeParser::flushForTerminal):
(JSC::DFG::ByteCodeParser::inliningCost):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::~Graph):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::hasDebuggerEnabled): Deleted.
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
2016-03-23 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Allow undefined/null for Symbol.search and Symbol.match
https://bugs.webkit.org/show_bug.cgi?id=155785
Reviewed by Saam Barati.
Undefined and null for Symbol.search and Symbol.match properties of the given RegExp (like) object are allowed.
When they are specified, we go to the fallback path; creating the RegExp with the given object and matching.
* builtins/StringPrototype.js:
(match):
(search):
* tests/stress/string-symbol-customization.js: Added.
(shouldBe):
(shouldThrow):
2016-03-22 Caitlin Potter <caitp@igalia.com>
[JSC] correctly handle indexed properties in Object.getOwnPropertyDescriptors
https://bugs.webkit.org/show_bug.cgi?id=155563
Reviewed by Saam Barati.
* runtime/JSObject.h:
(JSC::JSObject::putOwnDataPropertyMayBeIndex):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptors):
2016-03-22 Saam Barati <sbarati@apple.com>
We should FTL compile code when the debugger is enabled
https://bugs.webkit.org/show_bug.cgi?id=155740
Reviewed by Oliver Hunt.
There was no fundamental reason why we didn't support debugging
with the FTL. It looks like this was just an oversight. We had
a Breakpoint node in the DFG that amounted to a nop. By removing
this node, we now support debugging in the FTL. Anytime a breakpoint
is set, we will jettison any DFG/FTL CodeBlocks that contain the breakpoint
that was set.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2016-03-22 Keith Miller <keith_miller@apple.com>
REGRESSION(r197543): Use-after-free on storage/indexeddb/transaction-abort-private.html
https://bugs.webkit.org/show_bug.cgi?id=155067
Reviewed by Filip Pizlo.
GCIncommingRefCountedSets need to be finalized before we start
destructing members of the Heap object. Previously, we would
clear all our ArrayBuffer objects when the GCIncommingRefCountedSet
holding them was destroyed. However, ArrayBuffers have a weak
reference to their wrappers. When we would attempt to destroy the
ArrayBuffer object we would end up accessing the WeakImpl for
the weak reference, which had already been freed as we destroyed
our weak block. The solution to this is to move the old
GCIncommingRefCountedSet destructor functionality to a new
function lastChanceToFinalize. This function is called when
we finalize our other objects on Heap destruction.
* heap/GCIncomingRefCountedSet.h:
* heap/GCIncomingRefCountedSetInlines.h:
(JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):
(JSC::GCIncomingRefCountedSet<T>::~GCIncomingRefCountedSet): Deleted.
* heap/Heap.cpp:
(JSC::Heap::lastChanceToFinalize):
2016-03-22 Per Arne Vollan <peavo@outlook.com>
[Win] [64-bit] Remove MSVC 2013 FMA3 Bug Workaround
https://bugs.webkit.org/show_bug.cgi?id=141499
Reviewed by Brent Fulgham.
As we have moved on to VS2015, this workaround is no longer needed.
* API/tests/testapi.c:
(main):
* JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp:
(wWinMain):
* jsc.cpp:
(main):
* testRegExp.cpp:
(main):
2016-03-22 Michael Saboff <msaboff@apple.com>
[ES6] Implement RegExp.prototype[@@match]
https://bugs.webkit.org/show_bug.cgi?id=155711
Reviewed by Filip Pizlo.
Implemented ES6 spec for String.prototype.match and RegExp.prototype[@@match].
Implemented both as builtins, with String.prototype.match calling
RegExp.prototype[@@match].
For performance reasons, RegExp.prototype[@@match] has a C++ fast path when
RegExp.prototype.exec has not been overridden. This fast path,
RegExpObject::matchGlobal, was taken from the prior StringPrototype::match.
It only handles global matches.
Added new test, stress/regexp-match.js.
Updated various tests for changes exception string and now passing ES6 behavior.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
Added builtins/RegExpPrototype.js and eliminated RegExpPrototype.lut.h.
* builtins/RegExpPrototype.js: Added.
(match.advanceStringIndexUnicode): Helper.
(match): Implements RegExp.prototype[@@match].
* builtins/StringPrototype.js:
(match): Implements String.prototype.match.
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
(JSC::BytecodeIntrinsicRegistry::lookup):
* bytecode/BytecodeIntrinsicRegistry.h:
* runtime/CommonIdentifiers.h:
Added Symbol.match and builtins @match and @exec.
* runtime/RegExpObject.cpp:
* runtime/RegExpObject.h:
* runtime/RegExpObjectInlines.h:
(JSC::RegExpObject::matchGlobal): Added.
(JSC::RegExpObject::advanceStringUnicode): Added helper.
* runtime/RegExpPrototype.cpp:
* runtime/RegExpPrototype.h:
(JSC::RegExpPrototype::RegExpPrototype):
(JSC::RegExpPrototype::finishCreation):
(JSC::RegExpPrototype::visitChildren):
(JSC::regExpProtoFuncMatchPrivate):
(JSC::RegExpPrototype::getOwnPropertySlot): Deleted.
(JSC::RegExpPrototype::create):
Restructured to create properties explicitly due to having two names for native regExpProtoFuncExec.
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
Made match a builtin.
Removed unused declaration of stringProtoFuncSearch() since it was made a builtin.
* tests/es6.yaml:
* tests/stress/regexp-match.js: Added.
(shouldBe):
(shouldThrow):
(errorKey.toString):
(primitive.of.primitives.shouldThrow):
(testRegExpMatch):
(testMatch):
(testBoth):
(alwaysUnmatch):
2016-03-22 Caitlin Potter <caitp@igalia.com>
[JSC] allow duplicate property names returned from Proxy ownKeys() trap
https://bugs.webkit.org/show_bug.cgi?id=155560
Reviewed by Darin Adler.
Specification allows duplicate property names to be reported by the
Proxy ownKeys() trap --- and this is observable in any API which
operates on the returned list, such as Object.keys(),
Object.getOwnPropertyNames(), Object.getOwnPropertySymbols(), or
Object.getOwnPropertyDescriptors().
* runtime/PropertyNameArray.h:
(JSC::PropertyNameArray::addUnchecked):
(JSC::PropertyNameArray::add):
(JSC::PropertyNameArray::addKnownUnique): Deleted.
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performGetOwnPropertyNames):
* runtime/Structure.cpp:
(JSC::Structure::getPropertyNamesFromStructure):
2016-03-21 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Clean up Math.floor thunk and use SSE round instruction
https://bugs.webkit.org/show_bug.cgi?id=155705
Reviewed by Geoffrey Garen.
SSE now allow us to use round instruction to implement Math.floor.
MacroAssembler's floorDouble is now only used in ARM64, but it can be allowed in x86 SSE.
* jit/ThunkGenerators.cpp:
(JSC::floorThunkGenerator):
2016-03-21 Konstantin Tokarev <annulen@yandex.ru>
Fixed compilation with GCC 4.8.
https://bugs.webkit.org/show_bug.cgi?id=155698
Reviewed by Alexey Proskuryakov.
GCC 4.8 does not allow aggregate initialization for type with deleted
constructor, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707.
* dfg/DFGCSEPhase.cpp: Added ctor for ImpureDataSlot.
2016-03-21 Joonghun Park <jh718.park@samsung.com>
[JSC] Add ArrayBuffer::tryCreate and change the callsites where it is needed
https://bugs.webkit.org/show_bug.cgi?id=155328
Reviewed by Darin Adler.
* API/JSTypedArray.cpp:
(JSObjectMakeTypedArray):
(JSObjectMakeArrayBufferWithBytesNoCopy):
* runtime/ArrayBuffer.h:
(JSC::ArrayBuffer::create):
(JSC::ArrayBuffer::tryCreate):
(JSC::ArrayBuffer::createUninitialized):
(JSC::ArrayBuffer::tryCreateUninitialized):
(JSC::ArrayBuffer::createInternal):
* runtime/GenericTypedArrayViewInlines.h:
(JSC::GenericTypedArrayView<Adaptor>::create):
(JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::constructArrayBuffer):
2016-03-20 Dan Bernstein <mitz@apple.com>
[Mac] Determine TARGET_MAC_OS_X_VERSION_MAJOR from MACOSX_DEPLOYMENT_TARGET rather than from MAC_OS_X_VERSION_MAJOR
https://bugs.webkit.org/show_bug.cgi?id=155707
<rdar://problem/24980691>
Reviewed by Darin Adler.
* Configurations/Base.xcconfig: Set TARGET_MAC_OS_X_VERSION_MAJOR based on the last
component of MACOSX_DEPLOYMENT_TARGET.
* Configurations/DebugRelease.xcconfig: For engineering builds, preserve the behavior of
TARGET_MAC_OS_X_VERSION_MAJOR being the host’s OS version.
2016-03-20 Michael Saboff <msaboff@apple.com>
Crash in stress/regexp-matches-array-slow-put.js due to stomping on memory when having bad time
https://bugs.webkit.org/show_bug.cgi?id=155679
Reviewed by Saam Barati.
Allocate out of line storage based on what the structure says it needs
in JSArray::tryCreateUninitialized.
* runtime/JSArray.h:
(JSC::JSArray::tryCreateUninitialized):
2016-03-20 Joseph Pecoraro <pecoraro@apple.com>
Crash on DFG::WorkList thread in JSC::Heap::isCollecting for destroyed Web Worker
https://bugs.webkit.org/show_bug.cgi?id=155678
<rdar://problem/25251439>
Reviewed by Filip Pizlo.
This fixes a crash that we saw with GuardMalloc. If the Plan was
Cancelled it may not be safe to access the VM. If the Plan was
cancelled we are just going to bail anyways, so keep the ASSERT but
short-circuit if the plan was Cancelled.
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::runThread):
2016-03-20 Dan Bernstein <mitz@apple.com>
Update build settings
Rubber-stamped by Andy Estes.
* Configurations/DebugRelease.xcconfig:
* Configurations/FeatureDefines.xcconfig:
* Configurations/Version.xcconfig:
2016-03-19 Skachkov Oleksandr <gskachkov@gmail.com>
[ES6] Arrow function syntax. Update syntax error text 'super is only valid inside functions' to more suitable
https://bugs.webkit.org/show_bug.cgi?id=155491
Reviewed by Saam Barati.
Current message 'super is only valid inside of funcitons' is not correct
after patch for https://bugs.webkit.org/show_bug.cgi?id=153864 because
it is allow to use 'super' in eval. Current patch replace old message by
'Super is only valid inside functions or 'eval' inside a function' and
fix tests that rely on this message.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
* tests/stress/generator-with-super.js:
(shouldThrow):
* tests/stress/modules-syntax-error.js:
* tests/stress/super-in-lexical-scope.js:
* tests/stress/tagged-templates-syntax.js:
2016-03-19 Mark Lam <mark.lam@apple.com>
ES6 spec requires that ErrorPrototype not be an Error object.
https://bugs.webkit.org/show_bug.cgi?id=155680
Reviewed by Michael Saboff.
The ES6 spec states that Error.prototype should not be an instance of Error:
https://tc39.github.io/ecma262/#sec-properties-of-the-error-prototype-object
"The Error prototype object is an ordinary object. It is not an Error instance
and does not have an [[ErrorData]] internal slot."
This patch changes ErrorPrototype to conform to the above specification.
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::finishCreation):
* runtime/ErrorPrototype.cpp:
(JSC::ErrorPrototype::ErrorPrototype):
(JSC::ErrorPrototype::finishCreation):
(JSC::ErrorPrototype::getOwnPropertySlot):
* runtime/ErrorPrototype.h:
(JSC::ErrorPrototype::create):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor::finishCreation):
* runtime/NativeErrorPrototype.cpp:
(JSC::NativeErrorPrototype::NativeErrorPrototype):
(JSC::NativeErrorPrototype::finishCreation):
* runtime/NativeErrorPrototype.h:
(JSC::NativeErrorPrototype::create):
- updated to no longer need a JSGlobalObject argument.
* tests/es6/miscellaneous_built-in_prototypes_are_not_instances.js:
- updated to match the kangax version of this test.
2016-03-18 Benjamin Poulain <bpoulain@apple.com>
[JSC] Limit DFG's Validate symbols to its compilation unit
https://bugs.webkit.org/show_bug.cgi?id=155670
Reviewed by Filip Pizlo.
* dfg/DFGValidate.cpp:
2016-03-18 Mark Lam <mark.lam@apple.com>
ES6 spec requires that RegExpPrototype not be a RegExp object.
https://bugs.webkit.org/show_bug.cgi?id=155654
Reviewed by Filip Pizlo.
The ES6 spec states that RegExp.prototype should not be an instance of RegExp:
https://tc39.github.io/ecma262/#sec-properties-of-the-regexp-prototype-object
"The RegExp prototype object is an ordinary object. It is not a RegExp instance
and does not have a [[RegExpMatcher]] internal slot or any of the other internal
slots of RegExp instance objects."
This patch changes RegExpPrototype to conform to the above specifications.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::RegExpConstructor):
(JSC::RegExpConstructor::finishCreation):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::RegExpPrototype):
(JSC::RegExpPrototype::finishCreation):
(JSC::RegExpPrototype::getOwnPropertySlot):
(JSC::RegExpPrototype::visitChildren):
(JSC::regExpProtoFuncTest):
* runtime/RegExpPrototype.h:
(JSC::RegExpPrototype::create):
(JSC::RegExpPrototype::createStructure):
(JSC::RegExpPrototype::emptyRegExp):
* tests/es6.yaml:
- This patch makes the es6/miscellaneous_built-in_prototypes_are_not_instances.js
test now pass. However, the kangax version of this test still fails because
it also checks Error objects (which will be fixed in a subsequent patch).
* tests/mozilla/ecma_2/shell.js:
(stringify):
(test):
(getFailedCases):
(err):
* tests/stress/static-getter-in-names.js:
(shouldBe):
2016-03-18 Keith Miller <keith_miller@apple.com>
DataView should use an accessor for its length and buffer properties
https://bugs.webkit.org/show_bug.cgi?id=155625
Reviewed by Michael Saboff.
The DataView object should use an accessor on DataView.prototype for its
byteLength, byteOffset, and buffer properties. This patch also, moves the
buffer property off the TypedArray object itself and onto the prototype
along with the other accessors. Since the .buffer property is no longer on
the object, JSArrayBufferView no longer needs to intercept accesses to
properties. Finally, this patch also fixes the length property on all the
existing DataView.prototype functions.
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::getOwnPropertySlot): Deleted.
(JSC::JSArrayBufferView::put): Deleted.
(JSC::JSArrayBufferView::defineOwnProperty): Deleted.
(JSC::JSArrayBufferView::deleteProperty): Deleted.
(JSC::JSArrayBufferView::getOwnNonIndexPropertyNames): Deleted.
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::jsBuffer):
* runtime/JSDataViewPrototype.cpp:
(JSC::dataViewProtoGetterBuffer):
(JSC::dataViewProtoGetterByteLength):
(JSC::dataViewProtoGetterByteOffset):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoGetterFuncBuffer):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::typedArrayViewProtoGetterFuncBuffer):
(JSC::JSTypedArrayViewPrototype::finishCreation):
2016-03-18 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed speculative cloop buildfix after r198364.
* bytecode/SuperSampler.cpp:
2016-03-17 Benjamin Poulain <bpoulain@apple.com>
[JSC] Make CSE's ImpureData faster when dealing with large blocks
https://bugs.webkit.org/show_bug.cgi?id=155594
Reviewed by Filip Pizlo.
In some tests with large blocks, the time spent in DFG's LocalCSE
can be over 10% of the total compile time.
In those cases, LocalCSE is completely dominated by handling large
blocks.
This patch addresses the most obvious hot spots ImpureData's handling.
Initially, most of the time was going into HashTable::rehash().
The reason is the buckets are <HeapLocation, LazyNode> gigantic.
The hash table would easily get into several kilobytes and the CPU
was spending more time dealing with memory than anything.
To solve that, I moved the pairs lazily to the heap. The table itself
just contains the unique_ptr to those values. This makes the table
reasonably small and the alloc/dealloc are paid for by the fast rehash().
Once addImpure() was better, the next big bottleneck was clobber().
For each clobber(), we need to go over the entire map and test each value.
That loop was where most of the time was going.
Most calls to clobber() come from two kinds: SideState and Stack.
SideState is easy: it is never def'ed so we can always skip it.
Stack is disjoint from Heap too so we can also put it separately.
Splitting the map into 2 helped reduce the overhead. The maps are:
-Stack
-Heap
Having Stack alone was not enough for many blocks. In some cases,
you have a ton of SetLocal/GetLocal and having Stack separately
makes no difference.
To solve that, I split Stack in two: a map addressed by AbstractHeap
+ unique HeapLocation and a fallback map for everything else.
Since most Stack are not TOP and are unique per AbstractHeap,
I get O(1) clobber in most cases.
I could achieve the same result with a custom hash structure.
I don't think it is worth the effort, in most cases, m_fallbackStackMap
has a size of zero or one.
This patch introduces a lot of coupling between CSE and AbstractHeap.
To reduce the risk of bugs, the old map is still maintained in debug
and each step checks that the results are the same as the new implementation.
A new validation step also verify the strong assumptions made by CSE:
-SideState and World are never def().
-We never write HEAP TOP, we only write specific heap location.
* dfg/DFGCSEPhase.cpp:
* dfg/DFGHeapLocation.h:
* dfg/DFGLazyNode.h:
(JSC::DFG::LazyNode::hash):
2016-03-17 Saam barati <sbarati@apple.com>
Implement SmallPtrSet and integrate it into the Parser
https://bugs.webkit.org/show_bug.cgi?id=155552
Reviewed by Filip Pizlo.
Using SmallPtrSet instead of HashSet really helps speed
up the parser. What saves us most is not needing to always
malloc/free memory in the HashSet.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::startSwitch):
(JSC::Scope::endSwitch):
(JSC::Scope::startLoop):
(JSC::Scope::hasDeclaredParameter):
(JSC::Scope::declareWrite):
(JSC::Scope::declareParameter):
(JSC::Scope::usedVariablesContains):
(JSC::Scope::useVariable):
(JSC::Scope::collectFreeVariables):
(JSC::Scope::getCapturedVars):
(JSC::Scope::isValidStrictMode):
(JSC::Scope::shadowsArguments):
(JSC::Scope::copyCapturedVariablesToVector):
(JSC::Scope::setIsModule):
(JSC::Parser::pushScope):
(JSC::Scope::getUsedVariables): Deleted.
2016-03-17 Brian Burg <bburg@apple.com>
Web Inspector: protocol generator shouldn't generate enums for parameters with non-anonymous enum types
https://bugs.webkit.org/show_bug.cgi?id=155610
<rdar://problem/25229878>
Reviewed by Joseph Pecoraro.
If a command parameter has an anonymous enum type, the backend dispatcher generator
makes a C++ enum for the parameter. However, if the parameter references a named enum
type specified in a domain's 'type' section, then there's no need to generate an enum.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
Add a missing check for the is_anonymous flag. Type references to named enums are resolved
to the underlying aliased EnumType instead of an AliasedType, so we have to check the flag.
Rebaseline tests.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2016-03-17 Filip Pizlo <fpizlo@apple.com>
Replace all of the various non-working and non-compiling sampling profiler hacks with a single super hack
https://bugs.webkit.org/show_bug.cgi?id=155561
Reviewed by Saam Barati.
A VM needs some internal profiling hacks in addition to the profiler(s) that the user sees, because
you can squeeze out more fidelity if you're willing to make some kind of deal with the devil. Prior
to this change JSC had a bunch of these:
- CodeBlock sampling profiler
- Bytecode sampling profiler
- Sampling flags
- Sampling regions
- Some other stuff
I tried using these recently. They didn't even build. Initially I fixed that, but then I found that
these profilers had some serious bugs that made them report bogus results - like underreporting the
time spent in regions of code by more than 2x.
Part of the problem here is that a profiler loses fidelity as it gains power. The more general it
tries to be, the more code gets executed on the hot path for the profiler, which increasingly
perturbs the results. I believe that's the reason for the underreporting - code ran sufficiently
slower, and in a sufficiently different way when profiling, that the results were just wrong.
This change attacks this problem directly by replacing all of the diverse profiling hacks with just
one, which I call the SuperSampler. It consists of exactly one counter. When enabled, the sampler
will periodically print (via dataLog()) the percentage of samples that saw a non-zero count. Because
it's so simple, it gives better accuracy. This comes about in two ways:
- It runs at a lower rate. That's fine since it's only checking one flag. You don't need a high rate
for just one flag.
- The fact that there is only *one* flag means that the user must choose a hypothesis about what is
slow. This turns the problem of profiling into a hypothesis testing problem, which is an inherently
less flaky kind of experiment to run.
The SuperSampler is enabled with a runtime flag rather than a compile-time flag, so it's much less
likely to break. That also means that you can enable it without rebuilding the universe. The old
samplers all had ENABLE flags in Platform.h, which was rather unfortunate for compile times.
SuperSampler supports both JIT and C++ users. C++ users should use SuperSamplerScope. The default
idiom is to create one and pass "true" to it. You can disable a scope by passing "false" instead.
This patch puts a bunch of scopes in places I care about. I think it's probably OK if people check in
these deactivated scopes. That makes it convenient to retest things we've tested previously.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/SamplingTool.cpp: Removed.
* bytecode/SamplingTool.h: Removed.
* bytecode/SuperSampler.cpp: Added.
(JSC::initializeSuperSampler):
(JSC::printSuperSamplerState):
* bytecode/SuperSampler.h: Added.
(JSC::SuperSamplerScope::SuperSamplerScope):
(JSC::SuperSamplerScope::~SuperSamplerScope):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
* bytecompiler/NodesCodegen.cpp:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::forAllValues):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberStructures):
* dfg/DFGArgumentsEliminationPhase.cpp:
(JSC::DFG::performArgumentsElimination):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::performBackwardsPropagation):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::parse):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::performCFA):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::performCFGSimplification):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlocks):
(JSC::DFG::CPSRethreadingPhase::propagatePhis):
(JSC::DFG::performCPSRethreading):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::performLocalCSE):
(JSC::DFG::performGlobalCSE):
* dfg/DFGCleanUpPhase.cpp:
(JSC::DFG::performCleanUp):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::performConstantFolding):
* dfg/DFGConstantHoistingPhase.cpp:
(JSC::DFG::performConstantHoisting):
* dfg/DFGCriticalEdgeBreakingPhase.cpp:
(JSC::DFG::performCriticalEdgeBreaking):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::performDCE):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::performFixup):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dethread):
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::performIntegerCheckCombining):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
(JSC::DFG::performIntegerRangeOptimization):
* dfg/DFGInvalidationPointInjectionPhase.cpp:
(JSC::DFG::performInvalidationPointInjection):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::performLICM):
* dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::performLiveCatchVariablePreservationPhase):
* dfg/DFGLivenessAnalysisPhase.cpp:
(JSC::DFG::performLivenessAnalysis):
* dfg/DFGLoopPreHeaderCreationPhase.cpp:
(JSC::DFG::performLoopPreHeaderCreation):
* dfg/DFGMaximalFlushInsertionPhase.cpp:
(JSC::DFG::performMaximalFlushInsertion):
* dfg/DFGMovHintRemovalPhase.cpp:
(JSC::DFG::performMovHintRemoval):
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::performOSRAvailabilityAnalysis):
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::performOSREntrypointCreation):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::performObjectAllocationSinking):
* dfg/DFGOperations.cpp:
* dfg/DFGPhantomInsertionPhase.cpp:
(JSC::DFG::performPhantomInsertion):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::performPredictionInjection):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::performPredictionPropagation):
* dfg/DFGPutStackSinkingPhase.cpp:
(JSC::DFG::performPutStackSinking):
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::performSSAConversion):
* dfg/DFGSSALoweringPhase.cpp:
(JSC::DFG::performSSALowering):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::performStackLayout):
* dfg/DFGStaticExecutionCountEstimationPhase.cpp:
(JSC::DFG::performStaticExecutionCountEstimation):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
(JSC::DFG::performFastStoreBarrierInsertion):
(JSC::DFG::performGlobalStoreBarrierInsertion):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::performStrengthReduction):
* dfg/DFGStructureAbstractValue.cpp:
(JSC::DFG::StructureAbstractValue::assertIsRegistered):
(JSC::DFG::StructureAbstractValue::clobber):
(JSC::DFG::StructureAbstractValue::observeTransition):
(JSC::DFG::StructureAbstractValue::observeTransitions):
(JSC::DFG::StructureAbstractValue::add):
(JSC::DFG::StructureAbstractValue::merge):
(JSC::DFG::StructureAbstractValue::mergeSlow):
(JSC::DFG::StructureAbstractValue::mergeNotTop):
(JSC::DFG::StructureAbstractValue::filter):
(JSC::DFG::StructureAbstractValue::filterSlow):
(JSC::DFG::StructureAbstractValue::contains):
(JSC::DFG::StructureAbstractValue::isSubsetOf):
(JSC::DFG::StructureAbstractValue::isSupersetOf):
(JSC::DFG::StructureAbstractValue::overlaps):
(JSC::DFG::StructureAbstractValue::equalsSlow):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::performStructureRegistration):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::performTierUpCheckInjection):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::performTypeCheckHoisting):
* dfg/DFGUnificationPhase.cpp:
(JSC::DFG::performUnification):
* dfg/DFGVarargsForwardingPhase.cpp:
(JSC::DFG::performVarargsForwarding):
* dfg/DFGVirtualRegisterAllocationPhase.cpp:
(JSC::DFG::performVirtualRegisterAllocation):
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::performWatchpointCollection):
* dynbench.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
(JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
(JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
(JSC::FTL::DFG::LowerDFGToB3::compileGetRegExpObjectLastIndex):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::store):
(JSC::FTL::Output::absolute):
(JSC::FTL::Output::incrementSuperSamplerCount):
(JSC::FTL::Output::decrementSuperSamplerCount):
* ftl/FTLOutput.h:
(JSC::FTL::Output::baseIndex):
(JSC::FTL::Output::load8SignExt32):
(JSC::FTL::Output::load8ZeroExt32):
(JSC::FTL::Output::anchor):
(JSC::FTL::Output::absolute): Deleted.
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::collectAndSweep):
(JSC::Heap::collectImpl):
(JSC::Heap::zombifyDeadObjects):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::specializedSweep):
* interpreter/Interpreter.cpp:
(JSC::setupVarargsFrameAndSetThis):
(JSC::Interpreter::Interpreter):
(JSC::Interpreter::initialize):
(JSC::checkedReturn):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::debug):
(JSC::SamplingScope::SamplingScope): Deleted.
(JSC::SamplingScope::~SamplingScope): Deleted.
(JSC::Interpreter::enableSampler): Deleted.
(JSC::Interpreter::dumpSampleData): Deleted.
(JSC::Interpreter::startSampling): Deleted.
(JSC::Interpreter::stopSampling): Deleted.
* interpreter/Interpreter.h:
(JSC::Interpreter::isCallBytecode):
(JSC::Interpreter::sampler): Deleted.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::branchIfNotFastTypedArray):
(JSC::AssemblyHelpers::incrementSuperSamplerCount):
(JSC::AssemblyHelpers::decrementSuperSamplerCount):
(JSC::AssemblyHelpers::purifyNaN):
* jit/AssemblyHelpers.h:
* jit/JIT.cpp:
* jit/JIT.h:
* jit/JITArithmetic.cpp:
* jit/JITArithmetic32_64.cpp:
* jit/JITCall.cpp:
* jit/JITCall32_64.cpp:
* jit/JITOperations.cpp:
* jit/JITPropertyAccess.cpp:
* jit/JITPropertyAccess32_64.cpp:
* jsc.cpp:
(runWithScripts):
(jscmain):
* parser/Nodes.cpp:
* parser/Parser.h:
(JSC::parse):
* runtime/Executable.h:
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/Options.h:
* runtime/RegExpCachedResult.h:
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
* runtime/StringPrototype.cpp:
(JSC::removeUsingRegExpSearch):
(JSC::stringProtoFuncSubstring):
* runtime/VM.cpp:
(JSC::VM::resetDateCache):
(JSC::VM::whenIdle):
(JSC::VM::deleteAllCode):
(JSC::VM::addSourceProviderCache):
(JSC::VM::startSampling): Deleted.
(JSC::VM::stopSampling): Deleted.
(JSC::VM::dumpSampleData): Deleted.
* runtime/VM.h:
(JSC::VM::regExpCache):
* testRegExp.cpp:
(runFromFiles):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::interpret):
2016-03-17 Saam barati <sbarati@apple.com>
[ES6] Make GetProperty(.) inside ArrayPrototype.cpp spec compatible.
https://bugs.webkit.org/show_bug.cgi?id=155575
Reviewed by Filip Pizlo and Mark Lam.
This patch makes various Array.prototype.(shift | unshift | splice)
spec compliant. Before, they were performing Get and HasProperty as one
operation. Instead, they need to be performed as two distinct operations
when it would be observable.
* runtime/ArrayPrototype.cpp:
(JSC::getProperty):
* runtime/PropertySlot.h:
(JSC::PropertySlot::PropertySlot):
(JSC::PropertySlot::isCacheableValue):
(JSC::PropertySlot::isCacheableGetter):
(JSC::PropertySlot::isCacheableCustom):
(JSC::PropertySlot::setIsTaintedByProxy):
(JSC::PropertySlot::isTaintedByProxy):
(JSC::PropertySlot::internalMethodType):
(JSC::PropertySlot::getValue):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::getOwnPropertySlotCommon):
* tests/es6.yaml:
* tests/stress/proxy-array-prototype-methods.js: Added.
(assert):
(test):
(shallowEq):
2016-03-17 Mark Lam <mark.lam@apple.com>
Make FunctionMode an enum class.
https://bugs.webkit.org/show_bug.cgi?id=155587
Reviewed by Saam Barati.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* parser/NodeConstructors.h:
(JSC::BaseFuncExprNode::BaseFuncExprNode):
(JSC::FuncExprNode::FuncExprNode):
(JSC::FuncDeclNode::FuncDeclNode):
(JSC::ArrowFuncExprNode::ArrowFuncExprNode):
(JSC::MethodDefinitionNode::MethodDefinitionNode):
* parser/ParserModes.h:
(JSC::functionNameIsInScope):
2016-03-17 Michael Saboff <msaboff@apple.com>
[ES6] Getters and Setters should be prefixed appropriately
https://bugs.webkit.org/show_bug.cgi?id=155593
Reviewed by Mark Lam.
Changed the putDirectNativeIntrinsicGetter() to prepend "get " to the funtion name.
Updated places that had their own macro or hand constructed a getter function to use
the JSC_NATIVE_GETTER macro which will properly append "get ".
Prepended "get " and "set " to the __proto__ accessor created on the Object prototype.
When we create the Symbol.species getter, added an explicit function name of "get [Symbol.species]".
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeAttributeEvaluate):
* inspector/JSJavaScriptCallFramePrototype.cpp:
(Inspector::JSJavaScriptCallFramePrototype::finishCreation):
(Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluate):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectNativeIntrinsicGetter):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
(JSC::MapPrototype::getOwnPropertySlot):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
(JSC::SetPrototype::getOwnPropertySlot):
* tests/stress/accessors-get-set-prefix.js: Added.
(tryGetOwnPropertyDescriptorGetName):
2016-03-16 Mark Lam <mark.lam@apple.com>
Method names should not appear in the lexical scope of the method's body.
https://bugs.webkit.org/show_bug.cgi?id=155568
Reviewed by Saam Barati.
Consider this scenario:
var f = "foo";
var result = ({
f() {
return f; // f should be the string "foo", not this method f.
}
}).f();
result === "foo"; // Should be true.
The reason this is not current working is because the parser does not yet
distinguish between FunctionExpressions and MethodDefinitions. The ES6 spec
explicitly distinguishes between the 2, and we should do the same.
This patch changes all methods (and getters and setters which are also methods)
to have a FunctionMode of MethodDefinition (instead of FunctionExpression).
functionNameIsInScope() is responsible for determining whether a function's name
should be in its scope or not. It already returns false for any function
whose FunctionMode is not FunctionExpression. Giving methods the MethodDefinition
FunctionMode gets us the correct behavior ES6 expects.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
(JSC::BytecodeGenerator::emitNewMethodDefinition):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrowFuncExprNode::emitBytecode):
(JSC::MethodDefinitionNode::emitBytecode):
(JSC::YieldExprNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionExpr):
(JSC::ASTBuilder::createMethodDefinition):
(JSC::ASTBuilder::createFunctionMetadata):
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createArguments):
* parser/NodeConstructors.h:
(JSC::FunctionParameters::FunctionParameters):
(JSC::BaseFuncExprNode::BaseFuncExprNode):
(JSC::FuncExprNode::FuncExprNode):
(JSC::FuncDeclNode::FuncDeclNode):
(JSC::ArrowFuncExprNode::ArrowFuncExprNode):
(JSC::MethodDefinitionNode::MethodDefinitionNode):
(JSC::YieldExprNode::YieldExprNode):
* parser/Nodes.h:
(JSC::BaseFuncExprNode::metadata):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parsePropertyMethod):
* parser/ParserModes.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionExpr):
(JSC::SyntaxChecker::createFunctionMetadata):
(JSC::SyntaxChecker::createArrowFunctionExpr):
(JSC::SyntaxChecker::createMethodDefinition):
(JSC::SyntaxChecker::setFunctionNameStart):
(JSC::SyntaxChecker::createArguments):
* tests/es6.yaml:
2016-03-17 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION(r197380): Build fails with new GCC and Clang
https://bugs.webkit.org/show_bug.cgi?id=155044
Reviewed by Michael Catanzaro.
In C++, std math functions ceil and floor are overloaded for double and float.
Without explicit cast or function pointer assignment, compilers cannot
determine which function address is used in the given context.
* b3/B3LowerMacrosAfterOptimizations.cpp:
2016-03-17 Skachkov Oleksandr <gskachkov@gmail.com>
Invoking super()/super inside of the eval should not lead to SyntaxError
https://bugs.webkit.org/show_bug.cgi?id=153864
Reviewed by Saam Barati.
Added support of the invoking super/super() inside of the eval within class.
Also support cases when eval is invoked in constructor, class method directly
or via arrow function. Access to the new.target in eval is not part of this patch
and will be implemented in https://bugs.webkit.org/show_bug.cgi?id=155545
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isSuperCallUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
* interpreter/Interpreter.cpp:
(JSC::eval):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::isEvalContext):
(JSC::Scope::setIsEvalContext):
(JSC::parse):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
* tests/stress/arrowfunction-lexical-bind-supercall-4.js:
* tests/stress/arrowfunction-lexical-bind-superproperty.js:
* tests/stress/class-syntax-super-in-eval.js: Added.
* tests/stress/generator-with-super.js:
2016-03-15 Filip Pizlo <fpizlo@apple.com>
ASSERTION FAILED: !edge->isPhantomAllocation() in regress/script-tests/sink-huge-activation.js.ftl-eager in debug mode
https://bugs.webkit.org/show_bug.cgi?id=153805
Reviewed by Mark Lam.
The object allocation sinking phase uses InferredValue::isStillValid() in the opposite
way from most clients: it will do an *extra* optimization if it returns false. The
phase will first compute sink candidates and then it will compute materialization
points. If something is a sink candidate then it is not a materialization point. A
NewFunction node may appear as not being a sink candidate during the first pass, so it's
not added to the set of things that will turn into PhantomNewFunction. But on the second
pass where we add materializations, we check isStillValid() again. Now this may become
false, so that second pass thinks that NewFunction is a sink candidate (even though it's
not in the sink candidates set) and so is not a materialization point.
This manifests as the NewFunction referring to a PhantomCreateActivation or whatever.
The solution is to have the phase cache results of calls to isStillValid(). It's OK if
we just remember the result of the first call and assume that it's not a sink candidate.
That's the worst that can happen.
No new tests since this is a super hard race and sink-huge-activation seemed to already
be catching it.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
2016-03-16 Saam Barati <sbarati@apple.com>
[ES6] Make Array.prototype.reverse spec compatible.
https://bugs.webkit.org/show_bug.cgi?id=155528
Reviewed by Michael Saboff.
This patch make Array.prototype.reverse spec compatible.
Before, we weren't performing a HasProperty of each index
before performing a Get on that index. We now do that on
the slow path.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncReverse):
* tests/stress/array-reverse-proxy.js: Added.
(assert):
(test):
(shallowCopy):
(shallowEqual):
(let.handler.get getSet):
(test.let.handler.get getSet):
2016-03-16 Chris Dumez <cdumez@apple.com>
Unreviewed, rolling out r198235, r198240, r198241, and
r198252.
Causing crashes on ARM
Reverted changesets:
"Remove compile time define for SEPARATED_HEAP"
https://bugs.webkit.org/show_bug.cgi?id=155508
http://trac.webkit.org/changeset/198235
"Gardening: build fix after r198235."
http://trac.webkit.org/changeset/198240
"Build fix."
http://trac.webkit.org/changeset/198241
"Rename performJITMemcpy to something more inline with our
normal webkit function names"
https://bugs.webkit.org/show_bug.cgi?id=155525
http://trac.webkit.org/changeset/198252
2016-03-16 Brian Burg <bburg@apple.com>
Unreviewed, rolling out r198257.
https://bugs.webkit.org/show_bug.cgi?id=155553
This change is unnecessary, clients can instead compile the
file with ARC enabled (Requested by brrian on #webkit).
Reverted changeset:
"REGRESSION(r198077): generated Objective-C protocol object
getters leak their wrappers"
https://bugs.webkit.org/show_bug.cgi?id=155523
http://trac.webkit.org/changeset/198257
2016-03-16 Mark Lam <mark.lam@apple.com>
Add support for setting Function.name from computed properties.
https://bugs.webkit.org/show_bug.cgi?id=155437
Reviewed by Filip Pizlo.
In JS code, we can have initialization of computed properties with function and
class objects e.g.
var o = {
[x]: function() {},
[y]: class {}
}
The ES6 spec states that the function and class in the example above (being
anonymous) should take on the value of x and y respectively as their names:
o[x].name; // should be the "stringified" value of x.
o[y].name; // should be the "stringified" value of y.
To achieve this, we will now inject an op_set_function_name bytecode at property
initialization sites if:
1. the property assigned value is a function or class, and
2. the function and class is anonymous, and
3. if property assigned value is a class, it doesn't have a static method
that is statically named "name".
The op_set_function_name will result in JSFunction::setFunctionName() being
called on the target function / class before it is assigned to the property.
JSFunction::setFunctionName() will take care of:
1. computing the name to use from the value of the computed property name
e.g. x and y in the example above.
If the computed property name is not a symbol, then the function / class name
should be the toString() value of that computed property name.
If the computed property name is a symbol, then ...
a. if the Symbol has a defined description (e.g. Symbol("foo")), then the
function / class name should be "[<symbol description>]" e.g. "[foo]".
b. if the Symbol has an undefined description (e.g. Symbol()), then the
function / class name should be "".
Note: Symbol("") is not the same as Symbol(). The former has a defined
descriptor "", and hence, yields a function / class name of "[]". The latter
yields a function / class name of "".
2. reifying the lazy name property with this function / class name.
op_set_function_name is named after the SetFunctionName internal function
in the ES6 spec that performs the above operation.
It is behaviorally correct to use op_set_function_name at every property
initialization site with computed property names. However, we choose to not
emit the op_set_function_name bytecode when we already know that it will do
nothing i.e. when the target function / class is proven to already have a name or
name property. This is done as an optimization to avoid unnecessary calls to
JSFunction::setFunctionName().
Note: we could further check if the class has a static method with a computed
name that is a constant string "name" and elide op_set_function_name there too.
However, we don't bother because this should be rare. JSFunction::setFunctionName()
will still do the right thing.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewFunction):
(JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
(JSC::BytecodeGenerator::emitCall):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitBytecode):
(JSC::PropertyListNode::emitPutConstantProperty):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunction):
(JSC::DFG::SpeculativeJIT::compileSetFunctionName):
(JSC::DFG::SpeculativeJIT::compileForwardVarargs):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
(JSC::FTL::DFG::LowerDFGToB3::compileSetFunctionName):
(JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_strcat):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emitSlow_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_strcat):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::handleHostCall):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* parser/Nodes.cpp:
(JSC::FunctionNode::finishParsing):
(JSC::PropertyListNode::hasStaticallyNamedProperty):
(JSC::VariableEnvironmentNode::VariableEnvironmentNode):
* parser/Nodes.h:
* runtime/JSFunction.cpp:
(JSC::getCalculatedDisplayName):
(JSC::JSFunction::setFunctionName):
(JSC::JSFunction::reifyLength):
(JSC::JSFunction::reifyName):
* runtime/JSFunction.h:
* tests/es6.yaml:
* tests/stress/computed-function-names.js: Added.
(toKeyString):
(toFuncName):
(shouldBe):
(return.propKey):
2016-03-16 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Reflect.set with receiver
https://bugs.webkit.org/show_bug.cgi?id=155294
Reviewed by Saam Barati.
This patch introduces the receiver parameter support for Reflect.set.
Reflect.set can alter the receiver with arbitrary values.
Each property descriptor uses the receiver in [[Set]].
1) In the accessor descriptor case, the receiver is used as |this| value for setter calls.
2) In the data descriptor case, the actual property will be set onto the receiver objects.
The current put operation does not support the receiver that is different from the base object.
In particular, (2) case is not supported.
The naive implementation adds one more [[GetOwnProperty]] for the receiver per [[Set]] (9.1.9.1-4-c [1]), and it is unacceptable.
To keep the fast path efficiently, we fall back to the slow but generic implementation (ordinarySetSlow)
only when the receiver is altered.
We need not to change any JIT part, because the JS code cannot alter the receiver without Reflect.set.
The property accesses generated by the JIT code always have the receiver that is the same to the base object.
ProxyObject can alter the receiver, but this situation has no problem because ProxyObject disables Inline Caching.
NOTE: Generating Inline Caching for JSProxy (that is used for the Window proxy) is already disabled before this change.
[1]: https://tc39.github.io/ecma262/#sec-ordinaryset
* jsc.cpp:
(functionCreateProxy):
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::put):
* runtime/JSArray.cpp:
(JSC::JSArray::put):
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::put):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::put):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::isThisValueAltered):
* runtime/JSDataView.cpp:
(JSC::JSDataView::put):
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::put):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::put):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::putInlineSlow):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::putInline):
* runtime/JSProxy.h:
(JSC::JSProxy::createStructure):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/PropertySlot.h:
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::put):
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
(JSC::PutPropertySlot::isCacheablePut):
(JSC::PutPropertySlot::isCacheableSetter):
(JSC::PutPropertySlot::isCacheableCustom):
(JSC::PutPropertySlot::isCustomAccessor):
(JSC::PutPropertySlot::disableCaching):
(JSC::PutPropertySlot::isCacheable):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectSet):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::put):
(JSC::reject): Deleted.
* runtime/StringObject.cpp:
(JSC::StringObject::put):
* tests/es6.yaml:
* tests/stress/ordinary-set-exceptions.js: Added.
(shouldBe):
(shouldThrow):
(shouldThrow.set get var):
* tests/stress/proxy-set.js:
* tests/stress/reflect-set-proxy-set.js: Copied from Source/JavaScriptCore/tests/stress/proxy-set.js.
(shouldBe):
(unreachable):
(assert):
(throw.new.Error.let.handler.set 45):
(throw.new.Error):
(let.target.set x):
(let.target.get x):
(set let):
* tests/stress/reflect-set-receiver-proxy-set.js: Added.
(shouldBe):
(unreachable):
(assert):
(let.handler.set 45):
(catch):
(let.target.set x):
(let.target.get x):
(set let):
* tests/stress/reflect-set-with-global-proxy.js: Added.
(shouldBe):
(unreachable):
(get shouldBe):
(set shouldBe):
(set test1):
(set test2):
(set test3):
* tests/stress/reflect-set.js:
(shouldThrow):
(unreachable):
(get shouldBe):
(set shouldBe):
(receiverTestIndexed):
(set get Uint8Array):
(receiverCase): Deleted.
(proxyCase): Deleted.
(stringObjectCase.set get shouldBe): Deleted.
(regExpLastIndex): Deleted.
2016-03-15 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove hint from SlowCaseEntry
https://bugs.webkit.org/show_bug.cgi?id=155530
Reviewed by Alex Christensen.
* jit/JIT.h:
(JSC::SlowCaseEntry::SlowCaseEntry):
2016-03-15 Brian Burg <bburg@apple.com>
REGRESSION(r198077): generated Objective-C protocol object getters leak their wrappers
https://bugs.webkit.org/show_bug.cgi?id=155523
<rdar://problem/25181764>
Reviewed by Joseph Pecoraro.
Since the code may not be compiled with ARC, autorelease the returned wrapper.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.protocol_to_objc_expression_for_member):
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-03-15 Benjamin Poulain <bpoulain@apple.com>
[JSC] Help clang generate better code on arrayProtoFuncToString()
https://bugs.webkit.org/show_bug.cgi?id=155512
Reviewed by Mark Lam.
3d-raytrace hits Array.toString() hard with small arrays.
Half of the time is going into overhead around the StringJoiner.
This patch makes the function shorter and the layout better.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncToString):
Add "UNLIKELY" on rare cases. Clang pushes that code to the tail.
Factor the code of jsMakeNontrivialString() so that the operation
is not duplicated in the function.
* runtime/JSStringBuilder.h:
(JSC::jsMakeNontrivialString):
jsNontrivialString() supports r-value reference.
Move the result string into jsNontrivialString(), this removes
the deref+destructor from the function.
* runtime/JSStringJoiner.cpp:
(JSC::JSStringJoiner::~JSStringJoiner):
The destructor is pretty large. No point in inlining it.
(JSC::joinStrings):
* runtime/JSStringJoiner.h:
(JSC::JSStringJoiner::JSStringJoiner):
(JSC::JSStringJoiner::append):
The calls were duplicated. That's unnecessary.
* runtime/NumericStrings.h:
(JSC::NumericStrings::add):
Return a reference in all cases.
This removes a deref+destructor.
2016-03-15 Joseph Pecoraro <pecoraro@apple.com>
Remove stale ArrayPrototype declarations
https://bugs.webkit.org/show_bug.cgi?id=155520
Reviewed by Mark Lam.
* runtime/ArrayPrototype.cpp:
The implementations went away when the methods were moved to builtins
but the declarations were left behind.
2016-03-15 Oliver Hunt <oliver@apple.com>
Rename performJITMemcpy to something more inline with our normal webkit function names
https://bugs.webkit.org/show_bug.cgi?id=155525
Reviewed by Saam Barati.
Simple bulk search/replace with a better name.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::fillNops):
(JSC::ARM64Assembler::replaceWithJump):
(JSC::ARM64Assembler::replaceWithLoad):
(JSC::ARM64Assembler::replaceWithAddressComputation):
(JSC::ARM64Assembler::setPointer):
(JSC::ARM64Assembler::repatchInt32):
(JSC::ARM64Assembler::repatchCompact):
(JSC::ARM64Assembler::linkJumpOrCall):
(JSC::ARM64Assembler::linkCompareAndBranch):
(JSC::ARM64Assembler::linkConditionalBranch):
(JSC::ARM64Assembler::linkTestAndBranch):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
* jit/ExecutableAllocator.h:
(JSC::writeToExecutableRegion):
(JSC::performJITMemcpy): Deleted.
2016-03-15 Oliver Hunt <oliver@apple.com>
Build fix.
* jit/ExecutableAllocatorFixedVMPool.cpp:
2016-03-15 Mark Lam <mark.lam@apple.com>
Gardening: build fix after r198235.
Not Reviewed.
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
2016-03-15 Oliver Hunt <oliver@apple.com>
Remove compile time define for SEPARATED_HEAP
https://bugs.webkit.org/show_bug.cgi?id=155508
Reviewed by Mark Lam.
This removes the compile time define for the SEPARATED_HEAP
feature, and moves to a default-off runtime preference.
This happily also removes the need for world rebuilds while
bringing it up on different platforms.
* Configurations/FeatureDefines.xcconfig:
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
(JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
(JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion):
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Deleted.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2016-03-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r198148.
https://bugs.webkit.org/show_bug.cgi?id=155518
"Lets do this patch at a later time" (Requested by saamyjoon
on #webkit).
Reverted changeset:
"[ES6] Disallow var assignments in for-in loops"
https://bugs.webkit.org/show_bug.cgi?id=155451
http://trac.webkit.org/changeset/198148
2016-03-15 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION: ASSERTION FAILED: !m_lastActiveBlock on js/function-apply.html
https://bugs.webkit.org/show_bug.cgi?id=155411
<rdar://problem/25134537>
Reviewed by Mark Lam.
* heap/Heap.cpp:
(JSC::Heap::collectImpl):
(JSC::Heap::didFinishCollection):
During collection allocators are stop/reset. The HeapProfiler tasks
were using HeapIterationScope (to satisfy MarkedSpace forEachCell API
contracts) which was doing its own stop/resume of allocators. Doing a
stop/resume in between the normal stop/reset of collection is unexpected.
Move this to didFinishCollection, alongside other heap iterations
like zombies and immortal objects. Putting this after those tasks
also means the heap snapshots will respect the zombies/immortal options
when deciding if the cell is alive or not.
2016-03-15 Saam Barati <sbarati@apple.com>
We should have different JSTypes for JSGlobalLexicalEnvironment and JSLexicalEnvironment and JSModuleEnvironment
https://bugs.webkit.org/show_bug.cgi?id=152406
Reviewed by Mark Lam.
This makes testing for a JSGlobalLexicalEnvironment faster
because we can just check the Cell's type instead of using
jsDynamicCast. I also changed code that does jsDynamicCast<JSGlobalObject*>
instead of isGlobalObject().
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/JSGlobalLexicalEnvironment.h:
(JSC::JSGlobalLexicalEnvironment::createStructure):
* runtime/JSLexicalEnvironment.h:
(JSC::JSLexicalEnvironment::createStructure):
(JSC::JSLexicalEnvironment::JSLexicalEnvironment):
* runtime/JSModuleEnvironment.h:
(JSC::JSModuleEnvironment::createStructure):
(JSC::JSModuleEnvironment::offsetOfModuleRecord):
* runtime/JSObject.h:
(JSC::JSObject::isGlobalObject):
(JSC::JSObject::isJSLexicalEnvironment):
(JSC::JSObject::isGlobalLexicalEnvironment):
(JSC::JSObject::isErrorInstance):
* runtime/JSScope.cpp:
(JSC::abstractAccess):
(JSC::isUnscopable):
(JSC::JSScope::resolve):
(JSC::JSScope::collectVariablesUnderTDZ):
(JSC::JSScope::isVarScope):
(JSC::JSScope::isLexicalScope):
(JSC::JSScope::isModuleScope):
(JSC::JSScope::isCatchScope):
(JSC::JSScope::isFunctionNameScopeObject):
(JSC::JSScope::isNestedLexicalScope):
(JSC::JSScope::constantScopeForCodeBlock):
(JSC::isScopeType): Deleted.
(JSC::JSScope::isGlobalLexicalEnvironment): Deleted.
* runtime/JSScope.h:
* runtime/JSType.h:
2016-03-15 Filip Pizlo <fpizlo@apple.com>
Remove the Baker barrier from JSC
https://bugs.webkit.org/show_bug.cgi?id=155479
Reviewed by Saam Barati.
It's been a while since I added a Baker barrier, but I never followed it up with an actual
concurrent GC. While thinking about the GC, I became convinced that the right path forward
is to do a non-copying concurrent GC. That is, remove the copied space and just use the
marked space. The downside of using marked space cannot be more than the overhead of the
Baker barrier, so concurrent non-copying GC is definitely better than copying
non-concurrent GC. I also suspect that just plain non-copying non-concurrent GC is going to
be fine also, so the path forward will probably be to first just remove CopiedSpace.
Anyway, for now this patch just removes the Baker barrier. It was a cute implementation but
it just cost performance and I don't think we'll ever use it.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGCopyBarrierOptimizationPhase.cpp: Removed.
* dfg/DFGCopyBarrierOptimizationPhase.h: Removed.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
(JSC::DFG::SpeculativeJIT::compileGetButterfly):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetButterfly):
(JSC::FTL::DFG::LowerDFGToB3::compileConstantStoragePointer):
(JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckArray):
(JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
(JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
(JSC::FTL::DFG::LowerDFGToB3::getById):
(JSC::FTL::DFG::LowerDFGToB3::isFastTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::compileGetButterflyReadOnly): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::loadButterflyWithBarrier): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::loadVectorWithBarrier): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::copyBarrier): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::isInToSpace): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::loadButterflyReadOnly): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::loadVectorReadOnly): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::removeSpaceBits): Deleted.
* heap/CopyBarrier.h:
(JSC::CopyBarrierBase::CopyBarrierBase):
(JSC::CopyBarrierBase::operator bool):
(JSC::CopyBarrierBase::get):
(JSC::CopyBarrierBase::clear):
(JSC::CopyBarrierBase::setWithoutBarrier):
(JSC::CopyBarrier::CopyBarrier):
(JSC::CopyBarrier::get):
(JSC::CopyBarrier::set):
(JSC::CopyBarrier::setWithoutBarrier):
(JSC::CopyBarrierBase::operator!): Deleted.
(JSC::CopyBarrierBase::getWithoutBarrier): Deleted.
(JSC::CopyBarrierBase::getPredicated): Deleted.
(JSC::CopyBarrierBase::copyState): Deleted.
(JSC::CopyBarrierBase::setCopyState): Deleted.
(JSC::CopyBarrierBase::weakCASWithoutBarrier): Deleted.
(JSC::CopyBarrier::getWithoutBarrier): Deleted.
(JSC::CopyBarrier::getPredicated): Deleted.
(JSC::CopyBarrier::weakCASWithoutBarrier): Deleted.
* heap/Heap.cpp:
(JSC::Heap::addToRememberedSet):
(JSC::Heap::collectAndSweep):
(JSC::Heap::copyBarrier): Deleted.
* heap/Heap.h:
(JSC::Heap::writeBarrierBuffer):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::branchIfNotFastTypedArray):
(JSC::AssemblyHelpers::purifyNaN):
(JSC::AssemblyHelpers::loadTypedArrayVector): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchStructure):
(JSC::AssemblyHelpers::addressForByteOffset):
(JSC::AssemblyHelpers::branchIfToSpace): Deleted.
(JSC::AssemblyHelpers::branchIfNotToSpace): Deleted.
(JSC::AssemblyHelpers::removeSpaceBits): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompile):
* jit/JITOpcodes.cpp:
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emitSlow_op_get_direct_pname):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emitSlow_op_get_direct_pname):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitDoubleLoad):
(JSC::JIT::emitContiguousLoad):
(JSC::JIT::emitArrayStorageLoad):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/DirectArguments.cpp:
(JSC::DirectArguments::visitChildren):
(JSC::DirectArguments::copyBackingStore):
(JSC::DirectArguments::overrideArgument):
(JSC::DirectArguments::copyToArguments):
* runtime/DirectArguments.h:
(JSC::DirectArguments::canAccessIndexQuickly):
(JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG):
* runtime/JSArray.cpp:
(JSC::JSArray::setLength):
(JSC::JSArray::pop):
(JSC::JSArray::push):
(JSC::JSArray::fastSlice):
(JSC::JSArray::fastConcatWith):
(JSC::JSArray::shiftCountWithArrayStorage):
(JSC::JSArray::shiftCountWithAnyIndexingType):
(JSC::JSArray::unshiftCountWithAnyIndexingType):
(JSC::JSArray::fillArgList):
(JSC::JSArray::copyToArguments):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::finalize):
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::isNeutered):
(JSC::JSArrayBufferView::vector):
(JSC::JSArrayBufferView::length):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
(JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
* runtime/JSObject.cpp:
(JSC::JSObject::visitChildren):
(JSC::JSObject::copyBackingStore):
(JSC::JSObject::heapSnapshot):
(JSC::JSObject::getOwnPropertySlotByIndex):
(JSC::JSObject::putByIndex):
(JSC::JSObject::enterDictionaryIndexingMode):
(JSC::JSObject::createInitialIndexedStorage):
(JSC::JSObject::createArrayStorage):
(JSC::JSObject::convertUndecidedToInt32):
(JSC::JSObject::convertUndecidedToDouble):
(JSC::JSObject::convertUndecidedToContiguous):
(JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
(JSC::JSObject::convertUndecidedToArrayStorage):
(JSC::JSObject::convertInt32ToDouble):
(JSC::JSObject::convertInt32ToContiguous):
(JSC::JSObject::convertInt32ToArrayStorage):
(JSC::JSObject::convertDoubleToContiguous):
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
(JSC::JSObject::setIndexQuicklyToUndecided):
(JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
(JSC::JSObject::deletePropertyByIndex):
(JSC::JSObject::getOwnPropertyNames):
(JSC::JSObject::putIndexedDescriptor):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
(JSC::JSObject::putDirectIndexBeyondVectorLength):
(JSC::JSObject::getNewVectorLength):
(JSC::JSObject::ensureLengthSlow):
(JSC::JSObject::reallocateAndShrinkButterfly):
(JSC::JSObject::growOutOfLineStorage):
(JSC::getBoundSlotBaseFunctionForGetterSetter):
(JSC::JSObject::getEnumerableLength):
* runtime/JSObject.h:
(JSC::JSObject::getArrayLength):
(JSC::JSObject::getVectorLength):
(JSC::JSObject::canGetIndexQuickly):
(JSC::JSObject::getIndexQuickly):
(JSC::JSObject::tryGetIndexQuickly):
(JSC::JSObject::canSetIndexQuickly):
(JSC::JSObject::canSetIndexQuicklyForPutDirect):
(JSC::JSObject::setIndexQuickly):
(JSC::JSObject::initializeIndex):
(JSC::JSObject::hasSparseMap):
(JSC::JSObject::inSparseIndexingMode):
(JSC::JSObject::inlineStorage):
(JSC::JSObject::butterfly):
(JSC::JSObject::outOfLineStorage):
(JSC::JSObject::locationForOffset):
(JSC::JSObject::ensureInt32):
(JSC::JSObject::ensureDouble):
(JSC::JSObject::ensureContiguous):
(JSC::JSObject::ensureArrayStorage):
(JSC::JSObject::arrayStorage):
(JSC::JSObject::arrayStorageOrNull):
(JSC::JSObject::ensureLength):
(JSC::JSObject::putDirectWithoutTransition):
* runtime/MapData.h:
(JSC::JSIterator>::IteratorData::next):
(JSC::JSIterator>::IteratorData::refreshCursor):
* runtime/MapDataInlines.h:
(JSC::JSIterator>::find):
(JSC::JSIterator>::add):
(JSC::JSIterator>::remove):
(JSC::JSIterator>::replaceAndPackBackingStore):
(JSC::JSIterator>::replaceBackingStore):
(JSC::JSIterator>::ensureSpaceForAppend):
(JSC::JSIterator>::visitChildren):
(JSC::JSIterator>::copyBackingStore):
* runtime/Options.h:
2016-03-15 Saam barati <sbarati@apple.com>
Destructuring parameters are evaluated in the wrong scope
https://bugs.webkit.org/show_bug.cgi?id=155454
Reviewed by Geoffrey Garen.
This patch makes our engine compatible with how parameter
lists are evaluated in ES6. A parameter list that contains
a rest parameter, any destructuring patterns, or default parameter values,
is classified as being non-simple. Non-simple parameter lists
must get their own scope to live in, and the variables in the
scope are under TDZ. This means that functions evaluated in the
parameter list don't have access to variables inside the function
body. Also, non-simple parameter lists get the strict-mode arguments object.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::~BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
* bytecompiler/BytecodeGenerator.h:
* parser/Nodes.h:
(JSC::FunctionParameters::size):
(JSC::FunctionParameters::at):
(JSC::FunctionParameters::append):
(JSC::FunctionParameters::hasDefaultParameterValues): Deleted.
* tests/es6.yaml:
* tests/stress/parameter-scoping.js: Added.
(assert):
(test):
(test.foo):
(test.):
2016-03-14 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Don't reference the properties of @Reflect directly
https://bugs.webkit.org/show_bug.cgi?id=155436
Reviewed by Geoffrey Garen.
Reflect.ownKeys and Reflect.getOwnPropertyDescriptor can be altered with the user-crafted values.
Instead of referencing them directly, let's reference them through private names.
* builtins/ObjectConstructor.js:
(assign):
* runtime/CommonIdentifiers.h:
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation): Deleted.
* runtime/ReflectObject.cpp:
(JSC::ReflectObject::finishCreation):
* tests/stress/object-assign-correctness.js:
(runTests.):
(runTests.get let):
(Reflect.ownKeys):
(Reflect.getOwnPropertyDescriptor):
(test.let.handler.switch.case.string_appeared_here.return.get enumerable): Deleted.
(test.let.handler.getOwnPropertyDescriptor): Deleted.
(test.let.handler.ownKeys): Deleted.
(test.let.handler.get getProps): Deleted.
(test.let.handler): Deleted.
(test): Deleted.
2016-03-14 Daniel Bates <dabates@apple.com>
Web Inspector: Display Content Security Policy hash in details sidebar for script and style elements
https://bugs.webkit.org/show_bug.cgi?id=155466
<rdar://problem/25152480>
Reviewed by Joseph Pecoraro and Timothy Hatcher.
Add property contentSecurityPolicyHash to store the CSP hash for an HTML style element or an
applicable HTML script element.
* inspector/protocol/DOM.json:
2016-03-14 Joonghun Park <jh718.park@samsung.com>
Purge PassRefPtr from ArrayBuffer, ArchiveResource, Pasteboard, LegacyWebArchive and DataObjectGtk
https://bugs.webkit.org/show_bug.cgi?id=150497
Reviewed by Darin Adler.
* runtime/ArrayBuffer.h:
(JSC::ArrayBuffer::create):
(JSC::ArrayBuffer::createAdopted):
(JSC::ArrayBuffer::createFromBytes):
(JSC::ArrayBuffer::createUninitialized):
(JSC::ArrayBuffer::slice):
(JSC::ArrayBuffer::sliceImpl):
2016-03-14 Benjamin Poulain <bpoulain@apple.com>
Andy VanWagoner no longer has time to own Intl
* features.json:
Andy is busy with other things.
Andy, thanks for your amazing work on Intl and your dedication
to making things right.
2016-03-14 Julien Brianceau <jbriance@cisco.com>
[mips] Fix unaligned access in LLINT.
https://bugs.webkit.org/show_bug.cgi?id=153228
Address loads used with btbxx opcodes were wrongly converted to lw
instruction instead of lbu, leading to unaligned access on mips
platforms. This is not a bug as it's silently fixed up by kernel,
but it's more efficient to avoid unaligned accesses for mips.
Reviewed by Geoffrey Garen.
* offlineasm/mips.rb:
2016-03-14 Filip Pizlo <fpizlo@apple.com>
REGRESSION(r194394): >2x slow-down on CDjs
https://bugs.webkit.org/show_bug.cgi?id=155471
Unreviewed (rollout).
This revision changes localeCompare() so that it's *much* slower than before. It's
understandable that sometimes things will get a tiny bit slower when implementing new
language features, but more than 2x regression on a major benchmark is not OK.
This rolls out that change. We can reland it once we think about how to do it in a
performant way.
* builtins/StringPrototype.js:
(search):
(localeCompare): Deleted.
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
2016-03-14 Mark Lam <mark.lam@apple.com>
Need to distinguish between Symbol() and Symbol("").
https://bugs.webkit.org/show_bug.cgi?id=155438
Reviewed by Saam Barati.
* runtime/PrivateName.h:
(JSC::PrivateName::PrivateName):
2016-03-14 Oliver Hunt <oliver@apple.com>
Temporarily disable the separated heap.
https://bugs.webkit.org/show_bug.cgi?id=155472
Reviewed by Geoffrey Garen.
Temporarily disable this.
* Configurations/FeatureDefines.xcconfig:
2016-03-14 Joseph Pecoraro <pecoraro@apple.com>
Reduce generated JSON HeapSnapshot size
https://bugs.webkit.org/show_bug.cgi?id=155460
Reviewed by Geoffrey Garen.
Adjust the HeapSnapshot JSON to better reduce its size.
Changes include:
- avoid inner array groups and instead just have a large array for
nodes/edges. This removes lots of small array allocations.
- eliminate duplicate edges
- avoid duplicating edge names by including them in their own table;
- now both the nodes and edges lists hold only integers
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json):
Add some more documentation for the slightly modified format.
While generating, clear data structures as early as possible.
* heap/HeapSnapshotBuilder.h:
(JSC::HeapSnapshotEdge::HeapSnapshotEdge):
During JSON building, the edge's cell pointers are converted to the
identifier they point to. This avoids having to re-lookup the identifier.
* tests/heapProfiler/driver/driver.js:
(CheapHeapSnapshotEdge):
(CheapHeapSnapshot):
(CheapHeapSnapshot.prototype.edgeNameFromTableIndex):
(HeapSnapshot):
Update test driver for slightly different snapshot format.
2016-03-14 Keith Miller <keith_miller@apple.com>
We should be able to eliminate cloned arguments objects that use the length property
https://bugs.webkit.org/show_bug.cgi?id=155391
Reviewed by Geoffrey Garen.
Previously if a programmer tried to use arguments.length in a strict function we would not eliminate the
arguments object. We were unable to eliminate the arguments object because the user would get a cloned arguments
object, which does not special case the length property. Thus, in order to get arguments elimination for cloned
we need to add a special case. There are two things that need to happen for the elimination to succeed.
First, we need to eliminate the CheckStructure blocking the GetByOffset for the length property. In order to
eliminate the check structure we need to prove to the Abstract Interpreter that this structure check is
unnesssary. This didn't occur before for two reasons: 1) CreateClonedArguments did not set the structure it
produced. 2) Even if CreateClonedArguments provided the global object's cloned arguments structure we would
transition the new argements object when we added the length property during construction. To fix the second
problem we now pre-assign a slot on clonedArgumentsStructure for the length property. Additionally, in order to
prevent future transitions of the structure we need to choose an indexing type for the structure. Since, not
eliminating the arguments object is so expensive we choose to have all cloned arguments start with continuous
indexing type, this avoids transitioning when otherwise we would not have to. In the future we should be smarter
about choosing the indexing type but since its relatively rare to have a arguments object escape we don't worry
about this for now.
Additionally, this patch renames all former references of outOfBandArguments to clonedArguments and adds
extra instrumentation to DFGArgumentsEliminationPhase.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::clonedArgumentsThatWereNotCreated):
(JSC::ValueRecovery::outOfBandArgumentsThatWereNotCreated): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::tryToSetConstantRecovery):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_cloned_arguments):
(JSC::JIT::emit_op_create_out_of_band_arguments): Deleted.
* llint/LowLevelInterpreter.asm:
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::ClonedArguments):
(JSC::ClonedArguments::createEmpty):
(JSC::ClonedArguments::createWithInlineFrame):
(JSC::ClonedArguments::createByCopyingFrom):
(JSC::ClonedArguments::createStructure):
* runtime/ClonedArguments.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::clonedArgumentsStructure):
(JSC::JSGlobalObject::outOfBandArgumentsStructure): Deleted.
2016-03-14 Saam barati <sbarati@apple.com>
[ES6] Make JSON.stringify ES6 compatible
https://bugs.webkit.org/show_bug.cgi?id=155448
Reviewed by Sam Weinig and Mark Lam.
We weren't following the spec with respect to the "toJSON" property
of the thing being stringified. We were perform hasProperty(.)
on "toJSON" instead of get(.). This patch changes it our
implementation to perform get(value, "toJSON").
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::isFunction):
(JSC::JSValue::isCallable):
* runtime/JSONObject.cpp:
(JSC::Stringifier::toJSON):
(JSC::Stringifier::toJSONImpl):
(JSC::Stringifier::appendStringifiedValue):
* tests/es6.yaml:
* tests/stress/proxy-json.js:
(test):
(test.let.handler.get assert):
(test.let.handler):
2016-03-14 Saam barati <sbarati@apple.com>
[ES6] Disallow var assignments in for-in loops
https://bugs.webkit.org/show_bug.cgi?id=155451
Reviewed by Mark Lam.
We're doing this in its own patch instead of the patch for https://bugs.webkit.org/show_bug.cgi?id=155384
because last time we made this change it broke some websites. Lets try making
it again because it's what the ES6 mandates. If it still breaks things we will
roll it out.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseForStatement):
2016-03-14 Saam barati <sbarati@apple.com>
assignments in for-in/for-of header not allowed
https://bugs.webkit.org/show_bug.cgi?id=155384
Reviewed by Darin Adler.
This patch prevents assignments to the loop variable
in for in/of loops in all but one situation. The following
syntax is still allowed even though the spec prevents it:
```
for (var i = X in blah) ;
```
If the loop contains let/const, destructuring, or is a for-of
loop, we always throw a syntax error if there is an assignment.
We can do this with full backwards compatibility.
We only allow the above type of for-in loops because Oliver told
me that when he tried to make such programs illegal he ran
into real websites breaking.
This patch also removed the !::CreatesAST compile-time branch when checking
assignments to new.target. This was a dangerous thing for me
to introduce into our parser. There are times where ::CreatesAST
is true but we also want to check for syntax errors. For example,
when parsing the top-level AST of a program. Though this check
was technically correct, it's dangerous to have. It was correct
because we would always be reparsing the new.target assignment
because new.target is only allowed inside a function. That made it
so that (!::CreatesAST <=> we care about new.target assignment syntax errors).
But, (!::CreatesAST <=> we care about syntax error X) is not true in general.
I think it's safer to remove such code.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createNewTargetExpr):
(JSC::ASTBuilder::isNewTarget):
(JSC::ASTBuilder::createResolve):
* parser/Nodes.h:
(JSC::ExpressionNode::isBoolean):
(JSC::ExpressionNode::isSpreadExpression):
(JSC::ExpressionNode::isSuperNode):
(JSC::ExpressionNode::isNewTarget):
(JSC::ExpressionNode::isBytecodeIntrinsicNode):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseUnaryExpression):
2016-03-13 Joseph Pecoraro <pecoraro@apple.com>
Remove ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) guards
https://bugs.webkit.org/show_bug.cgi?id=155417
Reviewed by Yusuke Suzuki.
* Configurations/FeatureDefines.xcconfig:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parsePrimaryExpression): Deleted.
(JSC::Parser<LexerType>::parseMemberExpression): Deleted.
2016-03-13 Konstantin Tokarev <annulen@yandex.ru>
Added new port JSCOnly.
https://bugs.webkit.org/show_bug.cgi?id=154512
Reviewed by Michael Catanzaro.
This port allows to build JavaScriptCore engine with minimal
dependencies.
* PlatformJSCOnly.cmake: Added.
2016-03-12 Mark Lam <mark.lam@apple.com>
http://kangax.github.io/compat-table/esnext/ crashes reliably.
https://bugs.webkit.org/show_bug.cgi?id=155404
Reviewed by Yusuke Suzuki.
constructObjectFromPropertyDescriptor() was incorrectly assuming that either
both getter and setter will be set or unset. It did not consider that only one
of the getter or setter may be set. This patch fixes that.
* runtime/ObjectConstructor.h:
(JSC::constructObjectFromPropertyDescriptor):
* tests/stress/proxy-with-unbalanced-getter-setter.js: Added.
(assert):
(let.handler.defineProperty):
(i.):
(i.assert):
(i.get assert):
(set assert):
2016-03-12 Brian Burg <bburg@apple.com>
When generating Objective-C protocol types, getters for objects need to synthesize a new object instance
https://bugs.webkit.org/show_bug.cgi?id=155389
<rdar://problem/25125821>
Reviewed by Timothy Hatcher.
Currently, in object property getters for Objective-C protocol types, we use
a C-style cast of the member's RWIProtocolJSONObject * to the type of the property.
However, at runtime the class of `self` is going to be RWIProtocolJSONObject *,
not MemberType *, so any subsequent calls to MemberType properties on the return value
will fail as the selectors will not be recognized.
Instead of doing a C-style pointer cast, we need to create a new MemberType object
that's backed by the InspectorObject retrieved from the parent object by key.
This requires a new initWithJSONObject initializer for each object protocol type.
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator._generate_type_interface): Add new declaration.
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_json_object): Added.
Forward through to the super class initializer who assigns the underlying InspectorObject.
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
Drive-by cleanup to use the more compact [super init] form.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.protocol_to_objc_expression_for_member):
For property getters of objects, use initWithJSONObject: rather than a C-style cast.
Rebaseline relevant test results.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-03-12 Konstantin Tokarev <annulen@yandex.ru>
Removed variable names from default constructor declarations.
https://bugs.webkit.org/show_bug.cgi?id=155397
Reviewed by Mark Lam.
They carry no information and generate unused variable warning with GCC
4.8 in a lot of source files.
* parser/VariableEnvironment.h:
2016-03-12 Myles C. Maxfield <mmaxfield@apple.com>
Delete dead SVG Font code
https://bugs.webkit.org/show_bug.cgi?id=154718
Reviewed by Antti Koivisto.
* Configurations/FeatureDefines.xcconfig:
2016-03-11 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove a few jumps from DFG
https://bugs.webkit.org/show_bug.cgi?id=155347
Reviewed by Mark Lam.
Usually, setting ValueTrue or ValueFalse is set
by Compare+Or. There are 3 places in DFG with branches instead.
This patch changes them to the usual pattern.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
2016-03-11 Saam barati <sbarati@apple.com>
[ES6] Make Object.assign spec compliant
https://bugs.webkit.org/show_bug.cgi?id=155375
Reviewed by Michael Saboff.
This is a straight forward implementation of Object.assign
in the spec.
https://tc39.github.io/ecma262/#sec-object.assign
Before, weren't performing all of the specified operations.
Now, we are.
* builtins/ObjectConstructor.js:
(assign):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* tests/es6.yaml:
2016-03-11 Mark Lam <mark.lam@apple.com>
Implement Function.name and Function#toString for ES6 class.
https://bugs.webkit.org/show_bug.cgi?id=155336
Reviewed by Geoffrey Garen.
The only thing that the ES6 spec says about toString with regards to class
objects is:
"The string representation must have the syntax of a FunctionDeclaration,
FunctionExpression, GeneratorDeclaration, GeneratorExpression, ClassDeclaration,
ClassExpression, ArrowFunction, MethodDefinition, or GeneratorMethod depending
upon the actual characteristics of the object."
Previously, invoking toString() on a class object will return the function
source string of the class' constructor function. This does not conform to the
spec in that the toString string for a class does not have the syntax of a
ClassDeclaration or ClassExpression.
This is now fixed by doing the following:
1. Added "m_classSource" to FunctionExecutable (and correspondingly to
UnlinkedFunctionExecutable, FunctionMetadataNode, and ClassExprNode).
m_classSource is the SourceCode for the code range "class ... { ... }".
Since the class constructor function is the in memory representation of the
class object, only class constructor functions will have its m_classSource
set. m_classSource will be "null" (by default) for all other functions.
This is how we know if a FunctionExecutable is for a class.
Note: FunctionExecutable does not have its own m_classSource. It always gets
it from its UnlinkedFunctionExecutable. This is ok to do because our CodeCache
currently does not cache UnlinkedFunctionExecutables for class constructors.
2. The ClassExprNode now tracks the SourceCode range for the class expression.
This is used to set m_classSource in the UnlinkedFunctionExecutable at
bytecode generation time, and the FunctionExecutable later at bytecode
linking time.
3. Function.prototype.toString() now checks if the function is for a class.
If so, it returns the string for the class source instead of just the
function source for the class constructor.
Note: the class source is static from the time the class was parsed. This
can introduces some weirdness at runtime. Consider the following:
var v1 = class {}
v1.toString(); // yields "class {}".
class c2 extends v1 {}
c2.__proto__ === v1; // yields true i.e. c2 extends v1.
c2.toString(); // yields "class c2 extends v1 {}" which is fine.
v1 = {}; // point v1 to something else now.
c2.__proto__ === v1; // now yields false i.e. c2 no longer extends v1.
// c2 actually extends the class that v1 used to
// point to, but ...
c2.toString(); // still yields "class c2 extends v1 {}" which is no longer true.
It is unclear how we can best implement toString() to avoid this issue.
The above behavior is how Chrome (Version 51.0.2671.0 canary (64-bit))
currently implements toString() of a class, and we do the same in this patch.
In Firefox (45.0), toString() of a class will yield the function source of it
constructor function, which is not better.
In this patch, we also added ES6 compliance for Function.name on class objects:
4. The ClassExprNode now has a m_ecmaName string for tracking the inferred
name of a class according to the ES6 spec. The ASTBuilder now mirrors its
handling of FuncExprNodes to ClassExprNodes in setting the nodes' m_ecmaName
where relevant.
The m_ecmaName is later used to set the m_ecmaName of the FunctionExecutable
of the class constructor, which in turn is used to populate the initial value
of the Function.name property.
5. Also renamed some variable names (/m_metadata/metadata/) to be consistent with
webkit naming convention.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
(JSC::BytecodeGenerator::emitNewDefaultConstructor):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createAssignResolve):
(JSC::ASTBuilder::createYield):
(JSC::ASTBuilder::createClassExpr):
(JSC::ASTBuilder::createFunctionExpr):
(JSC::ASTBuilder::createProperty):
(JSC::ASTBuilder::makeAssignNode):
* parser/NodeConstructors.h:
(JSC::FunctionParameters::FunctionParameters):
(JSC::BaseFuncExprNode::BaseFuncExprNode):
(JSC::FuncExprNode::FuncExprNode):
(JSC::FuncDeclNode::FuncDeclNode):
(JSC::ArrowFuncExprNode::ArrowFuncExprNode):
(JSC::ClassDeclNode::ClassDeclNode):
(JSC::ClassExprNode::ClassExprNode):
* parser/Nodes.h:
(JSC::ExpressionNode::isDestructuringNode):
(JSC::ExpressionNode::isFuncExprNode):
(JSC::ExpressionNode::isArrowFuncExprNode):
(JSC::ExpressionNode::isClassExprNode):
(JSC::ExpressionNode::isCommaNode):
(JSC::ExpressionNode::isSimpleArray):
(JSC::ExpressionNode::isAdd):
* parser/Parser.cpp:
(JSC::stringForFunctionMode):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseClass):
* parser/ParserFunctionInfo.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createEmptyLetExpression):
(JSC::SyntaxChecker::createYield):
(JSC::SyntaxChecker::createClassExpr):
(JSC::SyntaxChecker::createFunctionExpr):
(JSC::SyntaxChecker::createFunctionMetadata):
(JSC::SyntaxChecker::createArrowFunctionExpr):
* runtime/Executable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::FunctionExecutable::finishCreation):
* runtime/Executable.h:
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* tests/es6.yaml:
2016-03-11 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r197994.
https://bugs.webkit.org/show_bug.cgi?id=155368
Broke several ARM tests (Requested by msaboff on #webkit).
Reverted changeset:
"[JSC] Add register reuse for ArithAdd of an Int32 and
constant in DFG"
https://bugs.webkit.org/show_bug.cgi?id=155164
http://trac.webkit.org/changeset/197994
2016-03-11 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.set without receiver support
https://bugs.webkit.org/show_bug.cgi?id=155024
Reviewed by Geoffrey Garen.
This patch implements Reflect.set.
The challenge in this patch is Reflect.set requires boolean result of [[Set]],
this is not propagated in the previous JSC put implementation.
This patch changes the put and putByIndex signature from `void put(...)` and `void putByIndex(...)` to `bool put(...)` and `bool putByIndex(...)`,
more consistent style to the ECMA262 spec's [[Set]].
This patch modifies so many part of WebKit. But almost all the changes are mechanical ones.
Currently, this patch does not support receiver modification support.
This will be supported in the subsequent patch[1].
[1]: https://bugs.webkit.org/show_bug.cgi?id=155294
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::put):
(JSC::JSCallbackObject<Parent>::putByIndex):
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::put):
* debugger/DebuggerScope.h:
* jsc.cpp:
(WTF::RuntimeArray::put):
* runtime/ClassInfo.h:
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::put):
* runtime/ClonedArguments.h:
* runtime/CustomGetterSetter.cpp:
(JSC::callCustomSetter):
* runtime/CustomGetterSetter.h:
* runtime/GenericArguments.h:
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::put):
(JSC::GenericArguments<Type>::putByIndex):
* runtime/GetterSetter.cpp:
(JSC::callSetter):
* runtime/GetterSetter.h:
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
(JSC::JSArray::put):
(JSC::JSArray::push):
* runtime/JSArray.h:
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::put):
* runtime/JSArrayBuffer.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::put):
* runtime/JSArrayBufferView.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
(JSC::JSValue::putToPrimitiveByIndex):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::put):
(JSC::JSValue::putInline):
(JSC::JSValue::putByIndex):
* runtime/JSCell.cpp:
(JSC::JSCell::put):
(JSC::JSCell::putByIndex):
* runtime/JSCell.h:
* runtime/JSDataView.cpp:
(JSC::JSDataView::put):
* runtime/JSDataView.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::put):
(JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
* runtime/JSGlobalLexicalEnvironment.cpp:
(JSC::JSGlobalLexicalEnvironment::put):
* runtime/JSGlobalLexicalEnvironment.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::put):
* runtime/JSGlobalObject.h:
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::put):
* runtime/JSLexicalEnvironment.h:
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::put):
* runtime/JSModuleEnvironment.h:
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::put):
(JSC::JSModuleNamespaceObject::putByIndex):
* runtime/JSModuleNamespaceObject.h:
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::instantiateDeclarations):
* runtime/JSObject.cpp:
(JSC::JSObject::put):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::putByIndex):
(JSC::JSObject::putGetter):
(JSC::JSObject::putSetter):
(JSC::JSObject::putDirectAccessor):
(JSC::JSObject::putDirectCustomAccessor):
(JSC::JSObject::putDirectNonIndexAccessor):
(JSC::JSObject::putIndexedDescriptor):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
(JSC::JSObject::attemptToInterceptPutByIndexOnHole):
(JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putByIndexBeyondVectorLength):
(JSC::JSObject::putDirectNativeIntrinsicGetter):
(JSC::JSObject::putDirectNativeFunction):
(JSC::JSObject::putDirectMayBeIndex):
(JSC::validateAndApplyPropertyDescriptor):
* runtime/JSObject.h:
(JSC::JSObject::putByIndexInline):
(JSC::JSObject::putDirect):
* runtime/JSObjectInlines.h:
(JSC::JSObject::putInline):
* runtime/JSProxy.cpp:
(JSC::JSProxy::put):
(JSC::JSProxy::putByIndex):
* runtime/JSProxy.h:
* runtime/JSSymbolTableObject.h:
(JSC::symbolTablePut):
(JSC::symbolTablePutTouchWatchpointSet):
(JSC::symbolTablePutInvalidateWatchpointSet):
(JSC::symbolTablePutWithAttributesTouchWatchpointSet):
* runtime/Lookup.h:
(JSC::putEntry):
(JSC::lookupPut):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::put):
(JSC::ProxyObject::putByIndexCommon):
(JSC::ProxyObject::putByIndex):
* runtime/ProxyObject.h:
* runtime/PutPropertySlot.h:
* runtime/ReflectObject.cpp:
(JSC::reflectObjectSet):
* runtime/RegExpConstructor.cpp:
(JSC::setRegExpConstructorInput):
(JSC::setRegExpConstructorMultiline):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
(JSC::regExpObjectSetLastIndexStrict):
(JSC::regExpObjectSetLastIndexNonStrict):
(JSC::RegExpObject::put):
* runtime/RegExpObject.h:
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayEntry::put):
* runtime/SparseArrayValueMap.h:
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
* runtime/StringObject.h:
* tests/es6.yaml:
* tests/modules/namespace.js:
* tests/stress/reflect-set.js: Added.
(shouldBe):
(shouldThrow):
(receiverCase.object2.set Cocoa):
(receiverCase):
(proxyCase):
(objectCase.set get shouldBe):
(objectCase.get shouldBe):
(arrayCase.set get shouldBe):
(arrayCase.get shouldBe):
(arrayBufferCase.set get shouldBe):
(arrayBufferCase.get shouldBe):
(set get shouldBe):
(get shouldBe):
(argumentCase.test1):
(argumentCase.test2):
(argumentCase.test3):
(argumentCase.test4.set get shouldBe):
(argumentCase.test5.get shouldBe):
(argumentStrictCase.test1):
(argumentStrictCase.test2):
(argumentStrictCase.test3):
(argumentStrictCase.test4.set get shouldBe):
(argumentStrictCase.test5.get shouldBe):
(stringObjectCase.set get shouldBe):
(stringObjectCase.get shouldBe):
(customSetter.test1):
(customSetter.test2):
(customSetter.test3):
(customSetter):
(regExpLastIndex):
(functionCase.func):
2016-03-10 Brian Burg <bburg@apple.com>
Web Inspector: generated initWithPayload: protocol object initializers should recursively decode array and object members
https://bugs.webkit.org/show_bug.cgi?id=155337
<rdar://problem/25098357>
Reviewed by Timothy Hatcher.
In cases where an object member is itself an object or array, we were
not calling initWithPayload: on the object member itself. So, this caused
a runtime error when constructing the outer object because the generated
code casted the NSDictionary/NSArray into the member's protocol object type.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.payload_to_objc_expression_for_member):
Do a straightforward call to initWithPayload: for objects. For arrays,
call a templated helper function which does the same thing. The helper
is used to make this array decoding fit into a single generated expression.
Rebaseline relevant test results.
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-03-10 Keith Miller <keith_miller@apple.com>
Unreviewed, fix Changelog. git merged poorly.
2016-03-10 Keith Miller <keith_miller@apple.com>
Unreviewed, fix testapi.
* API/tests/TypedArrayCTest.cpp:
(testAccess):
(testConstructors):
(forEachTypedArrayType):
(testTypedArrayCAPI):
2016-03-10 Saam barati <sbarati@apple.com>
[ES6] Make RegExp.prototype.toString spec compliant
https://bugs.webkit.org/show_bug.cgi?id=155341
Reviewed by Filip Pizlo.
Before we were directly calling into the flagsString
function. Instead, we must get the "flags" property
of the thisObject. This will usually call into the flags
getter, but not always. Specifically, you can you a Proxy
to observe this behavior.
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncToString):
(JSC::regExpProtoGetterGlobal):
* tests/es6.yaml:
* tests/es6/Proxy_internal_get_calls_RegExp.prototype.toString.js: Added.
(test.get var):
(test.):
* tests/stress/regexp-prototype-tostring.js: Added.
(assert):
(test):
(test.get var):
(test.):
(let.handler.get switch):
(let.handler):
(get test):
(test.get RegExp):
2016-03-10 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add register reuse for ArithAdd of an Int32 and constant in DFG
https://bugs.webkit.org/show_bug.cgi?id=155164
Reviewed by Geoffrey Garen.
Every "inc" in loop was looking like this:
move rX, rY
inc rY
jo 0x230f4a200580
This patch add register Reuse to that case to remove
the extra "move".
* dfg/DFGOSRExit.h:
(JSC::DFG::SpeculationRecovery::SpeculationRecovery):
(JSC::DFG::SpeculationRecovery::immediate):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithAdd):
* tests/stress/arith-add-with-constant-overflow.js: Added.
(opaqueAdd):
2016-03-10 Keith Miller <keith_miller@apple.com>
Unreviewed, build fix for r197983, hopefully.
* API/WebKitAvailability.h:
2016-03-10 Keith Miller <keith_miller@apple.com>
Typed Arrays have no public facing API
https://bugs.webkit.org/show_bug.cgi?id=120112
Reviewed by Geoffrey Garen.
This patch adds a new C-API (an Obj-C API will follow in the future) for Typed Arrays. The API has two sets of
functions. One for Typed Arrays and another for Array Buffers. This API is intended to reflect the use of Typed
Array objects in JS code. There is a method for each of the core TypedArray and Array Buffer methods.
Originally, we were planning on using a separate non-JS object as the backing store instead of a JS Array Buffer
but we decide to defer that idea since there was no good CF/NS API that met all the constraints we needed
(Discussed further below). We also wanted to want until Shared Array Buffers had reached a more finished state
to see what impact they might have on an API.
The API has the following Typed Array construction methods:
1) Create with length (the backing buffer is zero initialized). -- JSObjectMakeTypedArray
2) Create with an existing pointer and a destructor. -- JSObjectMakeTypedArrayFromBytesNoCopy
3) Create with an Array Buffer object. -- JSObjectMakeTypedArrayFromArrayBuffer
4) Create with an Array Buffer object with a given offset and length. -- JSObjectMakeTypedArrayFromArrayBufferWithOffset
The API has the following functions on Typed Array JSObjectRefs:
5) Get access to a temporary void* of the backing store's data. -- JSObjectGetTypedArrayBytesPtr
6) Get the length of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayLength
7) Get the byte length of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayByteLength
8) Get the byte offset of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayByteOffset
9) Get a Typed Array object's Array Buffer backing store. -- JSObjectGetTypedArrayBuffer
The API has the following Array Buffer construction method:
10) Create with an existing pointer and a destructor. -- JSObjectMakeArrayBufferWithBytesNoCopy
The API has the following functions on Array Buffer JSObjectRefs:
11) Get access to a temporary void* of the backing store's data. -- JSObjectGetArrayBufferBytesPtr
12) Get the byte length of an Array Buffer object (returns 0 if it is not an Array Buffer object). -- JSObjectGetArrayBufferByteLength
The API adds the following new typedefs and enumerations:
13) A typedef representing the function pointer type used to deallocate byte pointers provided to constructors. -- JSTypedArrayByesDeallocator
14) An enumeration indicating the Typed Array API type of a JSValueRef. -- JSTypedArrayType
Finally, The API has the following function to get Typed Array Types:
15) Get the Typed Array type of a JS value. -- JSValueGetTypedArrayType
There are a couple of things to note about these functions. Calling JSObjectGetTypedArrayBytesPtr (5) or
JSObjectGetArrayBufferBytesPtr (12) will pin and lock the ArrayBuffer's data for the remaining lifetime of that
ArrayBuffer. This is because, currently, we do not have finalizers for our Array Buffers or Typed Arrays with a
backing ArrayBuffer and adding one would likely incur a non-trivial cost to GC. Also, we do not have a direct
way to make a Typed Array from a pointer with an offset as we do not expect using offsets to be a common use
case of the API.
While it would have been nice to integrate our backing store with CFData or one of its subclasses, it is not
possible to force a CFData/CFMutableData to be both writable and have a fixed size/backing store pointer.
NSData is not writable and CFMutableData can have a fixed pointer if it is allocated with a non-zero capacity
but there is no way for us to force an existing CFMutableData into this state.
* API/APIUtils.h: Copied from Source/JavaScriptCore/runtime/ArrayBuffer.cpp.
(handleExceptionIfNeeded):
(setException):
* API/JSBase.h:
* API/JSObjectRef.cpp:
(handleExceptionIfNeeded): Deleted.
* API/JSTypedArray.cpp: Added.
(toJSTypedArrayType):
(toTypedArrayType):
(createTypedArray):
(JSValueGetTypedArrayType):
(JSObjectMakeTypedArray):
(JSObjectMakeTypedArrayWithBytesNoCopy):
(JSObjectMakeTypedArrayWithArrayBuffer):
(JSObjectMakeTypedArrayWithArrayBufferAndOffset):
(JSObjectGetTypedArrayBytesPtr):
(JSObjectGetTypedArrayLength):
(JSObjectGetTypedArrayByteLength):
(JSObjectGetTypedArrayByteOffset):
(JSObjectGetTypedArrayBuffer):
(JSObjectMakeArrayBufferWithBytesNoCopy):
(JSObjectGetArrayBufferBytesPtr):
(JSObjectGetArrayBufferByteLength):
* API/JSTypedArray.h: Added.
* API/JSValueRef.cpp:
(handleExceptionIfNeeded): Deleted.
* API/JSValueRef.h:
* API/JavaScript.h:
* API/WebKitAvailability.h:
* API/tests/TypedArrayCTest.cpp: Added.
(id):
(freePtr):
(assertEqualsAsNumber):
(testAccess):
(testConstructors):
(forEachTypedArrayType):
(testTypedArrayCAPI):
* API/tests/TypedArrayCTest.h: Added.
* API/tests/testapi.c:
(main):
* CMakeLists.txt:
* ForwardingHeaders/JavaScriptCore/JSTypedArray.h: Added.
* JavaScriptCore.xcodeproj/project.pbxproj:
* PlatformEfl.cmake:
* PlatformGTK.cmake:
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::transfer):
* runtime/ArrayBuffer.h:
(JSC::arrayBufferDestructorNull):
(JSC::arrayBufferDestructorDefault):
(JSC::ArrayBufferContents::ArrayBufferContents):
(JSC::ArrayBufferContents::transfer):
(JSC::ArrayBuffer::createAdopted):
(JSC::ArrayBuffer::createFromBytes):
(JSC::ArrayBuffer::ArrayBuffer):
(JSC::ArrayBuffer::pinAndLock):
(JSC::ArrayBufferContents::tryAllocate):
(JSC::ArrayBufferContents::~ArrayBufferContents):
* shell/PlatformWin.cmake:
2016-03-10 Saam barati <sbarati@apple.com>
[ES6] Instanceof isn't spec compliant when the RHS is a Proxy with a target that is a function
https://bugs.webkit.org/show_bug.cgi?id=155329
Reviewed by Mark Lam.
We use type info flags on the structure to dictate whether or not
the RHS of an instanceof is a valid RHS (i.e, a function). The solution
to make Proxy a valid RHS when the Proxy's target is callable is to have
two different structures for ProxyObject: one for a non-callable target
and one for a callable target.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::moduleRecordStructure):
(JSC::JSGlobalObject::moduleNamespaceObjectStructure):
(JSC::JSGlobalObject::proxyObjectStructure):
(JSC::JSGlobalObject::callableProxyObjectStructure):
(JSC::JSGlobalObject::proxyRevokeStructure):
(JSC::JSGlobalObject::wasmModuleStructure):
* runtime/ProxyConstructor.cpp:
(JSC::makeRevocableProxy):
(JSC::constructProxyObject):
(JSC::ProxyConstructor::getConstructData):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::ProxyObject):
(JSC::ProxyObject::structureForTarget):
(JSC::ProxyObject::finishCreation):
* runtime/ProxyObject.h:
(JSC::ProxyObject::create):
(JSC::ProxyObject::createStructure):
* tests/es6.yaml:
* tests/stress/proxy-instanceof.js: Added.
(assert):
(test):
(C):
(test.let.handler.get if):
(test.let.handler):
2016-03-10 Michael Saboff <msaboff@apple.com>
[ES6] RegExp sticky flag should be ignored in String.match when global flag is given
https://bugs.webkit.org/show_bug.cgi?id=155332
Reviewed by Saam Barati.
Removed logic from stringProtoFuncMatch that handles the case where both global and sticky flags are set.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncMatch):
2016-03-10 Michael Saboff <msaboff@apple.com>
[ES6] Allow RegExp constructor to take pattern from an existing RegExp with new flags
https://bugs.webkit.org/show_bug.cgi?id=155315
Reviewed by Saam Barati.
Changed to comply with section 21.2.3.1, step 5. Eliminated syntax error.
In the process, change to get the VM at the top of the function.
Updated tests accordingly.
* runtime/RegExpConstructor.cpp:
(JSC::constructRegExp):
* tests/es6.yaml: Changed miscellaneous_RegExp_constructor_can_alter_flags.js to normal.
* tests/mozilla/mozilla-tests.yaml: Disabled ecma_3/RegExp/15.10.4.1-5-n.js as it checks
for the old behavior of throwing a syntax error.
2016-03-10 Saam barati <sbarati@apple.com>
[ES6] Make ToPropertyDescriptor spec compliant
https://bugs.webkit.org/show_bug.cgi?id=155313
Reviewed by Mark Lam.
We were performing HasProperty(.) and Get(.) in the same operation.
This isn't valid according to the spec and it's user observable
behavior with Proxy. This patch fixes ToPropertyDescriptor to use
two distinct operations for HasProperty(.) and Get(.).
* runtime/ObjectConstructor.cpp:
(JSC::ownEnumerablePropertyKeys):
(JSC::toPropertyDescriptor):
* tests/es6.yaml:
* tests/stress/to-property-key-correctness.js: Added.
(assert):
(test):
(test.let.handler.has):
(arrayEq):
(let.handler.has):
(let.target):
(set get let):
2016-03-10 Brian Burg <bburg@apple.com>
Web Inspector: report the underlying parser error message when JSON parsing fails
https://bugs.webkit.org/show_bug.cgi?id=155303
<rdar://problem/25088939>
Reviewed by Timothy Hatcher.
* inspector/scripts/generate-inspector-protocol-bindings.py:
(generate_from_specification.load_specification):
Stringize the underlying error so we can see what it says.
2016-03-09 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: JavaScript Heap Allocations Timeline
https://bugs.webkit.org/show_bug.cgi?id=155287
<rdar://problem/25078088>
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._describe):
(InjectedScript.prototype._nodeDescription):
Provide the nicer node preview more often.
2016-03-10 Saam barati <sbarati@apple.com>
Assignment to new.target should be an early error
https://bugs.webkit.org/show_bug.cgi?id=151148
Reviewed by Mark Lam.
This patch makes it so that any form of assignment to new.target
is an early syntax error.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createNewTargetExpr):
(JSC::ASTBuilder::isNewTarget):
(JSC::ASTBuilder::createResolve):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseUnaryExpression):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createThisExpr):
(JSC::SyntaxChecker::createSuperExpr):
(JSC::SyntaxChecker::createNewTargetExpr):
(JSC::SyntaxChecker::isNewTarget):
(JSC::SyntaxChecker::createResolve):
(JSC::SyntaxChecker::createObjectLiteral):
* tests/es6.yaml:
* tests/stress/new-target-syntax-errors.js: Added.
(shouldBeSyntaxError):
(shouldNotBeSyntaxError):
* tests/stress/new-target.js:
(Constructor):
(doWeirdThings):
(noAssign): Deleted.
(catch): Deleted.
2016-03-08 Skachkov Oleksandr <gskachkov@gmail.com>
How we load new.target in arrow functions is broken
https://bugs.webkit.org/show_bug.cgi?id=155153
Reviewed by Saam Barati.
Fixed not correct approach of caching new.target. In current patch was added code feature
flag that shows that current function is using new.target, when generating byte code an arrow
function we are loading new.target value to its register from arrow function lexical environment.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::newTarget):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createNewTargetExpr):
(JSC::ASTBuilder::usesNewTarget):
* parser/Nodes.h:
(JSC::ScopeNode::usesNewTarget):
* parser/ParserModes.h:
* tests/stress/arrowfunction-lexical-bind-newtarget.js:
2016-03-09 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Get a RemoteObject or ObjectPreview from HeapSnapshot Object Identifier
https://bugs.webkit.org/show_bug.cgi?id=155264
<rdar://problem/25070716>
Reviewed by Timothy Hatcher.
* inspector/InjectedScript.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::functionDetails):
(Inspector::InjectedScript::previewValue):
New InjectedScript methods for building Debugger.FunctionDetails
or Runtime.ObjectPreview protocol objects from a JSValue.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype.previewValue):
(InjectedScript.prototype.functionDetails):
(InjectedScript.prototype.getFunctionDetails):
(InjectedScript.RemoteObject.prototype._isPreviewableObjectInternal):
(InjectedScript.RemoteObject.prototype._createObjectPreviewForValue): Deleted.
(InjectedScript.RemoteObject.prototype._appendEntryPreviews): Deleted.
Share code around creating function details or object preview objects.
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::InspectorHeapAgent):
(Inspector::InspectorHeapAgent::nodeForHeapObjectIdentifier):
(Inspector::InspectorHeapAgent::getPreview):
(Inspector::InspectorHeapAgent::getRemoteObject):
* inspector/agents/InspectorHeapAgent.h:
* inspector/protocol/Heap.json:
New protocol methods that go from heap object identifier to a
remote object or some kind of preview.
* inspector/scripts/codegen/generator.py:
Allow runtime casts for ObjectPreview.
2016-03-09 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Intl Constructors not web compatible with Object.create usage
https://bugs.webkit.org/show_bug.cgi?id=153679
Reviewed by Darin Adler.
Add workaround for initializing NumberFormat and DateTimeFormat objects
using Object.create followed by constructor.call. This is necessary for
backwards compatibility with libraries relying on v1 behavior of Intl
constructors.
Collator does not get the workaround, since polyfills do not include it,
and there are not any known instances of v2 incompatible libraries.
The workaround involves checking for an object that inherits from the
*Format constructor, but was not actually initialized with that type. A
substitute instance is created and attached to the object using a private
name. The prototype functions then check for the private property to use
in place of the original object.
Since this behavior is not part of the v2 spec, it should be removed as
soon as the incompatible behavior is no longer in common use.
* runtime/CommonIdentifiers.h:
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::callIntlDateTimeFormat):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
(JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::callIntlNumberFormat):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototypeGetterFormat):
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
2016-03-09 Saam barati <sbarati@apple.com>
Add proper JSON.stringify support for Proxy when the target is an array
https://bugs.webkit.org/show_bug.cgi?id=155180
Reviewed by Darin Adler.
This patch makes the following type of program true:
`JSON.stringify(new Proxy([25], {})) === "[25]"`
We need to change the JSON stringifier to use the IsArray test
in section 7.2.2 of ES6 spec instead of the JSC inherits(JSArray::info())
test.
This patch also adds tests for general JSON.stringify support
of Proxy.
* runtime/ArrayConstructor.cpp:
(JSC::arrayConstructorIsArray):
(JSC::arrayConstructorPrivateFuncIsArrayConstructor):
* runtime/ArrayConstructor.h:
(JSC::isArray):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::object):
(JSC::Stringifier::appendStringifiedValue):
(JSC::Stringifier::startNewLine):
(JSC::Stringifier::Holder::Holder):
* tests/es6.yaml:
* tests/stress/proxy-json.js: Added.
(assert):
(test):
2016-03-09 Saam Barati <sbarati@apple.com>
ES6: Implement lexical scoping for function definitions in strict mode
https://bugs.webkit.org/show_bug.cgi?id=152844
Reviewed by Geoffrey Garen.
This patch implements block scoping for function definitions
in strict mode. The implementation works as follows:
- If we're in sloppy mode, function declarations work exactly
as they did before this patch. I.e, function declarations are hoisted
and declared like "var" variables.
- If you're in strict mode and at the top of a function scope or program
scope, function declarations still work like they used to. They are defined
like "var" variables. This is necessary for backwards compatibility
because ES5 strict mode allowed duplicate function declarations at the
top-most scope of a program/function.
- If you're in strict mode and inside a block statement or a switch statement,
function declarations are now block scoped. All function declarations within
a block are hoisted to the beginning of the block. They are not hoisted out of the
block like they are in sloppy mode. This allows for the following types of
programs:
```
function foo() {
function bar() { return 20; }
{
function bar() { return 30; }
bar(); // 30
}
bar(); // 20
}
```
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::instantiateLexicalVariables):
(JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::initializeBlockScopedFunctions):
(JSC::BytecodeGenerator::popLexicalScope):
(JSC::BytecodeGenerator::liftTDZCheckIfPossible):
(JSC::BytecodeGenerator::pushTDZVariables):
(JSC::BytecodeGenerator::getVariablesUnderTDZ):
(JSC::BytecodeGenerator::emitNewRegExp):
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewFunctionExpression):
(JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
* bytecompiler/BytecodeGenerator.h:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createSourceElements):
(JSC::ASTBuilder::features):
(JSC::ASTBuilder::numConstants):
(JSC::ASTBuilder::createFuncDeclStatement):
(JSC::ASTBuilder::createClassDeclStatement):
(JSC::ASTBuilder::createBlockStatement):
(JSC::ASTBuilder::createTryStatement):
(JSC::ASTBuilder::createSwitchStatement):
(JSC::ASTBuilder::Scope::Scope):
(JSC::ASTBuilder::funcDeclarations): Deleted.
* parser/NodeConstructors.h:
(JSC::CaseBlockNode::CaseBlockNode):
(JSC::SwitchNode::SwitchNode):
(JSC::BlockNode::BlockNode):
* parser/Nodes.cpp:
(JSC::ScopeNode::ScopeNode):
(JSC::ScopeNode::singleStatement):
(JSC::ProgramNode::ProgramNode):
(JSC::ModuleProgramNode::ModuleProgramNode):
(JSC::EvalNode::EvalNode):
(JSC::FunctionNode::FunctionNode):
(JSC::VariableEnvironmentNode::VariableEnvironmentNode):
* parser/Nodes.h:
(JSC::VariableEnvironmentNode::VariableEnvironmentNode):
(JSC::VariableEnvironmentNode::lexicalVariables):
(JSC::VariableEnvironmentNode::functionStack):
(JSC::ScopeNode::captures):
(JSC::ScopeNode::varDeclarations):
(JSC::ScopeNode::neededConstants):
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::ModuleProgramNode::startColumn):
(JSC::ModuleProgramNode::endColumn):
(JSC::ScopeNode::functionStack): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::didFinishParsing):
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseSwitchStatement):
(JSC::Parser<LexerType>::parseBlockStatement):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::getMetadata):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseExportDeclaration):
* parser/Parser.h:
(JSC::Scope::declareVariable):
(JSC::Scope::declareFunction):
(JSC::Scope::appendFunction):
(JSC::Scope::takeFunctionDeclarations):
(JSC::Scope::declareLexicalVariable):
(JSC::Parser::currentVariableScope):
(JSC::Parser::currentLexicalDeclarationScope):
(JSC::Parser::currentFunctionScope):
(JSC::Parser::pushScope):
(JSC::Parser::popScopeInternal):
(JSC::Parser::declareVariable):
(JSC::Parser::declareFunction):
(JSC::Parser::hasDeclaredVariable):
(JSC::Parser::isFunctionMetadataNode):
(JSC::Parser<LexerType>::parse):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFuncDeclStatement):
(JSC::SyntaxChecker::createClassDeclStatement):
(JSC::SyntaxChecker::createBlockStatement):
(JSC::SyntaxChecker::createExprStatement):
(JSC::SyntaxChecker::createIfStatement):
(JSC::SyntaxChecker::createContinueStatement):
(JSC::SyntaxChecker::createTryStatement):
(JSC::SyntaxChecker::createSwitchStatement):
(JSC::SyntaxChecker::createWhileStatement):
(JSC::SyntaxChecker::createWithStatement):
(JSC::SyntaxChecker::createDoWhileStatement):
* parser/VariableEnvironment.h:
(JSC::VariableEnvironmentEntry::isExported):
(JSC::VariableEnvironmentEntry::isImported):
(JSC::VariableEnvironmentEntry::isImportedNamespace):
(JSC::VariableEnvironmentEntry::isFunction):
(JSC::VariableEnvironmentEntry::setIsCaptured):
(JSC::VariableEnvironmentEntry::setIsConst):
(JSC::VariableEnvironmentEntry::setIsExported):
(JSC::VariableEnvironmentEntry::setIsImported):
(JSC::VariableEnvironmentEntry::setIsImportedNamespace):
(JSC::VariableEnvironmentEntry::setIsFunction):
(JSC::VariableEnvironmentEntry::clearIsVar):
(JSC::VariableEnvironment::VariableEnvironment):
(JSC::VariableEnvironment::begin):
(JSC::VariableEnvironment::end):
* tests/es6.yaml:
* tests/stress/block-scoped-function-declarations.js: Added.
(assert):
(test):
(f.foo.bar):
(f.foo.):
(f.foo):
(f):
(assert.foo.):
(assert.foo):
(assert.foo.foo):
(assert.foo.bar):
(assert.foo.switch.case.1):
(assert.foo.switch.case.2):
(assert.foo.switch.foo):
(assert.foo.switch.bar):
2016-03-09 Saam barati <sbarati@apple.com>
Array.isArray support for Proxy
https://bugs.webkit.org/show_bug.cgi?id=155179
Reviewed by Mark Lam.
This patch implements Array.isArray to be compliant
with the ES6 spec. Specifically, it needs to interface
properly with Proxy arguments.
https://tc39.github.io/ecma262/#sec-isarray
* runtime/ArrayConstructor.cpp:
(JSC::ArrayConstructor::getCallData):
(JSC::arrayConstructorIsArray):
(JSC::arrayConstructorPrivateFuncIsArrayConstructor):
* runtime/ArrayPrototype.cpp:
(JSC::speciesConstructArray):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::revoke):
(JSC::ProxyObject::isRevoked):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
(JSC::ProxyObject::target):
(JSC::ProxyObject::handler):
* tests/es6.yaml:
* tests/stress/proxy-is-array.js: Added.
(assert):
(test):
2016-03-09 Benjamin Poulain <bpoulain@apple.com>
[JSC] Fix the ARM64 MacroAssembler after r197816
https://bugs.webkit.org/show_bug.cgi?id=155268
Reviewed by Mark Lam.
The patch tries to generate instructions that do not exist,
causing quite fun stuff at runtime.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load8):
(JSC::MacroAssemblerARM64::store16):
(JSC::MacroAssemblerARM64::store8):
2016-03-09 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r197873.
https://bugs.webkit.org/show_bug.cgi?id=155262
"Crashes some JSC tests" (Requested by mlam on #webkit).
Reverted changeset:
"Add dumping of function expression names in CodeBlock
bytecode dump."
https://bugs.webkit.org/show_bug.cgi?id=155248
http://trac.webkit.org/changeset/197873
2016-03-09 Oliver Hunt <oliver@apple.com>
Fix old iOS
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
2016-03-09 Oliver Hunt <oliver@apple.com>
Wincairo buildfix
https://bugs.webkit.org/show_bug.cgi?id=155245
Reviewed by Mark Lam.
Fix up exports for a few symbols
* jit/ExecutableAllocator.h:
* jit/ExecutableAllocatorFixedVMPool.cpp:
2016-03-09 Mark Lam <mark.lam@apple.com>
Add dumping of function expression names in CodeBlock bytecode dump.
https://bugs.webkit.org/show_bug.cgi?id=155248
Reviewed by Filip Pizlo.
Because ...
[ 19] new_func_exp loc5, loc3, f0:foo
... is more informative than
[ 19] new_func_exp loc5, loc3, f0
Anonymous functions will be dumped as <anon>.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpFunctionExpr):
(JSC::CodeBlock::dumpBytecode):
* bytecode/CodeBlock.h:
2016-03-09 Michael Saboff <msaboff@apple.com>
[ES6] Implement RegExp sticky flag and related functionality
https://bugs.webkit.org/show_bug.cgi?id=155177
Reviewed by Saam Barati.
Implemented the ES6 RegExp sticky functionality.
There are two main behavior changes when the sticky flag is specified.
1) Matching starts at lastIndex and lastIndex is updated after the match.
2) The regular expression is only matched from the start position in the string.
See ES6 section 21.2.5.2.2 for details.
Changed both the Yarr interpreter and jit to not loop to the next character for sticky RegExp's.
Updated RegExp exec and match, and stringProtoFuncMatch to handle lastIndex changes.
Restructured the way flags are passed to and through YarrPatterns to use RegExpFlags instead of
individual bools.
Updated tests for 'y' flag and new behavior.
* bytecode/CodeBlock.cpp:
(JSC::regexpToSourceString):
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::findMagicComment):
* runtime/CommonIdentifiers.h:
* runtime/RegExp.cpp:
(JSC::regExpFlags):
(JSC::RegExpFunctionalTestCollector::outputOneTest):
(JSC::RegExp::finishCreation):
(JSC::RegExp::compile):
(JSC::RegExp::compileMatchOnly):
* runtime/RegExp.h:
* runtime/RegExpKey.h:
* runtime/RegExpObjectInlines.h:
(JSC::RegExpObject::execInline):
(JSC::RegExpObject::matchInline):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
(JSC::flagsString):
(JSC::regExpProtoGetterMultiline):
(JSC::regExpProtoGetterSticky):
(JSC::regExpProtoGetterUnicode):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncMatch):
* tests/es6.yaml:
* tests/stress/static-getter-in-names.js:
(shouldBe):
* yarr/RegularExpression.cpp:
(JSC::Yarr::RegularExpression::Private::compile):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::tryConsumeBackReference):
(JSC::Yarr::Interpreter::matchAssertionBOL):
(JSC::Yarr::Interpreter::matchAssertionEOL):
(JSC::Yarr::Interpreter::matchAssertionWordBoundary):
(JSC::Yarr::Interpreter::matchDotStarEnclosure):
(JSC::Yarr::Interpreter::matchDisjunction):
(JSC::Yarr::Interpreter::Interpreter):
(JSC::Yarr::ByteCompiler::atomPatternCharacter):
* yarr/YarrInterpreter.h:
(JSC::Yarr::BytecodePattern::BytecodePattern):
(JSC::Yarr::BytecodePattern::estimatedSizeInBytes):
(JSC::Yarr::BytecodePattern::ignoreCase):
(JSC::Yarr::BytecodePattern::multiline):
(JSC::Yarr::BytecodePattern::sticky):
(JSC::Yarr::BytecodePattern::unicode):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::matchCharacterClass):
(JSC::Yarr::YarrGenerator::jumpIfCharNotEquals):
(JSC::Yarr::YarrGenerator::generateAssertionBOL):
(JSC::Yarr::YarrGenerator::generateAssertionEOL):
(JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
(JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
(JSC::Yarr::YarrGenerator::generateDotStarEnclosure):
(JSC::Yarr::YarrGenerator::backtrack):
* yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
(JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
(JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets):
(JSC::Yarr::YarrPatternConstructor::optimizeBOL):
(JSC::Yarr::YarrPattern::compile):
(JSC::Yarr::YarrPattern::YarrPattern):
* yarr/YarrPattern.h:
(JSC::Yarr::YarrPattern::reset):
(JSC::Yarr::YarrPattern::nonwordcharCharacterClass):
(JSC::Yarr::YarrPattern::ignoreCase):
(JSC::Yarr::YarrPattern::multiline):
(JSC::Yarr::YarrPattern::sticky):
(JSC::Yarr::YarrPattern::unicode):
2016-03-09 Mark Lam <mark.lam@apple.com>
FunctionExecutable::ecmaName() should not be based on inferredName().
https://bugs.webkit.org/show_bug.cgi?id=155203
Reviewed by Michael Saboff.
The ES6 rules for how a function name should be inferred closely matches JSC's
implementation with one exception:
var o = {}
o.foo = function() {}
JSC's inferredName for o.foo would be "foo".
ES6 specifies that o.foo.name is "".
The fix is to add a distinct FunctionExecutable::ecmaName() which applies the ES6
rules for inferring the initial value of Function.name.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createAssignResolve):
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createProperty):
(JSC::ASTBuilder::makeAssignNode):
* parser/Nodes.h:
* runtime/Executable.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::reifyName):
* tests/es6.yaml:
2016-03-09 Michael Saboff <msaboff@apple.com>
Harden JSC Root element functions from bad values
https://bugs.webkit.org/show_bug.cgi?id=155234
Reviewed by Saam Barati.
Changed jsCast() to jsDynamicCast() in Root related function to protect against being
called with non-Root arguments.
* jsc.cpp:
(functionCreateElement):
(functionGetElement):
(functionSetElementRoot):
2016-03-09 Benjamin Poulain <benjamin@webkit.org>
[JSC] Pick how to OSR Enter to FTL at runtime instead of compile time
https://bugs.webkit.org/show_bug.cgi?id=155217
Reviewed by Filip Pizlo.
This patch addresses 2 types of problems with tiering up to FTL
with OSR Entry in a loop:
-When there are nested loops, it is generally valuable to enter
an outer loop rather than an inner loop.
-When tiering up at a point that cannot OSR Enter, we are at
the mercy of the outer loop frequency to compile the right
entry point.
The first case is significant in the test "gaussian-blur".
That test has 4 nested loops. When we have an OSR Entry,
the analysis phases have to be pesimistic where we enter:
we do not really know what constraint can be proven from
the DFG code that was running.
In "gaussian-blur", integer-range analysis removes pretty
much all overflow checks in the inner loops of where we entered.
The more outside we enter, the better code we generate.
Since we spend the most iterations in the inner loop, we naturally
tend to OSR Enter into the 2 most inner loops, making the most
pessimistic assumptions.
To avoid such problems, I changed how we decide where to OSR Enter.
Previously, the last CheckTierUpAndOSREnter to cross the threshold
was where we take the entry point for FTL.
What happens now is that the entry point is not decied when
compiling the CheckTierUp variants. Instead, all the information
we need is gathered during compilation and keept on the JITCode
to be used at runtime.
When we try to tier up and decide to OSR Enter, we use the information
we have to pick a good outer loop for OSR Entry.
Now the problem is outer loop do not CheckTierUpAndOSREnter often,
wasting several miliseconds before entering the newly compiled FTL code.
To solve that, every CheckTierUpAndOSREnter has its own trigger that
bypass the counter. When the FTL Code is compiled, the trigger is set
and we enter through the right CheckTierUpAndOSREnter immediately.
---
This new mechanism also solves a problem of ai-astar.
When we try to tier up in ai-astar, we had nothing to compile until
the outer loop is reached.
To make sure we reached the CheckTierUpAndOSREnter in a reasonable time,
we had CheckTierUpWithNestedTriggerAndOSREnter with a special trigger.
With the new mechanism, we can do much better:
-When we keep hitting CheckTierUpInLoop, we now have all the information
we need to already start compiling the outer loop.
Instead of waiting for the outer loop to be reached a few times, we compile
it as soon as the inner loop is hammering CheckTierUpInLoop.
-With the new triggers, the very next time we hit the outer loop, we OSR Enter.
This allow us to compile what we need sooner and enter sooner.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize): Deleted.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC): Deleted.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Deleted.
* dfg/DFGJITCode.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::compileEntryExecutionFlag):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPlan.h:
(JSC::DFG::Plan::canTierUpAndOSREnter):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute): Deleted.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
(JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
(JSC::DFG::TierUpCheckInjectionPhase::findLoopsContainingLoopHintWithoutOSREnter): Deleted.
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
(JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
2016-03-08 Filip Pizlo <fpizlo@apple.com>
DFG should be able to constant-fold strings
https://bugs.webkit.org/show_bug.cgi?id=155200
Reviewed by Geoffrey Garen.
This adds constant-folding of string1 + string2 and string.length. The actual folding
rule is easy, but there are some gotchas.
The problem is that the DFG cannot allocate new JSString objects until we are on the
main thread. So, DFG IR must have a node for a JSValue string constant that hasn't been
created yet - i.e. it doesn't have any concrete JSValue bits yet.
We have the ability to speak of such things, using LazyJSValue. But that's a class, not
a node type. This patch now adds a node type, LazyJSConstant, which is a Node that holds
a LazyJSValue.
This puts us in a weird situation: AI uses JSValue to represent constants. It would take
a lot of work to change it to use LazyJSValue. So, this implements the constant folding
in StrengthReductionPhase. I created a bug and put a FIXME about moving these rules into
AI.
OTOH, our experience in B3 shows that constant folding in strength reduction is quite
nice. It would totally make sense to have strength reduction have constant folding rules
that mirror the rules in AI, or to factor out the AI constant folding rules, the same
way that B3 factors out those rules into Value methods.
Another issue is how to represent the cumulative result of possibly many foldings. I
initially considered adding LazyJSValue kinds that represented concatenation. Folding
the concatenation to a constant meand that this constant was actually a LazyJSValue that
represented the concatenation of two other things. But this would get super messy if we
wanted to fold an operation that uses the results of another folded operation.
So, the JIT thread folds string operations by creating a WTF::String that contains the
result. The DFG::Graph holds a +1 on the underlying StringImpl, so we can pass the
StringImpl* around without reference counting. The LazyJSValue now has a special kind
that means: we created this StringImpl* on the JIT thread, and once the JIT is done, we
will relinquish ownership of it. LazyJSValue has some magic to emit code for these
to-be-created-JSStrings while also transferring ownership of the StringImpl from the JIT
thread to the main thread and registering the JSString with the GC.
This just implements folding for concatenation and GetArrayLength. It's just a proof of
concept for evil things I want to do later.
This change is a 2.5x speed-up on the string concatenation microbenchmarks I added in
this patch.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGFrozenValue.cpp:
(JSC::DFG::FrozenValue::emptySingleton):
(JSC::DFG::FrozenValue::tryGetString):
(JSC::DFG::FrozenValue::dumpInContext):
* dfg/DFGFrozenValue.h:
(JSC::DFG::FrozenValue::strength):
* dfg/DFGGraph.h:
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::newString):
(JSC::DFG::LazyJSValue::getValue):
(JSC::DFG::equalToStringImpl):
(JSC::DFG::LazyJSValue::tryGetStringImpl):
(JSC::DFG::LazyJSValue::tryGetString):
(JSC::DFG::LazyJSValue::strictEqual):
(JSC::DFG::LazyJSValue::switchLookupValue):
(JSC::DFG::LazyJSValue::emit):
(JSC::DFG::LazyJSValue::dumpInContext):
* dfg/DFGLazyJSValue.h:
(JSC::DFG::LazyJSValue::LazyJSValue):
(JSC::DFG::LazyJSValue::knownStringImpl):
(JSC::DFG::LazyJSValue::kind):
(JSC::DFG::LazyJSValue::tryGetValue):
(JSC::DFG::LazyJSValue::character):
(JSC::DFG::LazyJSValue::stringImpl):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToIdentityOn):
(JSC::DFG::Node::convertToLazyJSConstant):
(JSC::DFG::Node::convertToPutHint):
(JSC::DFG::Node::convertToPutClosureVarHint):
(JSC::DFG::Node::tryGetString):
(JSC::DFG::Node::promotedLocationDescriptor):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToConstant):
(JSC::DFG::Node::convertToConstantStoragePointer):
(JSC::DFG::Node::castConstant):
(JSC::DFG::Node::hasLazyJSValue):
(JSC::DFG::Node::lazyJSValue):
(JSC::DFG::Node::initializationValueForActivation):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
(JSC::DFG::SpeculativeJIT::compileLazyJSConstant):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileInt52Constant):
(JSC::FTL::DFG::LowerDFGToB3::compileLazyJSConstant):
(JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
2016-03-08 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Memory Timeline should show MemoryPressure events
https://bugs.webkit.org/show_bug.cgi?id=155158
<rdar://problem/25026610>
Reviewed by Brian Burg.
* inspector/protocol/Memory.json:
2016-03-08 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Add Heap domain start/stop tracking commands
https://bugs.webkit.org/show_bug.cgi?id=155190
Reviewed by Brian Burg.
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorHeapAgent::startTracking):
(Inspector::InspectorHeapAgent::stopTracking):
* inspector/agents/InspectorHeapAgent.h:
* inspector/protocol/Heap.json:
2016-03-08 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Add a way to create a Heap Snapshot
https://bugs.webkit.org/show_bug.cgi?id=155188
Reviewed by Brian Burg.
* inspector/agents/InspectorHeapAgent.h:
* inspector/protocol/Heap.json:
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::snapshot):
Take a heap snapshot and return the JSON string result.
* inspector/protocol/Debugger.json:
Remove unused optional inferredName. Our displayName would be inferred.
2016-03-08 Oliver Hunt <oliver@apple.com>
Fix ios bot build.
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
2016-03-08 Mark Lam <mark.lam@apple.com>
Implement Function.name support for getters/setters and inferring name of function properties.
https://bugs.webkit.org/show_bug.cgi?id=154865
Rubber-stamped by Joseph Pecoraro.
Follow up to the fix for this bug: adding a few small clean-ups for issues Joe
pointed out in the bug.
* runtime/JSBoundSlotBaseFunction.cpp:
(JSC::JSBoundSlotBaseFunction::create):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitiveByIndex):
2016-03-08 Oliver Hunt <oliver@apple.com>
Start moving to separated writable and executable mappings in the JIT
https://bugs.webkit.org/show_bug.cgi?id=155178
Reviewed by Fil Pizlo.
Start moving to a separate writable and executable heap for the various
JITs.
As part of our work to harden the JIT against various attacks, we're
moving away from our current RWX heap and on to using separate RW and X
mappings. This means that simply leaking the location of the executable
mapping is not sufficient to compromise JSC, so we can continue to
use direct executable pointers in our GC objects (which we need for
performance), but keep the writable pointer in only a single location
so that we are less likely to leak the address. To further obscure the
address of the writable region we place it in an execute only region
of memory so that it is not possible to read the location from
anywhere. That means an attacker must have at least partial control
of PC (to call jitMemCopy) before they can start to attack the JIT.
This work is initially ARM64 only, as we use as the jitMemCopy is
currently specific to that platform's calling conventions and layout.
We're just landing it in the current form so that we can at least
ensure it doesn't regress.
* Configurations/FeatureDefines.xcconfig:
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::ldp):
(JSC::ARM64Assembler::ldnp):
(JSC::ARM64Assembler::fillNops):
(JSC::ARM64Assembler::stp):
(JSC::ARM64Assembler::stnp):
(JSC::ARM64Assembler::replaceWithJump):
(JSC::ARM64Assembler::replaceWithLoad):
(JSC::ARM64Assembler::replaceWithAddressComputation):
(JSC::ARM64Assembler::setPointer):
(JSC::ARM64Assembler::repatchInt32):
(JSC::ARM64Assembler::repatchCompact):
(JSC::ARM64Assembler::linkJumpOrCall):
(JSC::ARM64Assembler::linkCompareAndBranch):
(JSC::ARM64Assembler::linkConditionalBranch):
(JSC::ARM64Assembler::linkTestAndBranch):
(JSC::ARM64Assembler::loadStoreRegisterPairOffset):
(JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
(JSC::LinkBuffer::allocate):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::LinkBuffer):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::sub64):
(JSC::MacroAssemblerARM64::load64):
(JSC::MacroAssemblerARM64::loadPair64):
(JSC::MacroAssemblerARM64::loadPair64WithNonTemporalAccess):
(JSC::MacroAssemblerARM64::load8):
(JSC::MacroAssemblerARM64::store64):
(JSC::MacroAssemblerARM64::storePair64):
(JSC::MacroAssemblerARM64::storePair64WithNonTemporalAccess):
(JSC::MacroAssemblerARM64::store8):
(JSC::MacroAssemblerARM64::branchAdd64):
(JSC::MacroAssemblerARM64::branchSub64):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
(JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2016-03-08 Mark Lam <mark.lam@apple.com>
Implement Function.name support for getters/setters and inferring name of function properties.
https://bugs.webkit.org/show_bug.cgi?id=154865
Reviewed by Geoffrey Garen.
1. toString() no longer uses the value of Function.name as the name of the
function in the returned string, because ...
i. Function.name is supposed to be configurable. Hence, it can be made
writable and can be set to any JSValue, or deleted.
ii. Function.prototype.toString() is supposed to produce a string that can be
eval'ed. Hence, for JS functions, the function name in the produced
string must be a legal function name (and not some arbitrary value set in
Function.name). For example, while a number is a legal value for
Function.name, it is not legal as the function name in the toString()
string.
Instead, we'll always use the original name from the JS source that the
function was parsed from.
2. JSFunction::name() now always return the original name, not the value of
the Function.name property. As a result, it also no longer needs an
ExecState* arg.
If the original name is an empty string, JSFunction::name() will use the
inferred name.
3. For JS functions, the original name can be attained from their
FunctionExecutable object.
For host/native functions (which do not have a FunctionExecutable), we get the
"original" name from its NativeExecutable.
4. The m_hostFunctionStubMap now keys its NativeExecutable pointers using the
original name, in addition to the native function and constructor pointers.
This is needed because we want a different NativeExecutable for functions with
a different name (to satisfy (3) above).
5. Changed JSBoundFunction to store the name of its bound function in its
NativeExecutable. This will later be used to generate the toString() string.
It's Function.name value is eagerly initialized at construction time.
6. Function.name for getters/setters are now prefixed with "get"/"set".
This was done both for the JSBoundSlotBaseFunctions and JS definable get/set
functions.
7. Added InternalFunction::m_originalName so that we can use it to generate the
toString() string. We're storing it as a JSString instead of a WTF::String
only because we want InternalFunction to be continue to be trivially
destructible.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::functionDetails):
* jit/JITThunks.cpp:
(JSC::JITThunks::finalize):
(JSC::JITThunks::hostFunctionStub):
* jit/JITThunks.h:
* runtime/Executable.h:
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::finishCreation):
(JSC::InternalFunction::visitChildren):
(JSC::InternalFunction::name):
(JSC::InternalFunction::displayName):
* runtime/InternalFunction.h:
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::create):
(JSC::JSBoundFunction::visitChildren):
(JSC::JSBoundFunction::toStringName): Deleted.
* runtime/JSBoundFunction.h:
(JSC::JSBoundFunction::boundThis):
(JSC::JSBoundFunction::boundArgs):
(JSC::JSBoundFunction::createStructure):
* runtime/JSBoundSlotBaseFunction.cpp:
(JSC::boundSlotBaseFunctionCall):
(JSC::JSBoundSlotBaseFunction::create):
* runtime/JSFunction.cpp:
(JSC::JSFunction::initializeRareData):
(JSC::JSFunction::name):
(JSC::JSFunction::displayName):
(JSC::JSFunction::calculatedDisplayName):
(JSC::JSFunction::reifyName):
* runtime/JSFunction.h:
* tests/es6.yaml:
2016-03-08 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r197793 and r197799.
https://bugs.webkit.org/show_bug.cgi?id=155195
something weird happened while landing this and everything
broke (Requested by olliej on #webkit).
Reverted changesets:
"Start moving to separated writable and executable mappings in
the JIT"
https://bugs.webkit.org/show_bug.cgi?id=155178
http://trac.webkit.org/changeset/197793
"arm64 build fix after r197793."
http://trac.webkit.org/changeset/197799
2016-03-08 Alex Christensen <achristensen@webkit.org>
arm64 build fix after r197793.
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::initializeBulletproofJIT):
(JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
Use consistent ENABLE macro. It looks like it was partially renamed.
2016-03-08 Filip Pizlo <fpizlo@apple.com>
Regexp matching should incur less call overhead
https://bugs.webkit.org/show_bug.cgi?id=155181
Reviewed by Geoffrey Garen.
Previously we had DFG/FTL code call into the DFGOperation, which then called in to
RegExpObject, which then called into createRegExpMatchesArray, which then called into
RegExp, which then called the code generated by Yarr.
Now we have DFG/FTL code call into the DFGOperation, which does all of the things and calls
into code generated by Yarr.
This is another tiny Octane/regexp speed-up.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGOperations.cpp:
* runtime/RegExp.cpp:
(JSC::regExpFlags):
(JSC::RegExp::compile):
(JSC::RegExp::match):
(JSC::RegExp::compileMatchOnly):
(JSC::RegExp::deleteCode):
(JSC::RegExpFunctionalTestCollector::clearRegExp): Deleted.
(JSC::RegExp::compileIfNecessary): Deleted.
(JSC::RegExp::compileIfNecessaryMatchOnly): Deleted.
* runtime/RegExp.h:
* runtime/RegExpInlines.h: Added.
(JSC::RegExpFunctionalTestCollector::clearRegExp):
(JSC::RegExp::compileIfNecessary):
(JSC::RegExp::matchInline):
(JSC::RegExp::compileIfNecessaryMatchOnly):
* runtime/RegExpMatchesArray.cpp:
(JSC::createEmptyRegExpMatchesArray):
(JSC::createStructureImpl):
(JSC::tryCreateUninitializedRegExpMatchesArray): Deleted.
(JSC::createRegExpMatchesArray): Deleted.
* runtime/RegExpMatchesArray.h:
(JSC::tryCreateUninitializedRegExpMatchesArray):
(JSC::createRegExpMatchesArray):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::put):
(JSC::RegExpObject::exec):
(JSC::RegExpObject::match):
(JSC::getLastIndexAsUnsigned): Deleted.
* runtime/RegExpObject.h:
(JSC::RegExpObject::getLastIndex):
(JSC::RegExpObject::test):
(JSC::RegExpObject::testInline):
* runtime/RegExpObjectInlines.h: Added.
(JSC::getRegExpObjectLastIndexAsUnsigned):
(JSC::RegExpObject::execInline):
(JSC::RegExpObject::matchInline):
2016-03-08 Mark Lam <mark.lam@apple.com>
synthesizePrototype() and friends need to be followed by exception checks (or equivalent).
https://bugs.webkit.org/show_bug.cgi?id=155169
Reviewed by Geoffrey Garen.
With the exception checks, we may end up throwing new exceptions over an existing
one that has been thrown but not handled yet, thereby obscuring it. It may also
mean that the VM will continue running on potentially unstable state, which may
have undesirable consequences.
I first observed this in some failed assertion while running tests on a patch for
https://bugs.webkit.org/show_bug.cgi?id=154865.
Performance is neutral with this patch (tested on x86_64).
1. Deleted JSNotAnObject, and removed all uses of it.
2. Added exception checks, when needed, following calls to synthesizePrototype()
and JSValue::toObject().
The cases that do not need an exception check are the ones that already ensures
that JSValue::toObject() is only called on a value that is convertible to an
object. In those cases, I added an assertion that no exception was thrown
after the call.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/ScriptCallStackFactory.cpp:
(Inspector::createScriptCallStackFromException):
* interpreter/Interpreter.cpp:
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncJoin):
(JSC::arrayProtoFuncConcat):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoFuncPush):
(JSC::arrayProtoFuncReverse):
(JSC::arrayProtoFuncShift):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
(JSC::arrayProtoFuncUnShift):
(JSC::arrayProtoFuncIndexOf):
(JSC::arrayProtoFuncLastIndexOf):
(JSC::arrayProtoFuncValues):
(JSC::arrayProtoFuncEntries):
(JSC::arrayProtoFuncKeys):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/ExceptionHelpers.cpp:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toObjectSlowCase):
(JSC::JSValue::toThisSlowCase):
(JSC::JSValue::synthesizePrototype):
(JSC::JSValue::putToPrimitive):
(JSC::JSValue::putToPrimitiveByIndex):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::getPropertySlot):
(JSC::JSValue::get):
* runtime/JSFunction.cpp:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoGetter):
* runtime/JSNotAnObject.cpp: Removed.
* runtime/JSNotAnObject.h: Removed.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorDefineProperties):
(JSC::objectConstructorCreate):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncValueOf):
(JSC::objectProtoFuncHasOwnProperty):
(JSC::objectProtoFuncIsPrototypeOf):
(JSC::objectProtoFuncToString):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2016-03-08 Oliver Hunt <oliver@apple.com>
Start moving to separated writable and executable mappings in the JIT
https://bugs.webkit.org/show_bug.cgi?id=155178
Reviewed by Filip Pizlo.
Start moving to a separate writable and executable heap for the various
JITs.
As part of our work to harden the JIT against various attacks, we're
moving away from our current RWX heap and on to using separate RW and X
mappings. This means that simply leaking the location of the executable
mapping is not sufficient to compromise JSC, so we can continue to
use direct executable pointers in our GC objects (which we need for
performance), but keep the writable pointer in only a single location
so that we are less likely to leak the address. To further obscure the
address of the writable region we place it in an execute only region
of memory so that it is not possible to read the location from
anywhere. That means an attacker must have at least partial control
of PC (to call jitMemCopy) before they can start to attack the JIT.
This work is initially ARM64 only, as we use as the jitMemCopy is
currently specific to that platform's calling conventions and layout.
We're just landing it in the current form so that we can at least
ensure it doesn't regress.
* Configurations/FeatureDefines.xcconfig:
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::ldp):
(JSC::ARM64Assembler::ldnp):
(JSC::ARM64Assembler::fillNops):
(JSC::ARM64Assembler::stp):
(JSC::ARM64Assembler::stnp):
(JSC::ARM64Assembler::replaceWithJump):
(JSC::ARM64Assembler::replaceWithLoad):
(JSC::ARM64Assembler::replaceWithAddressComputation):
(JSC::ARM64Assembler::setPointer):
(JSC::ARM64Assembler::repatchInt32):
(JSC::ARM64Assembler::repatchCompact):
(JSC::ARM64Assembler::linkJumpOrCall):
(JSC::ARM64Assembler::linkCompareAndBranch):
(JSC::ARM64Assembler::linkConditionalBranch):
(JSC::ARM64Assembler::linkTestAndBranch):
(JSC::ARM64Assembler::loadStoreRegisterPairOffset):
(JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
(JSC::LinkBuffer::allocate):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::LinkBuffer):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::sub64):
(JSC::MacroAssemblerARM64::load64):
(JSC::MacroAssemblerARM64::loadPair64):
(JSC::MacroAssemblerARM64::loadPair64WithNonTemporalAccess):
(JSC::MacroAssemblerARM64::load8):
(JSC::MacroAssemblerARM64::store64):
(JSC::MacroAssemblerARM64::storePair64):
(JSC::MacroAssemblerARM64::storePair64WithNonTemporalAccess):
(JSC::MacroAssemblerARM64::store8):
(JSC::MacroAssemblerARM64::branchAdd64):
(JSC::MacroAssemblerARM64::branchSub64):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::initializeBulletproofJIT):
(JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2016-03-08 Michael Saboff <msaboff@apple.com>
[ES6] Regular Expression canonicalization tables for Unicode need to be updated to use Unicode CaseFolding.txt
https://bugs.webkit.org/show_bug.cgi?id=155114
Reviewed by Darin Adler.
Extracted out the Unicode canonicalization table creation from
YarrCanonicalizeUnicode.js into a new Python script, generateYarrCanonicalizeUnicode.
That script generates the Unicode tables as the file YarrCanonicalizeUnicode.cpp in
DerivedSources/JavaScriptCore.
Updated the processing of ignore case to make the ASCII short cuts dependent on whether
or not we are a Unicode pattern.
Renamed yarr/YarrCanonicalizeUnicode.{cpp,js} back to their prior names,
YarrCanonicalizeUCS2.{cpp,js}.
Renamed yarr/YarrCanonicalizeUnicode.h to YarrCanonicalize.h as it declares both the
legacy UCS2 and Unicode tables.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* generateYarrCanonicalizeUnicode: Added.
* ucd: Added.
* ucd/CaseFolding.txt: Added. The current verion, 8.0, of the Unicode CaseFolding table.
* yarr/YarrCanonicalizeUCS2.cpp: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.cpp.
* yarr/YarrCanonicalize.h: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.h.
* yarr/YarrCanonicalizeUCS2.js: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.js.
(printHeader):
* yarr/YarrCanonicalizeUnicode.cpp: Removed.
* yarr/YarrCanonicalizeUnicode.h: Removed.
* yarr/YarrCanonicalizeUnicode.js: Removed.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::tryConsumeBackReference):
* yarr/YarrJIT.cpp:
* yarr/YarrPattern.cpp:
(JSC::Yarr::CharacterClassConstructor::putChar):
2016-03-08 Andreas Kling <akling@apple.com>
WeakBlock::visit() should check for a WeakHandleOwner before consulting mark bits.
<https://webkit.org/b/155154>
Reviewed by Darin Adler.
Reorder the checks in WeakBlock::visit() so we don't look at the mark bits in MarkedBlock
unless the current WeakImpl has a WeakHandleOwner we need to consult.
I was originally hoping to make an optimization that could skip over entire WeakBlocks
if they didn't have a single WeakHandleOwner, but it turns out that scenario is not as
common as I suspected.
* heap/WeakBlock.cpp:
(JSC::WeakBlock::visit):
2016-03-07 Saam barati <sbarati@apple.com>
[ES6] Implement revocable proxies
https://bugs.webkit.org/show_bug.cgi?id=154321
Reviewed by Mark Lam.
This patch is a straight forward implementation of Proxy.revocable
with respect to section 26.2.2.1 of the ECMAScript spec.
https://tc39.github.io/ecma262/#sec-proxy.revocable
This patch also fixes a bug in Proxy where we
were incorrectly caching "in", i.e, `"x" in proxy`.
We should never blatantly cache this because caching is observable
behavior by users of the language. We could come up with
a smarter caching scheme that caches only if the Proxy's
handler doesn't have a "has" property, i.e, we don't have
to call out to JS code. But for now, it's easiest to disable
caching.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::moduleRecordStructure):
(JSC::JSGlobalObject::moduleNamespaceObjectStructure):
(JSC::JSGlobalObject::proxyObjectStructure):
(JSC::JSGlobalObject::proxyRevokeStructure):
(JSC::JSGlobalObject::wasmModuleStructure):
* runtime/ProxyConstructor.cpp:
(JSC::ProxyConstructor::create):
(JSC::ProxyConstructor::ProxyConstructor):
(JSC::makeRevocableProxy):
(JSC::proxyRevocableConstructorThrowError):
(JSC::ProxyConstructor::finishCreation):
(JSC::constructProxyObject):
* runtime/ProxyConstructor.h:
(JSC::ProxyConstructor::createStructure):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::finishCreation):
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::performPut):
(JSC::performProxyCall):
(JSC::performProxyConstruct):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::performPreventExtensions):
(JSC::ProxyObject::performIsExtensible):
(JSC::ProxyObject::performDefineOwnProperty):
(JSC::ProxyObject::performGetOwnPropertyNames):
(JSC::ProxyObject::performSetPrototype):
(JSC::ProxyObject::performGetPrototype):
(JSC::ProxyObject::getPrototype):
(JSC::ProxyObject::revoke):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
(JSC::ProxyObject::create):
* runtime/ProxyRevoke.cpp: Added.
(JSC::ProxyRevoke::create):
(JSC::ProxyRevoke::ProxyRevoke):
(JSC::ProxyRevoke::finishCreation):
(JSC::performProxyRevoke):
(JSC::ProxyRevoke::getCallData):
(JSC::ProxyRevoke::visitChildren):
* runtime/ProxyRevoke.h: Added.
(JSC::ProxyRevoke::createStructure):
(JSC::ProxyRevoke::proxy):
(JSC::ProxyRevoke::setProxyToNull):
* tests/stress/proxy-has-property.js:
(assert):
(assert.let.handler.has):
(assert.let.foo):
* tests/stress/proxy-revoke.js: Added.
(assert):
(throw.new.Error.):
(throw.new.Error):
(callAllHandlers):
(shouldThrowNullHandler):
(allHandlersShouldThrow):
(i.let.trap.of.traps.trap.string_appeared_here.func):
(i.let.trap.of.traps.else.func):
(i.Proxy.revocable):
2016-03-07 Csaba Osztrogonác <ossy@webkit.org>
Fix the ARM build after r197687
https://bugs.webkit.org/show_bug.cgi?id=155128
Reviewed by Saam Barati.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::moveZeroToDouble):
2016-03-07 Filip Pizlo <fpizlo@apple.com>
Reduce the number of instructions needed to record the last regexp result
https://bugs.webkit.org/show_bug.cgi?id=155161
Reviewed by Sam Weinig.
This tightens up RegExpCachedResult::record(). My profiling shows that we spend just
over 1% of the time in Octane/regexp in this function. This function had two obvious
redundancies:
1) It executed the write barrier on owner twice. It only needs to execute it once. Since
the same RegExpConstructor is likely to be used many times, it makes sense to do the
barrier without looking at the 'to' objects at all. In steady state, this means that
the RegExpConstructor will simply be OldGrey so this one barrier will always skip the
slow path.
2) It cleared some fields that didn't need to be cleared, since we can just use
m_reified to indicate that the fields are not meaningful anymore.
This is meant to be a microscopic regexp speed-up.
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::visitChildren):
(JSC::RegExpCachedResult::lastResult):
* runtime/RegExpCachedResult.h:
(JSC::RegExpCachedResult::record):
2016-03-07 Filip Pizlo <fpizlo@apple.com>
createRegExpMatchesArray should allocate substrings more quickly
https://bugs.webkit.org/show_bug.cgi?id=155160
Reviewed by Sam Weinig.
This was calling a version of jsSubstring() that isn't inlineable because it was doing a lot
of checks in finishCreation(). In particular, it was checking that the base string is not
itself a substring and that it's been resolved. We don't need those checks here, since the
string must have been resolved prior to regexp processing.
This patch is also smart about whether to do checks for the empty and full substrings. In
the matches array loop, these checks are super unlikely to be profitable, so we just
unconditionally allocate the substring.
This removes those checks and makes the allocation inlineable. It looks like a 1% speed-up
on Octane/regexp.
* runtime/JSString.h:
(JSC::jsSubstring):
(JSC::jsSubstringOfResolved):
* runtime/RegExpMatchesArray.cpp:
(JSC::createRegExpMatchesArray):
2016-03-07 Benjamin Poulain <bpoulain@apple.com>
[JSC] Small clean up of how we use SSA's valuesAtHead
https://bugs.webkit.org/show_bug.cgi?id=155152
Reviewed by Filip Pizlo.
liveAtHead and valuesAtHead contain the same nodes,
we do not need the extra look up.
This also opens the way to use the same kind of liveness
analysis as Air (where live values at head do not use a set).
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::beginBasicBlock):
(JSC::DFG::InPlaceAbstractState::merge):
2016-03-07 Brian Burg <bburg@apple.com>
Web Inspector: the protocol generator should generate factory method stubs for protocol types
https://bugs.webkit.org/show_bug.cgi?id=155103
<rdar://problem/25002772>
Reviewed by Timothy Hatcher.
Generate stubs with unique names so that parsing methods can be used
reflectively at runtime, based on the protocol version that's loaded.
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/scripts/codegen/__init__.py:
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
Added. For each type in a domain, add a method of the form
-[ProtocolTypeConversions _parseXXX:fromPayload]. This is in a category
method, and the selector is only ever looked up at runtime.
(ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
* inspector/scripts/generate-inspector-protocol-bindings.py:
(generate_from_specification):
Rebaseline test results with new generator output.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-03-07 Filip Pizlo <fpizlo@apple.com>
RegExp.prototype.exec() should call into Yarr at most once
https://bugs.webkit.org/show_bug.cgi?id=155139
Reviewed by Saam Barati.
For apparently no good reason, RegExp.prototype.match() was calling into Yarr twice, almost
as if it was hoping that the non-matching case was so common that it was best to have the
matching case do the work all over again.
This is a 4% speed-up on Octane/regexp. It's also a matter of common sense: we should not be
in the business of presuming whether someone's match will succeed or fail. The increased
cost of running Yarr twice is so much larger than whatever savings we were getting from
running a match-only regexp that this is just not a good overall deal for the engine.
Also, it's interesting that we are seeing a 4% speed-up on regexp despite the fact that a
majority (almost a supermajority, I think) of calls into RegExp.prototype.match() are failed
matches. So, this change is a 4% speed-up despite being a slow down on the common case. That
tells you just how bad the old behavior was on the uncommon case.
* runtime/MatchResult.h:
(MatchResult::MatchResult):
(MatchResult::failed):
(MatchResult::operator bool):
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::lastResult):
* runtime/RegExpConstructor.h:
(JSC::RegExpConstructor::setMultiline):
(JSC::RegExpConstructor::multiline):
(JSC::RegExpConstructor::performMatch):
(JSC::RegExpConstructor::recordMatch):
* runtime/RegExpMatchesArray.cpp:
(JSC::createRegExpMatchesArray):
(JSC::createEmptyRegExpMatchesArray):
(JSC::createStructureImpl):
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::put):
(JSC::getLastIndexAsUnsigned):
(JSC::RegExpObject::exec):
(JSC::RegExpObject::match):
* runtime/RegExpObject.h:
(JSC::RegExpObject::getLastIndex):
(JSC::RegExpObject::test):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncMatch):
2016-03-07 Joseph Pecoraro <pecoraro@apple.com>
Heap Snapshot should include different Edge types and data (Property, Index, Variable)
https://bugs.webkit.org/show_bug.cgi?id=154937
Reviewed by Geoffrey Garen.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendHidden):
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::appendHidden):
(JSC::SlotVisitor::appendValuesHidden):
Add new visit methods to visit a reference without snapshotting the edge.
* heap/Heap.cpp:
(JSC::AddExtraHeapSnapshotEdges::AddExtraHeapSnapshotEdges):
(JSC::AddExtraHeapSnapshotEdges::operator()):
(JSC::Heap::addHeapSnapshotEdges):
(JSC::Heap::removeDeadHeapSnapshotNodes):
(JSC::Heap::collectImpl):
* heap/Heap.h:
After marking, visit the live cells for a chance to record extra
heap snapshotting information about the cell.
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::appendNode):
(JSC::HeapSnapshotBuilder::appendEdge):
(JSC::HeapSnapshotBuilder::appendPropertyNameEdge):
(JSC::HeapSnapshotBuilder::appendVariableNameEdge):
(JSC::HeapSnapshotBuilder::appendIndexEdge):
(JSC::HeapSnapshotBuilder::json):
* heap/HeapSnapshotBuilder.h:
(JSC::HeapSnapshotEdge::HeapSnapshotEdge):
Construct edges with extra data.
* runtime/ClassInfo.h:
* runtime/JSCell.cpp:
(JSC::JSCell::heapSnapshot):
* runtime/JSCell.h:
Add a new method to provide cells with an opportunity to provide
extra heap snapshotting information.
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterfly):
(JSC::JSObject::visitChildren):
(JSC::JSObject::heapSnapshot):
(JSC::JSFinalObject::visitChildren):
* runtime/JSObject.h:
Capture object property names and index names when heap snapshotting.
Do not include them as internal edges in normal visitChildren.
* runtime/JSEnvironmentRecord.cpp:
(JSC::JSEnvironmentRecord::visitChildren):
(JSC::JSEnvironmentRecord::heapSnapshot):
* runtime/JSEnvironmentRecord.h:
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::visitChildren):
(JSC::JSSegmentedVariableObject::heapSnapshot):
* runtime/JSSegmentedVariableObject.h:
Capture scope variable names when heap snapshotting.
* runtime/Structure.cpp:
(JSC::Structure::visitChildren):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::propertyTable):
When performing a heap snapshotting collection, don't clear the
property table so that accessing the table during this GC is okay.
* tests/heapProfiler/driver/driver.js:
* tests/heapProfiler/property-edge-types.js: Added.
* tests/heapProfiler/variable-edge-types.js: Added.
Tests covering the different edge types and data we capture.
2016-03-07 Saam barati <sbarati@apple.com>
[ES6] Implement Proxy.[[GetPrototypeOf]]
https://bugs.webkit.org/show_bug.cgi?id=155099
Reviewed by Mark Lam.
This patch is a straight forward implementation of Proxy.[[GetPrototypeOf]]
with respect to section 9.5.1 of the ECMAScript spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-getprototypeof
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::setPrototype):
(JSC::ProxyObject::performGetPrototype):
(JSC::ProxyObject::getPrototype):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
* tests/es6.yaml:
* tests/stress/proxy-get-prototype-of.js: Added.
(assert):
(throw.new.Error.let.handler.get getPrototypeOf):
(throw.new.Error.get let):
(throw.new.Error.get catch):
(throw.new.Error):
(assert.let.handler.getPrototypeOf):
(assert.get let):
(assert.get catch):
(assert.):
(let.handler.getPrototypeOf):
(get let):
(let.handler.has):
2016-03-07 Brian Burg <bburg@apple.com>
Web Inspector: rename generated *EnumConversionHelpers.h to *TypeConversions.h
https://bugs.webkit.org/show_bug.cgi?id=155121
<rdar://problem/25010391>
Reviewed by Timothy Hatcher.
Split out this renaming from the work to generate factory method stubs for types.
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/scripts/codegen/__init__.py:
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCConfigurationImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objc_conversion_helpers.py.
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.generate_output):
* inspector/scripts/codegen/objc_generator_templates.py:
* inspector/scripts/generate-inspector-protocol-bindings.py:
(generate_from_specification):
Rebaseline tests after changing generator order.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-03-07 Benjamin Poulain <benjamin@webkit.org>
[JSC] Improve and64() and or64() with immediate on x86
https://bugs.webkit.org/show_bug.cgi?id=155104
Reviewed by Geoffrey Garen.
GetButterflyReadOnly was doing:
movq 0x8(%rbx), %r9
movq $0xfffffffffffffffc, %r11
andq %r11, %r9
There is no need for the move to load the immediate,
andq sign extend its immediate.
With this patch, we have:
movq 0x8(%rbx), %r9
andq $0xfffffffffffffffc, %r9
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::and64):
(JSC::MacroAssemblerX86_64::or64):
2016-03-07 Brian Burg <bburg@apple.com>
Web Inspector: It should be possible to initialize generated ObjC protocol types from an NSDictionary payload
https://bugs.webkit.org/show_bug.cgi?id=155102
<rdar://problem/25002015>
Reviewed by Timothy Hatcher.
In Objective-C code, we sometimes prefer to parse JSON using Cocoa rather
than the InspectorValue classes. Support initializing protocol objects
directly from an NSDictionary payload. This delegates validation of values to
the setter methods that already exist on the protocol object classes.
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator._generate_type_interface):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload):
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.payload_to_objc_expression_for_member):
Add a new helper method to generate an expression to unpack the value
from an NSDictionary. If it's not a primitive, the setter performs
validation of the value's kind using -[NSObject isKindOfClass:].
Rebaseline relevant tests.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-03-07 Benjamin Poulain <benjamin@webkit.org>
[JSC] Simplify the overflow check of ArithAbs
https://bugs.webkit.org/show_bug.cgi?id=155063
Reviewed by Geoffrey Garen.
The only integer that overflow abs(int32) is INT_MIN.
For some reason, our code testing for that case
was checking the top bit of the result specifically.
The code required a large immediate on x86 and an extra
register on ARM64.
This patch turns the overflow check into a branch on
the sign of the result.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileArithAbs):
* jit/ThunkGenerators.cpp:
(JSC::absThunkGenerator):
* tests/stress/arith-abs-overflow.js: Added.
(opaqueAbs):
2016-03-07 Benjamin Poulain <bpoulain@apple.com>
[JSC] Improve how DFG zero Floating Point registers
https://bugs.webkit.org/show_bug.cgi?id=155096
Reviewed by Geoffrey Garen.
DFG had a weird way of zeroing a FPR:
-zero a GP.
-move that to a FP.
Filip added moveZeroToDouble() for B3. This patch
uses that in the lower tiers.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::moveZeroToDouble):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
* jit/ThunkGenerators.cpp:
(JSC::floorThunkGenerator):
(JSC::roundThunkGenerator):
2016-03-07 Andreas Kling <akling@apple.com>
REGRESSION (r197303): Web Inspector crashes web process when inspecting an element on TOT
<https://webkit.org/b/154812>
Reviewed by Geoffrey Garen.
Guard against null pointer dereference for UnlinkedCodeBlocks that don't have any control flow
profiling data.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::hasOpProfileControlFlowBytecodeOffsets):
2016-03-07 Benjamin Poulain <benjamin@webkit.org>
[JSC] Remove a useless "Move" from baseline-JIT op_mul's fast path
https://bugs.webkit.org/show_bug.cgi?id=155071
Reviewed by Geoffrey Garen.
We do not need to multiply to a scratch and then move the result
to the destination. We can just multiply to the destination.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_mul):
* jit/JITMulGenerator.cpp:
(JSC::JITMulGenerator::generateFastPath):
2016-03-07 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] StringObject.{put, defineOwnProperty} should realize indexed properties
https://bugs.webkit.org/show_bug.cgi?id=155089
Reviewed by Geoffrey Garen.
Through implementing Reflect.set[1], we found StringObject does not obey the spec.
StringObject::put should call putByIndex if the given propertyName is index.
And StringObject::defineOwnProperty should recognize indexed properties since
JSObject::defineOwnIndexedProperty is specialized to JSObject layout.
Before calling JSObject::defineOwnProperty,
StringObject should handle its special indexed own properties.
It is responsibility of StringObject::defineOwnProperty.
And the logic is cleaned up by using validateAndApplyPropertyDescriptor.
[1]: https://bugs.webkit.org/show_bug.cgi?id=155024
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
(JSC::isStringOwnProperty):
(JSC::StringObject::defineOwnProperty):
(JSC::StringObject::deleteProperty):
* tests/stress/string-object-define-own-property.js: Added.
(shouldBe):
(shouldThrow):
* tests/stress/string-object-put-by-index.js: Added.
(shouldBe):
(shouldThrow):
(testSloppy):
(testStrict):
2016-03-06 Brian Burg <bburg@apple.com>
Web Inspector: the protocol generator should have separate prefix options for Objective-C classes and filenames
https://bugs.webkit.org/show_bug.cgi?id=155101
<rdar://problem/25000053>
Reviewed by Timothy Hatcher.
It should be possible to generate Objective-C protocol types without prefixing all class names.
The prefixes are only necessary when the generated files are part of a framework, but this isn't
how the generated Objective-C frontend files are used.
Add a separate framework setting and switch over code to use the 'protocol_group' in filenames,
and the 'objc_prefix' for Objective-C enum and class prefixes.
No tests need to be rebaselined because tests always set the protocol_group and objc_prefix
to the same value.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator.output_filename):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCConfigurationImplementationGenerator.output_filename):
(ObjCConfigurationImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_configuration_header.py:
(ObjCConfigurationHeaderGenerator.output_filename):
(ObjCConfigurationHeaderGenerator.generate_output):
(ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
* inspector/scripts/codegen/generate_objc_configuration_implementation.py:
(ObjCBackendDispatcherImplementationGenerator.output_filename):
(ObjCBackendDispatcherImplementationGenerator.generate_output):
(ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
* inspector/scripts/codegen/generate_objc_conversion_helpers.py:
(ObjCConversionHelpersGenerator.output_filename):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator.output_filename):
(ObjCFrontendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator.output_filename):
* inspector/scripts/codegen/generate_objc_internal_header.py:
(ObjCInternalHeaderGenerator.output_filename):
(ObjCInternalHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.output_filename):
(ObjCProtocolTypesImplementationGenerator.generate_output):
* inspector/scripts/codegen/models.py:
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator):
(ObjCGenerator.protocol_name):
(ObjCGenerator.objc_prefix):
2016-03-06 Brian Burg <bburg@apple.com>
Unreviewed, rebaseline inspector protocol generator tests after r197563.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2016-03-06 Benjamin Poulain <benjamin@webkit.org>
[JSC] Improve DFG's Int32 ArithMul if one operand is a constant
https://bugs.webkit.org/show_bug.cgi?id=155066
Reviewed by Filip Pizlo.
When multiplying an integer by a constant, DFG was doing quite
a bit worse than baseline JIT.
We were loading the constant into a register, doing the multiply,
the checking the result and both operands for negative zero.
This patch changes:
-Use the multiply-by-immediate form on x86.
-Do as few checks as possible to detect negative-zero.
In most cases, this reduce the negative-zero checks
to zero or one TEST+JUMP.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::mul32):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithMul):
2016-03-06 Benjamin Poulain <benjamin@webkit.org>
[JSC] Remove a superfluous Move in front of every double unboxing
https://bugs.webkit.org/show_bug.cgi?id=155064
Reviewed by Saam Barati.
Double unboxing was always doing:
Move source, scratch
Add64 tag, scratch
IntToDouble scratch, fp
We do not need to "Move" to copy the source.
Both x86 and ARM64 have an efficient 3 operands Add instruction.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
(JSC::DFG::SpeculativeJIT::speculateRealNumber):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::unboxDouble):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::unboxDoubleWithoutAssertions):
(JSC::AssemblyHelpers::unboxDouble):
(JSC::AssemblyHelpers::unboxDoubleNonDestructive):
2016-03-06 Benjamin Poulain <benjamin@webkit.org>
[JSC] Use 3 operands Add in more places
https://bugs.webkit.org/show_bug.cgi?id=155082
Reviewed by Filip Pizlo.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::addPtr):
(JSC::MacroAssembler::add32):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::add32):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithAdd):
The case with child1 constant is useless.
The canonical form will have the constant as child2.
Also add register reuse for the fast-add.
Registers are a scarce resource on x86.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::prepareForTailCallSlow):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generate):
2016-03-06 Benjamin Poulain <bpoulain@apple.com>
[JSC] Improve codegen of Compare and Test
https://bugs.webkit.org/show_bug.cgi?id=155055
Reviewed by Filip Pizlo.
This patch introduces a few improvements on how we lower
Compare and Test with immediates:
-Add certain Immediate forms of ARM64.
-Use CBZ/CBNZ when possible on ARM64.
-When possible, convert a CMP into a TST
On some hardware, we can issue more TST simultaneously.
On x86, any TST+Jump is candidate for macro-fusion.
They are also smaller.
(sections 3.4.2.2 and 3.5.1.9)
-Do not load the mask immediate of a TST
if it only contains ones (mostly useful for ARM64
since that would not have been a valid immediate).
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::compare32):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare):
(JSC::MacroAssemblerARM64::moveDoubleConditionallyAfterFloatingPointCompare):
This is somewhat unrelated but I found that out while working
on moveDoubleConditionallyTest32:
If "thenCase" and "dest" are assigned the same register
by the allocator, then the first (f)fcsel would override
the "thenCase" and the second fcsel would always be "elseCase".
This is covered by testb3 but was only uncovered
after recent "Move" removals in lowering.
(JSC::MacroAssemblerARM64::moveConditionally32):
(JSC::MacroAssemblerARM64::moveConditionally64):
(JSC::MacroAssemblerARM64::moveConditionallyTest32):
(JSC::MacroAssemblerARM64::moveDoubleConditionally32):
(JSC::MacroAssemblerARM64::moveDoubleConditionally64):
(JSC::MacroAssemblerARM64::moveDoubleConditionallyTest32):
(JSC::MacroAssemblerARM64::branch32):
(JSC::MacroAssemblerARM64::branch64):
(JSC::MacroAssemblerARM64::branchTest32):
(JSC::MacroAssemblerARM64::test32):
The version taking an immediate was guarded by
(cond == Zero) || (cond == NonZero). That is overzealous,
and only needed for CBZ/CBNZ.
(JSC::MacroAssemblerARM64::branchTest64):
(JSC::MacroAssemblerARM64::compare32):
(JSC::MacroAssemblerARM64::compare64):
(JSC::MacroAssemblerARM64::commuteCompareToZeroIntoTest):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::moveConditionally32):
(JSC::MacroAssemblerX86Common::moveConditionallyTest32):
(JSC::MacroAssemblerX86Common::branch32):
(JSC::MacroAssemblerX86Common::test32):
(JSC::MacroAssemblerX86Common::branchTest32):
(JSC::MacroAssemblerX86Common::compare32):
(JSC::MacroAssemblerX86Common::commuteCompareToZeroIntoTest):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::compare64):
(JSC::MacroAssemblerX86_64::branch64):
(JSC::MacroAssemblerX86_64::moveConditionally64):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createGenericCompare):
Unfortunately this cannot be abstracted by the MacroAssembler.
Those immediates are not valid, we have to pick the better
for right away.
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::int64Operands):
(JSC::B3::modelCompare):
(JSC::B3::testCompareImpl):
(JSC::B3::testCompare):
(JSC::B3::b3Pow):
(JSC::B3::testPowDoubleByIntegerLoop):
Some versions of pow(double, int) do not return
the exact same bits as our integer loop.
Added a new version to have the same behavior
as the B3 loop.
(JSC::B3::run):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileInt32Compare):
Comparing to an immediate is super common. Do not waste
a register for that!
2016-03-06 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix build. This was a messed up merge.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2016-03-06 Filip Pizlo <fpizlo@apple.com>
DFG should know how to speculate StringOrOther
https://bugs.webkit.org/show_bug.cgi?id=155094
Reviewed by Saam Barati.
Any code that processes the regexp matches array was previously doing a relatively expensive
Branch(Untyped:). This introduces a new use kind called StringOrOther, which is perfect for
code that loops over the matches array and branches on the entries being non-empty.
To do this, I needed to introduce code into the FTL that creates new blocks. We still had that
awful FTL_NEW_BLOCK idiom since the only way to debug LLVM IR was to ascribe names to basic
blocks. B3 IR is inherently more debuggable since unlike LLVM, B3 knows how to always respect
code origin, and it knows how to print the code origin nicely in the dumps. So, rather than
continue using FTL_NEW_BLOCK(m_out, ("things")), I replaced all of that stuff with
m_out.newBlock(). It's much nicer that way.
This is a tiny speed-up on Octane/regexp at best. I was hoping for more. Oh well.
* bytecode/SpeculatedType.h:
(JSC::isStringSpeculation):
(JSC::isStringOrOtherSpeculation):
(JSC::isSymbolSpeculation):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateString):
(JSC::DFG::Node::shouldSpeculateStringOrOther):
(JSC::DFG::Node::shouldSpeculateStringObject):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStringZeroLength):
(JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
(JSC::DFG::SpeculativeJIT::emitStringBranch):
(JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compileConstantStoragePointer):
(JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
(JSC::DFG::SpeculativeJIT::speculateString):
(JSC::DFG::SpeculativeJIT::speculateStringOrOther):
(JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileLogicalNot):
(JSC::DFG::SpeculativeJIT::emitBranch):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileLogicalNot):
(JSC::DFG::SpeculativeJIT::emitBranch):
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
(JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
(JSC::FTL::DFG::LowerDFGToB3::compileBooleanToNumber):
(JSC::FTL::DFG::LowerDFGToB3::compileToThis):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
(JSC::FTL::DFG::LowerDFGToB3::compileArithDiv):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMod):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMinOrMax):
(JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
(JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckStructure):
(JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure):
(JSC::FTL::DFG::LowerDFGToB3::compileGetById):
(JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
(JSC::FTL::DFG::LowerDFGToB3::compileArrayPop):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
(JSC::FTL::DFG::LowerDFGToB3::compileCopyRest):
(JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor):
(JSC::FTL::DFG::LowerDFGToB3::compileToPrimitive):
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileNotifyWrite):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
(JSC::FTL::DFG::LowerDFGToB3::compileIsString):
(JSC::FTL::DFG::LowerDFGToB3::compileIsObject):
(JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
(JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
(JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
(JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
(JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
(JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorStructurePname):
(JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorGenericPname):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckWatchdogTimer):
(JSC::FTL::DFG::LowerDFGToB3::checkStructure):
(JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32):
(JSC::FTL::DFG::LowerDFGToB3::checkInferredType):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
(JSC::FTL::DFG::LowerDFGToB3::loadVectorWithBarrier):
(JSC::FTL::DFG::LowerDFGToB3::copyBarrier):
(JSC::FTL::DFG::LowerDFGToB3::loadVectorReadOnly):
(JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
(JSC::FTL::DFG::LowerDFGToB3::nonSpeculativeCompare):
(JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
(JSC::FTL::DFG::LowerDFGToB3::allocateCell):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorageAndGetEnd):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
(JSC::FTL::DFG::LowerDFGToB3::contiguousPutByValOutOfBounds):
(JSC::FTL::DFG::LowerDFGToB3::switchString):
(JSC::FTL::DFG::LowerDFGToB3::switchStringRecurse):
(JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
(JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
(JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
(JSC::FTL::DFG::LowerDFGToB3::strictInt52ToJSValue):
(JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52):
(JSC::FTL::DFG::LowerDFGToB3::convertDoubleToInt32):
(JSC::FTL::DFG::LowerDFGToB3::speculate):
(JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther):
(JSC::FTL::DFG::LowerDFGToB3::speculateObjectOrOther):
(JSC::FTL::DFG::LowerDFGToB3::speculateString):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringOrOther):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringOrStringObject):
(JSC::FTL::DFG::LowerDFGToB3::speculateRealNumber):
(JSC::FTL::DFG::LowerDFGToB3::speculateNotStringVar):
(JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
(JSC::FTL::DFG::LowerDFGToB3::callCheck):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::initialize):
(JSC::FTL::Output::newBlock):
(JSC::FTL::Output::check):
* ftl/FTLOutput.h:
(JSC::FTL::Output::setFrequency):
(JSC::FTL::Output::insertNewBlocksBefore):
2016-03-06 Saam Barati <sbarati@apple.com>
[[GetPrototypeOf]] should be a fully virtual method in the method table
https://bugs.webkit.org/show_bug.cgi?id=155002
Reviewed by Filip Pizlo.
This patch makes us more consistent with how the ES6 specification models the
[[GetPrototypeOf]] trap. Moving this method into ClassInfo::methodTable
is a prerequisite for implementing Proxy.[[GetPrototypeOf]]. This patch
still allows directly accessing the prototype for situations where this
is the desired behavior. This is equivalent to getting the internal
[[Prototype]] field as described in the specification.
* API/JSObjectRef.cpp:
(JSObjectGetPrototype):
(JSObjectSetPrototype):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
(JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jsc.cpp:
(functionCreateProxy):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/ArrayPrototype.cpp:
(JSC::speciesConstructArray):
* runtime/ClassInfo.h:
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncBind):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototypeGetterCompare):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototypeGetterFormat):
* runtime/JSBoundFunction.cpp:
(JSC::hasInstanceBoundFunction):
(JSC::getBoundFunctionStructure):
(JSC::JSBoundFunction::create):
* runtime/JSBoundFunction.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCell.cpp:
(JSC::JSCell::setPrototype):
(JSC::JSCell::getPrototype):
* runtime/JSCell.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::hasLegacyProfiler):
(JSC::lastInPrototypeChain):
(JSC::JSGlobalObject::objectPrototypeIsSane):
(JSC::JSGlobalObject::arrayPrototypeChainIsSane):
(JSC::JSGlobalObject::stringPrototypeChainIsSane):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::finishCreation):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::GlobalFuncProtoGetterFunctor::GlobalFuncProtoGetterFunctor):
(JSC::GlobalFuncProtoGetterFunctor::operator()):
(JSC::globalFuncProtoGetter):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::getOwnPropertySlot):
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::setPrototype):
(JSC::JSObject::getPrototype):
(JSC::JSObject::defaultHasInstance):
(JSC::objectPrivateFuncInstanceOf):
(JSC::JSObject::getPropertyNames):
(JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
(JSC::JSObject::attemptToInterceptPutByIndexOnHole):
(JSC::JSObject::getGenericPropertyNames):
* runtime/JSObject.h:
(JSC::JSObject::finishCreation):
(JSC::JSObject::JSObject):
(JSC::JSObject::getPrototypeDirect):
(JSC::JSObject::getPrototype):
(JSC::JSObject::getOwnNonIndexPropertySlot):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::getNonIndexPropertySlot):
(JSC::JSObject::prototype): Deleted.
* runtime/JSObjectInlines.h:
(JSC::JSObject::canPerformFastPutInline):
* runtime/JSProxy.cpp:
(JSC::JSProxy::setTarget):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::constructTypedArrayView):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructorGetPrototypeOfFunctor::ObjectConstructorGetPrototypeOfFunctor):
(JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
(JSC::objectConstructorGetPrototypeOf):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncIsPrototypeOf):
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performSetPrototype):
* runtime/StructureInlines.h:
(JSC::Structure::isValid):
* tests/stress/proxy-has-property.js:
(assert.let.h1.has):
(assert.let.h2.has):
(assert):
2016-03-06 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r197645.
https://bugs.webkit.org/show_bug.cgi?id=155097
"Doesn't build properly when building entire webkit"
(Requested by saamyjoon on #webkit).
Reverted changeset:
"[[GetPrototypeOf]] should be a fully virtual method in the
method table"
https://bugs.webkit.org/show_bug.cgi?id=155002
http://trac.webkit.org/changeset/197645
2016-03-06 Saam barati <sbarati@apple.com>
[[GetPrototypeOf]] should be a fully virtual method in the method table
https://bugs.webkit.org/show_bug.cgi?id=155002
Reviewed by Filip Pizlo.
This patch makes us more consistent with how the ES6 specification models the
[[GetPrototypeOf]] trap. Moving this method into ClassInfo::methodTable
is a prerequisite for implementing Proxy.[[GetPrototypeOf]]. This patch
still allows directly accessing the prototype for situations where this
is the desired behavior. This is equivalent to getting the internal
[[Prototype]] field as described in the specification.
* API/JSObjectRef.cpp:
(JSObjectGetPrototype):
(JSObjectSetPrototype):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
(JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jsc.cpp:
(functionCreateProxy):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/ArrayPrototype.cpp:
(JSC::speciesConstructArray):
* runtime/ClassInfo.h:
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncBind):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototypeGetterCompare):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototypeGetterFormat):
* runtime/JSBoundFunction.cpp:
(JSC::hasInstanceBoundFunction):
(JSC::getBoundFunctionStructure):
(JSC::JSBoundFunction::create):
* runtime/JSBoundFunction.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCell.cpp:
(JSC::JSCell::setPrototype):
(JSC::JSCell::getPrototype):
* runtime/JSCell.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::hasLegacyProfiler):
(JSC::lastInPrototypeChain):
(JSC::JSGlobalObject::objectPrototypeIsSane):
(JSC::JSGlobalObject::arrayPrototypeChainIsSane):
(JSC::JSGlobalObject::stringPrototypeChainIsSane):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::finishCreation):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::GlobalFuncProtoGetterFunctor::GlobalFuncProtoGetterFunctor):
(JSC::GlobalFuncProtoGetterFunctor::operator()):
(JSC::globalFuncProtoGetter):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::getOwnPropertySlot):
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::setPrototype):
(JSC::JSObject::getPrototype):
(JSC::JSObject::defaultHasInstance):
(JSC::objectPrivateFuncInstanceOf):
(JSC::JSObject::getPropertyNames):
(JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
(JSC::JSObject::attemptToInterceptPutByIndexOnHole):
(JSC::JSObject::getGenericPropertyNames):
* runtime/JSObject.h:
(JSC::JSObject::finishCreation):
(JSC::JSObject::JSObject):
(JSC::JSObject::getPrototypeDirect):
(JSC::JSObject::getPrototype):
(JSC::JSObject::getOwnNonIndexPropertySlot):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::getNonIndexPropertySlot):
(JSC::JSObject::prototype): Deleted.
* runtime/JSObjectInlines.h:
(JSC::JSObject::canPerformFastPutInline):
* runtime/JSProxy.cpp:
(JSC::JSProxy::setTarget):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::constructTypedArrayView):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructorGetPrototypeOfFunctor::ObjectConstructorGetPrototypeOfFunctor):
(JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
(JSC::objectConstructorGetPrototypeOf):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncIsPrototypeOf):
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performSetPrototype):
* runtime/StructureInlines.h:
(JSC::Structure::isValid):
* tests/stress/proxy-has-property.js:
(assert.let.h1.has):
(assert.let.h2.has):
(assert):
2016-03-06 Filip Pizlo <fpizlo@apple.com>
RegExpMatchesArray doesn't know how to have a bad time
https://bugs.webkit.org/show_bug.cgi?id=155069
Reviewed by Yusuke Suzuki.
In trunk if we are having a bad time, the regexp matches array is still allocated with a
non-slow-put indexing shape, which makes it have the wrong behavior on indexed setters on
the prototype chain.
Getting this to work right requires introducing bad time code paths into the regexp matches
array. It also requires something more drastic: making this code not play games with the
global object. The code that creates the matches array needs to have the actual global
object of the regexp native function that it's logically created by.
This is totally different from how we've handled global objects in the past because it means
that the global object is not a constant. Normally we can make it a constant because a
script executable will know its global object. But with native functions, it's the function
instance that knows the global object - not the native executable. When we inline a native
intrinsic, we are guaranteed to know the native executable but we're not guaranteed to know
the functon instance. This means that the global object may be a variable that gets computed
by looking at the instance at run-time. So, the RegExpExec/RegExpTest nodes in DFG IR now
take a global object child. That also meant adding a new node type, GetGlobalObject, which
does the thing to the callee that CallFrame::lexicalGlobalObject() would have done.
Eventually, we'll probably have to make other native intrinsics also use GetGlobalObject. It
turns out that this really isn't so bad because usually it's constant-folded anyway, since
although the intrinsic code supports executable-based inlining (which leaves the callee
instance as an unknown), it happens rarely for intrinsics. So, conveying the global object
via a child isn't any worse than conveying it via meta-data, and it's probably better than
telling the inliner not to do executable-based inlining of native intrinsics. That would
have been a confusing special-case.
This is perf-neutral on my machines but it fixes a bug and it unlocks some interesting
possibilities. For example, RegExpExec can now make a firm promise about the type of array
it's creating.
This also contains some other changes:
- We are now using Structure::addPropertyTransition() in a lot of places even though it was
meant to be an internal method with a quirky contract - for example if only works if you
know that there is not existing transition. This relaxes this constraint.
- Restores the use of "*" for heap references in JSString.h. It's very unusual to have heap
references pointed at with "&", since we don't currently do that anywhere. The fact that
it was using the wrong reference type also meant that the code couldn't elegantly make use
of some our GC pointer helpers like jsCast<>.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::attemptToInlineCall):
(JSC::DFG::ByteCodeParser::handleMinMax):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileSkipScope):
(JSC::DFG::SpeculativeJIT::compileGetGlobalObject):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileSkipScope):
(JSC::FTL::DFG::LowerDFGToB3::compileGetGlobalObject):
(JSC::FTL::DFG::LowerDFGToB3::compileGetClosureVar):
(JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
(JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
(JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
* jit/JITOperations.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::haveABadTime):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
* runtime/JSObject.h:
(JSC::JSObject::putDirectInternal):
* runtime/JSString.h:
(JSC::jsString):
(JSC::jsSubstring):
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::lastResult):
* runtime/RegExpMatchesArray.cpp:
(JSC::tryCreateUninitializedRegExpMatchesArray):
(JSC::createRegExpMatchesArray):
(JSC::createStructureImpl):
(JSC::createRegExpMatchesArrayStructure):
(JSC::createRegExpMatchesArraySlowPutStructure):
* runtime/RegExpMatchesArray.h:
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::put):
(JSC::RegExpObject::exec):
(JSC::RegExpObject::match):
* runtime/RegExpObject.h:
(JSC::RegExpObject::getLastIndex):
(JSC::RegExpObject::test):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncTest):
(JSC::regExpProtoFuncExec):
(JSC::regExpProtoFuncCompile):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncMatch):
* runtime/Structure.cpp:
(JSC::Structure::suggestedArrayStorageTransition):
(JSC::Structure::addPropertyTransition):
(JSC::Structure::addNewPropertyTransition):
* runtime/Structure.h:
* tests/stress/regexp-matches-array-bad-time.js: Added.
* tests/stress/regexp-matches-array-slow-put.js: Added.
2016-03-06 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] RegExp#lastIndex should handle writable attribute when defining in defineOwnProperty path
https://bugs.webkit.org/show_bug.cgi?id=155093
Reviewed by Filip Pizlo.
Before this patch, `setLastIndex(ExecState* exec, size_t lastIndex)` always overwrites the existing value
regardless of writable attribute.
And when defining RegExp#lastIndex in defineOwnProperty, we need to define the value first
before making the attribute readonly. After changing the writable attribute, we cannot define the value.
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
* runtime/RegExpObject.h:
(JSC::RegExpObject::setLastIndex):
* tests/stress/regexp-last-index-writable.js: Added.
(shouldBe):
(shouldThrow):
(regExpLastIndex):
2016-03-05 Filip Pizlo <fpizlo@apple.com>
The most aggressive form of RegExpTest/RegExpExec should speculate more aggressively than just cell
https://bugs.webkit.org/show_bug.cgi?id=154900
Reviewed by Saam Barati.
These old operations used to speculate cell. That's what they did when they were first
introduced. That was probably about as good as they could do back then because we didn't have
very powerful checks. Now we have powerful checks, so we can do this right.
The most profitable thing to check is that child1 is a RegExpObject and child2 is a JSString.
Sometimes though, we will not know what child2 is even though we know that child1 is a
RegExpObject. So, this patch means that RegExpExec/RegExpTest have the following overloads:
RegExpExec(RegExpObject:, String:)
RegExpExec(RegExpObject:, Untyped:)
RegExpExec(Untyped:, Untyped:)
This shaves off some type checks in Octane/regexp. It also cleans up some problems in our
modeling of the effectfulness of these operations.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
(JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
* jit/JITOperations.h:
2016-03-05 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Support Reflect.construct
https://bugs.webkit.org/show_bug.cgi?id=147330
Reviewed by Saam Barati.
Based on Saam's r196868, this patch adds support for Reflect.construct.
This patch implements OrdinaryCreateFromConstructor[1] for fallback cases.
This path is rarely taken. For example,
Reflect.construct(function () { }, [], Map);
In this case, the `new.target` becomes `Map`.
So we should create an object that `__proto__` is `Map.prototype`.
And to allow forward declaration (and encouraging strong type checking), we change
ConstructType, CallType to C++11 enum class.
[1]: http://ecma-international.org/ecma-262/6.0/#sec-ordinarycreatefromconstructor
* API/JSCallbackConstructor.cpp:
(JSC::JSCallbackConstructor::getConstructData):
* API/JSCallbackFunction.cpp:
(JSC::JSCallbackFunction::getCallData):
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getConstructData):
(JSC::JSCallbackObject<Parent>::getCallData):
* API/JSObjectRef.cpp:
(JSObjectIsFunction):
(JSObjectCallAsFunction):
(JSObjectIsConstructor):
(JSObjectCallAsConstructor):
* API/ObjCCallbackFunction.mm:
(JSC::ObjCCallbackFunction::getCallData):
(JSC::ObjCCallbackFunction::getConstructData):
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
* bindings/ScriptValue.cpp:
(Deprecated::ScriptValue::isFunction):
* builtins/ReflectObject.js:
* dfg/DFGOperations.cpp:
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::createInjectedScript):
* interpreter/Interpreter.cpp:
(JSC::sizeOfVarargs):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::handleHostCall):
* runtime/ArrayConstructor.cpp:
(JSC::ArrayConstructor::getConstructData):
(JSC::ArrayConstructor::getCallData):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncToString):
(JSC::arrayProtoFuncToLocaleString):
(JSC::getLength): Deleted.
* runtime/BooleanConstructor.cpp:
(JSC::BooleanConstructor::getConstructData):
(JSC::BooleanConstructor::getCallData):
* runtime/CallData.cpp:
(JSC::call):
* runtime/CallData.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/ConstructData.cpp:
(JSC::construct):
* runtime/ConstructData.h:
* runtime/DateConstructor.cpp:
(JSC::DateConstructor::getConstructData):
(JSC::DateConstructor::getCallData):
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToJSON):
* runtime/Error.h:
(JSC::StrictModeTypeErrorFunction::getConstructData):
(JSC::StrictModeTypeErrorFunction::getCallData):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::getConstructData):
(JSC::ErrorConstructor::getCallData):
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue):
* runtime/FunctionConstructor.cpp:
(JSC::FunctionConstructor::getConstructData):
(JSC::FunctionConstructor::getCallData):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::getCallData):
(JSC::functionProtoFuncToString):
(JSC::functionProtoFuncBind):
* runtime/GeneratorFunctionConstructor.cpp:
(JSC::GeneratorFunctionConstructor::getCallData):
(JSC::GeneratorFunctionConstructor::getConstructData):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::getCallData):
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructor::getConstructData):
(JSC::IntlCollatorConstructor::getCallData):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructor::getConstructData):
(JSC::IntlDateTimeFormatConstructor::getCallData):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructor::getConstructData):
(JSC::IntlNumberFormatConstructor::getCallData):
* runtime/IteratorOperations.cpp:
(JSC::iteratorNext):
(JSC::iteratorClose):
* runtime/JSArray.h:
(JSC::getLength):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSArrayBufferConstructor::getConstructData):
(JSC::JSArrayBufferConstructor::getCallData):
* runtime/JSBoundFunction.cpp:
(JSC::boundFunctionCall):
(JSC::boundFunctionConstruct):
(JSC::JSBoundFunction::create):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::isFunction):
(JSC::JSValue::isConstructor):
* runtime/JSCell.cpp:
(JSC::JSCell::getCallData):
(JSC::JSCell::getConstructData):
* runtime/JSFunction.cpp:
(JSC::JSFunction::getCallData):
(JSC::JSFunction::getConstructData):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getConstructData):
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getCallData):
* runtime/JSInternalPromise.cpp:
(JSC::JSInternalPromise::then):
* runtime/JSInternalPromiseConstructor.cpp:
(JSC::JSInternalPromiseConstructor::getConstructData):
(JSC::JSInternalPromiseConstructor::getCallData):
* runtime/JSJob.cpp:
(JSC::JSJobMicrotask::run):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Stringifier):
(JSC::Stringifier::toJSONImpl):
(JSC::Stringifier::appendStringifiedValue):
(JSC::JSONProtoFuncParse):
* runtime/JSObject.cpp:
(JSC::callToPrimitiveFunction):
(JSC::JSObject::hasInstance):
(JSC::JSObject::getMethod):
* runtime/JSObject.h:
(JSC::getCallData):
(JSC::getConstructData):
* runtime/JSPromise.cpp:
(JSC::JSPromise::initialize):
* runtime/JSPromiseConstructor.cpp:
(JSC::JSPromiseConstructor::getConstructData):
(JSC::JSPromiseConstructor::getCallData):
* runtime/JSPromiseDeferred.cpp:
(JSC::newPromiseCapability):
(JSC::callFunction):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::constructTypedArrayView):
(JSC::JSTypedArrayViewConstructor::getConstructData):
(JSC::JSTypedArrayViewConstructor::getCallData):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
(JSC::MapConstructor::getConstructData):
(JSC::MapConstructor::getCallData):
* runtime/ModuleLoaderObject.cpp:
(JSC::ModuleLoaderObject::provide):
(JSC::ModuleLoaderObject::loadAndEvaluateModule):
(JSC::ModuleLoaderObject::loadModule):
(JSC::ModuleLoaderObject::linkAndEvaluateModule):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor::getConstructData):
(JSC::NativeErrorConstructor::getCallData):
* runtime/NullGetterFunction.cpp:
(JSC::NullGetterFunction::getCallData):
(JSC::NullGetterFunction::getConstructData):
* runtime/NullSetterFunction.cpp:
(JSC::NullSetterFunction::getCallData):
(JSC::NullSetterFunction::getConstructData):
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::getConstructData):
(JSC::NumberConstructor::getCallData):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::getConstructData):
(JSC::ObjectConstructor::getCallData):
(JSC::toPropertyDescriptor):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncDefineGetter):
(JSC::objectProtoFuncDefineSetter):
(JSC::objectProtoFuncToLocaleString):
* runtime/Operations.cpp:
(JSC::jsTypeStringForValue):
(JSC::jsIsObjectTypeOrNull):
(JSC::jsIsFunctionType):
* runtime/ProxyConstructor.cpp:
(JSC::ProxyConstructor::getConstructData):
(JSC::ProxyConstructor::getCallData):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::finishCreation):
(JSC::performProxyCall):
(JSC::ProxyObject::getCallData):
(JSC::performProxyConstruct):
(JSC::ProxyObject::getConstructData):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectConstruct):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::getConstructData):
(JSC::RegExpConstructor::getCallData):
* runtime/RuntimeType.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
(JSC::SetConstructor::getConstructData):
(JSC::SetConstructor::getCallData):
* runtime/StringConstructor.cpp:
(JSC::StringConstructor::getConstructData):
(JSC::StringConstructor::getCallData):
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
(JSC::operationStringProtoFuncReplaceRegExpString):
(JSC::replaceUsingStringSearch):
* runtime/SymbolConstructor.cpp:
(JSC::SymbolConstructor::getConstructData):
(JSC::SymbolConstructor::getCallData):
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
(JSC::WeakMapConstructor::getConstructData):
(JSC::WeakMapConstructor::getCallData):
* runtime/WeakSetConstructor.cpp:
(JSC::constructWeakSet):
(JSC::WeakSetConstructor::getConstructData):
(JSC::WeakSetConstructor::getCallData):
* tests/es6.yaml:
* tests/stress/reflect-construct.js: Added.
(shouldBe):
(shouldThrow):
(shouldThrow.array.get length):
(shouldThrow.array.get 0):
(array.get length):
(array.get 0):
(shouldBe.Reflect.construct):
(shouldBe.Reflect.construct.Hello):
(3.shouldBe.Reflect.construct.Hello):
(3.newTarget):
(0.shouldBe.Reflect.construct):
(shouldBe.A):
(shouldBe.B):
(nativeConstructorTest.DerivedMap):
(nativeConstructorTest.FailedMap):
(set noInline):
2016-03-04 Andreas Kling <akling@apple.com>
[iOS] Throw away compiled RegExp code when navigating to a new page.
<https://webkit.org/b/155015>
Reviewed by Anders Carlsson.
Add a mechanism to have the VM discard all RegExp bytecode and JIT code.
* runtime/VM.cpp:
(JSC::VM::deleteAllRegExpCode):
* runtime/VM.h:
2016-03-04 David Kilzer <ddkilzer@apple.com>
REGRESSION (r197531): JavaScriptCore ASan build fails due to weak external symbol
<http://webkit.org/b/155033>
<rdar://problem/24979661>
Reviewed by Alexey Proskuryakov.
* runtime/JSObject.cpp:
(JSC::JSObject::ordinaryToPrimitive): Don't mark this method
inline since it's also used in DatePrototype.cpp, and is
declared as a public class method.
* runtime/JSObject.h:
(JSC::JSObject::ordinaryToPrimitive): Don't export this method
since it is not used outside of JavaScriptCore.
2016-03-04 Alex Christensen <achristensen@webkit.org>
Remove vcxproj build system
https://bugs.webkit.org/show_bug.cgi?id=154388
Rubber-stamped by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.sln: Removed.
* JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: Removed.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Removed.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreCF.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreCFLite.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreDLL.cpp: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreDebug.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj.filters: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedCommon.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd: Removed.
* JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd: Removed.
* JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreProduction.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreRelease.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props: Removed.
* JavaScriptCore.vcxproj/build-generated-files.pl: Removed.
* JavaScriptCore.vcxproj/copy-files.cmd: Removed.
2016-03-04 Chris Dumez <cdumez@apple.com>
Location.reload should not be writable
https://bugs.webkit.org/show_bug.cgi?id=154989
Reviewed by Gavin Barraclough.
After r196770, operations marked as [Unforgeable] in the IDL (such as
Location.reload) are correctly reported as not writable by
Object.getOwnPropertyDescriptor(). Trying to set such property in JS
is correctly ignored (or throws in strict mode) if the object has
previously been reified. However, due to a bug in putEntry(), it was
still possible to override the property if the object was not reified
yet. This patch fixes the issue by checking in putEntry() that entries
that are functions are not ReadOnly before calling putDirect().
* runtime/Lookup.h:
(JSC::putEntry):
2016-03-04 Skachkov Oleksandr <gskachkov@gmail.com>
[ES6] Arrow function syntax. Lexical bind "super" inside of the arrow function in generator.
https://bugs.webkit.org/show_bug.cgi?id=152575
Reviewed by Yusuke Suzuki.
Added support of the 'SuperProperty' in arrow function within of the generator
method of class. Before patch parser did not recognize that current arrow function
is declated inside of the generator and raise SyntaxError.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::isGeneratorBoundary):
(JSC::Scope::setIsFunction):
(JSC::Scope::setIsGenerator):
(JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
* tests/stress/arrowfunction-lexical-bind-superproperty.js:
2016-03-03 Filip Pizlo <fpizlo@apple.com>
DFG/FTL should inline accesses to RegExpObject::m_lastIndex
https://bugs.webkit.org/show_bug.cgi?id=155003
Reviewed by Benjamin Poulain.
The Octane/regexp benchmark sets RegExps' lastIndex a lot. I could imagine this being
something that people want to do. Right now, I'm not convinced that making the RegExp object
be more plain-JS would be a good idea considering that pretty much all uses of it will
require some special compiler magic. Also, it's good that this patch teaches the compiler
how to reason about lastIndex since some of my other plans for regexp involve having the
compiler treat more regexp stuff as intrinsic.
This is a smaller Octane/regexp speed-up than I hoped - maybe around 1%. It's an enormous
speed-up on the microbenchmarks attached to this patch.
* dfg/DFGAbstractHeap.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.h:
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
(JSC::DFG::SpeculativeJIT::compileGetRegExpObjectLastIndex):
(JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* ftl/FTLAbstractHeapRepository.cpp:
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
(JSC::FTL::DFG::LowerDFGToB3::compileGetRegExpObjectLastIndex):
(JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
(JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
(JSC::FTL::DFG::LowerDFGToB3::lowObject):
(JSC::FTL::DFG::LowerDFGToB3::lowRegExpObject):
(JSC::FTL::DFG::LowerDFGToB3::lowString):
* runtime/RegExpObject.h:
(JSC::RegExpObject::createStructure):
(JSC::RegExpObject::offsetOfLastIndex):
2016-03-03 Chris Dumez <cdumez@apple.com>
Regression(r196770): Unable to use HipChat Mac app
https://bugs.webkit.org/show_bug.cgi?id=154999
<rdar://problem/24931959>
Reviewed by Darin Adler.
Add a setter to PutPropertySlot to override the 'isStrictMode' flag.
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::setStrictMode):
2016-03-03 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add support for MADD, MSUB and MNEG to Air
https://bugs.webkit.org/show_bug.cgi?id=154997
Reviewed by Filip Pizlo.
ARM64 can do an Add/Sub in the Multiply units.
LLVM was doing so but we lost that when switching to B3.
This patch adds those instructions in Air.
There are more ALUs than multiply units, thus we are more
likely to successfully schedule a Multiply+Add than 2 Multiply.
I am conservative and only emit a multiply-add if the value
can be interned. As far as I can tell from what is generated
by LLVM, that backend had the same rule.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::multiplyAdd32):
(JSC::MacroAssemblerARM64::multiplySub32):
(JSC::MacroAssemblerARM64::multiplyNeg32):
(JSC::MacroAssemblerARM64::multiplyAdd64):
(JSC::MacroAssemblerARM64::multiplySub64):
(JSC::MacroAssemblerARM64::multiplyNeg64):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::populateWithInterestingValues):
(JSC::B3::floatingPointOperands):
(JSC::B3::int64Operands):
(JSC::B3::int32Operands):
(JSC::B3::testMulAddArgsLeft):
(JSC::B3::testMulAddArgsRight):
(JSC::B3::testMulAddArgsLeft32):
(JSC::B3::testMulAddArgsRight32):
(JSC::B3::testMulSubArgsLeft):
(JSC::B3::testMulSubArgsRight):
(JSC::B3::testMulSubArgsLeft32):
(JSC::B3::testMulSubArgsRight32):
(JSC::B3::testMulNegArgs):
(JSC::B3::testMulNegArgs32):
(JSC::B3::run):
2016-03-03 Saam Barati <sbarati@apple.com>
[ES6] Implement Proxy.[[SetPrototypeOf]]
https://bugs.webkit.org/show_bug.cgi?id=154931
Reviewed by Ryosuke Niwa.
This patch is a straight forward implementation of Proxy.[[SetPrototypeOf]]
with respect to section 9.5.2 of the ECMAScript spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-setprototypeof-v
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::put):
(JSC::ProxyObject::getGenericPropertyNames):
(JSC::ProxyObject::performSetPrototype):
(JSC::ProxyObject::setPrototype):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
* tests/es6.yaml:
* tests/stress/proxy-set-prototype-of.js: Added.
(assert):
(throw.new.Error.let.handler.get setPrototypeOf):
(throw.new.Error.set let):
(throw.new.Error.set catch):
(throw.new.Error):
(assert.let.handler.setPrototypeOf):
(assert.set let):
(assert.set catch):
(let.handler.setPrototypeOf):
(set let):
(set catch):
2016-03-03 Keith Miller <keith_miller@apple.com>
JSArrayBuffers should be collected less aggressively
https://bugs.webkit.org/show_bug.cgi?id=154982
Reviewed by Geoffrey Garen.
We are currently too aggressive in our collection of ArrayBuffer wrappers.
There are three cases where we need to avoid collecting ArrayBuffer wrappers.
1. If the wrapper has custom properties.
2. If the wrapper is a subclass of ArrayBuffer.
3. If the wrapper is in a WeakMap/WeakSet.
Currently, we only pass the first case in WebCore and none in the jsc CLI.
This patch removes some optimizations that cause us to collect when we
should not. Namely, always skipping the object unless it has custom
properties. Additionally, in the case of subclassing, we also need a way
for custom JSArrayBuffer objects to register themselves as the wrapper for
an ArrayBuffer class.
Finally, this patch fixes an issue where views would not mark their ArrayBuffer
as an opaque root. This patch also moves an associated ASSERT that the
ArrayBuffer held by a view is not null in JSGenericTypedArrayView::visitChildren
into JSArrayBufferView::visitChildren, where we add the opaque root.
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::finishCreation):
(JSC::JSArrayBuffer::create):
(JSC::JSArrayBuffer::createWithoutWrapping):
* runtime/JSArrayBuffer.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::visitChildren):
* runtime/JSArrayBufferView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Deleted.
* runtime/SimpleTypedArrayController.cpp:
(JSC::SimpleTypedArrayController::toJS):
(JSC::SimpleTypedArrayController::registerWrapper):
(JSC::SimpleTypedArrayController::JSArrayBufferOwner::isReachableFromOpaqueRoots):
(JSC::SimpleTypedArrayController::JSArrayBufferOwner::finalize):
* runtime/SimpleTypedArrayController.h:
* runtime/TypedArrayController.h:
2016-03-03 Filip Pizlo <fpizlo@apple.com>
Octane/regexp's Exec function should benefit from array length accessor inlining
https://bugs.webkit.org/show_bug.cgi?id=154994
Reviewed by Benjamin Poulain.
It does:
var thingy = blahbitty.blah;
if (thingy)
foo = thingy.length;
So, 'thingy' is SpecArray | SpecOther, which prevents the array length accessor inlining from
kicking in. Our strategy for this elsewhere in the DFG is to allow a one-time speculation that
we won't see SpecOther, since *usually* we see SpecOther mixed with other stuff in cases like
this where there is some null check guarding the code.
This gives another slight speed-up on Octane/regexp.
* bytecode/SpeculatedType.h:
(JSC::isCellSpeculation):
(JSC::isCellOrOtherSpeculation):
(JSC::isNotCellSpeculation):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateCell):
(JSC::DFG::Node::shouldSpeculateCellOrOther):
(JSC::DFG::Node::shouldSpeculateNotCell):
2016-03-03 Saam Barati <sbarati@apple.com>
Add Proxy tests for exceptions that depend on an object being non-extensible and having configurable properties
https://bugs.webkit.org/show_bug.cgi?id=154745
Reviewed by Geoffrey Garen.
This patch is mostly an implementation of Proxy.[[OwnPropertyKeys]]
with respect to section 9.5.11 of the ECMAScript spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys
This patch also changes call sites of getOwnPropertyNames and
getPropertyNames to expect that an exception can be thrown.
* dfg/DFGOperations.cpp:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::iteratorEntries):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* runtime/IntlObject.cpp:
(JSC::supportedLocales):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::get):
(JSC::JSValue::put):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::Walker::walk):
* runtime/JSObject.cpp:
(JSC::JSObject::getPropertyNames):
(JSC::JSObject::getGenericPropertyNames):
* runtime/JSObject.h:
(JSC::makeIdentifier):
(JSC::createListFromArrayLike):
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/JSPropertyNameIterator.cpp:
(JSC::JSPropertyNameIterator::create):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/ObjectConstructor.cpp:
(JSC::defineProperties):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
(JSC::ownPropertyKeys):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::getOwnPropertySlotByIndex):
(JSC::ProxyObject::deleteProperty):
(JSC::ProxyObject::deletePropertyByIndex):
(JSC::ProxyObject::defineOwnProperty):
(JSC::ProxyObject::performGetOwnPropertyNames):
(JSC::ProxyObject::getOwnPropertyNames):
(JSC::ProxyObject::getOwnNonIndexPropertyNames):
(JSC::ProxyObject::getStructurePropertyNames):
(JSC::ProxyObject::getGenericPropertyNames):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
(JSC::ProxyObject::create):
(JSC::ProxyObject::createStructure):
* runtime/Structure.cpp:
(JSC::Structure::Structure):
(JSC::Structure::add):
(JSC::Structure::getPropertyNamesFromStructure):
(JSC::Structure::checkConsistency):
(JSC::Structure::canCachePropertyNameEnumerator):
(JSC::Structure::canAccessPropertiesQuicklyForEnumeration):
(JSC::Structure::canAccessPropertiesQuickly): Deleted.
* runtime/Structure.h:
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
* tests/es6.yaml:
* tests/stress/proxy-own-keys.js: Added.
(assert):
(throw.new.Error.let.handler.ownKeys):
(throw.new.Error):
(assert.let.handler.get ownKeys):
(assert.let.handler.ownKeys):
(let.handler.ownKeys):
(i.catch):
(shallowEq):
(let.handler.getOwnPropertyDescriptor):
(i.set assert):
(set add):
(set assert):
(set if):
2016-03-03 Keith Miller <keith_miller@apple.com>
Array prototype JS builtins should support Symbol.species
https://bugs.webkit.org/show_bug.cgi?id=154710
Reviewed by Geoffrey Garen.
Add support for Symbol.species in the Array.prototype JS
builtin functions.
* builtins/ArrayPrototype.js:
(filter):
(map):
* runtime/ArrayConstructor.cpp:
(JSC::ArrayConstructor::finishCreation):
(JSC::arrayConstructorPrivateFuncIsArrayConstructor):
* runtime/ArrayConstructor.h:
(JSC::ArrayConstructor::create):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* tests/stress/array-species-functions.js:
(id):
2016-03-03 Michael Saboff <msaboff@apple.com>
[ES6] Make Unicode RegExp pattern parsing conform to the spec
https://bugs.webkit.org/show_bug.cgi?id=154988
Reviewed by Benjamin Poulain.
Updated RegExp pattern processing with 'u' (Unicode) flag to conform to the
spec (https://tc39.github.io/ecma262/2016/#sec-patterns). In the spec, the
grammar is annotated with [U] annotations. Productions that are prefixed with
[+U] are only available with the Unicode flags while productions prefixed with
[~U] are only available without the Unicode flag.
Added flags argument to Yarr::checkSyntax() so we can catch Unicode flag related
parsing errors at syntax checking time. Restricted what escapes are available for
non Unicode patterns. Most of this is defined in the IdentityEscape rule in the
pattern grammar.
Added \- as a CharacterClass only escape in Unicode patterns.
Updated the tests for these changes.
Made changes suggested in https://bugs.webkit.org/show_bug.cgi?id=154842#c22 after
change set r197426 was landed.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createRegExp):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parsePrimaryExpression):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createRegExp):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::InputStream::readChecked):
(JSC::Yarr::Interpreter::InputStream::readSurrogatePairChecked):
(JSC::Yarr::Interpreter::InputStream::reread):
(JSC::Yarr::Interpreter::InputStream::uncheckInput):
(JSC::Yarr::Interpreter::InputStream::atStart):
(JSC::Yarr::Interpreter::InputStream::atEnd):
(JSC::Yarr::Interpreter::testCharacterClass):
(JSC::Yarr::Interpreter::backtrackPatternCharacter):
(JSC::Yarr::Interpreter::matchDisjunction):
(JSC::Yarr::ByteCompiler::atomPatternCharacter):
* yarr/YarrParser.h:
(JSC::Yarr::Parser::Parser):
(JSC::Yarr::Parser::isIdentityEscapeAnError):
(JSC::Yarr::Parser::parseEscape):
(JSC::Yarr::Parser::parse):
* yarr/YarrPattern.cpp:
(JSC::Yarr::CharacterClassConstructor::putChar):
(JSC::Yarr::CharacterClassConstructor::putRange):
(JSC::Yarr::CharacterClassConstructor::addSorted):
(JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets):
* yarr/YarrSyntaxChecker.cpp:
(JSC::Yarr::SyntaxChecker::disjunction):
(JSC::Yarr::checkSyntax):
* yarr/YarrSyntaxChecker.h:
2016-03-03 Saam barati <sbarati@apple.com>
[ES6] Implement Proxy.[[DefineOwnProperty]]
https://bugs.webkit.org/show_bug.cgi?id=154759
Reviewed by Geoffrey Garen and Mark Lam.
This patch is a straight forward implementation of Proxy.[[DefineOwnProperty]]
with respect to section 9.5.6 of the ECMAScript spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-defineownproperty-p-desc
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorGetOwnPropertyDescriptors):
* runtime/ObjectConstructor.h:
(JSC::constructEmptyObject):
(JSC::constructObjectFromPropertyDescriptor):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::isExtensible):
(JSC::ProxyObject::performDefineOwnProperty):
(JSC::ProxyObject::defineOwnProperty):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
* tests/es6.yaml:
* tests/stress/proxy-define-own-property.js: Added.
(assert):
(throw.new.Error):
(assert.let.handler.get defineProperty):
(assert.let.handler.defineProperty):
(let.handler.defineProperty):
(i.catch):
(assert.try.):
(assert.set get catch):
(assert.let.setter):
(assert.let.getter):
(assert.set get let.handler.defineProperty):
(assert.set get let):
(assert.):
2016-03-03 Keith Miller <keith_miller@apple.com>
[ES6] Add support for Symbol.toPrimitive
https://bugs.webkit.org/show_bug.cgi?id=154877
Reviewed by Saam Barati.
This patch adds suport for Symbol.toPrimitive. Since we don't currently
generate snippits for one side of a binary operation we only need to change
the JSObject::ToPrimitive function and update some optimizations in the DFG
that need to know how conversions to primitive values should work. As of
ES6, the date prototype is also no longer special cased in the ToPrimitive
operation. Instead, Date.prototype has a Symbol.species function that
replicates the old behavior.
* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::generateConditionsForPropertyMissConcurrently):
* bytecode/ObjectPropertyConditionSet.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::watchConditions):
(JSC::DFG::Graph::canOptimizeStringObjectAccess):
* dfg/DFGGraph.h:
* runtime/CommonIdentifiers.h:
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
(JSC::dateProtoFuncToPrimitiveSymbol):
* runtime/Error.cpp:
(JSC::throwTypeError):
* runtime/Error.h:
* runtime/JSCJSValueInlines.h:
(JSC::toPreferredPrimitiveType):
* runtime/JSObject.cpp:
(JSC::callToPrimitiveFunction):
(JSC::JSObject::ordinaryToPrimitive):
(JSC::JSObject::defaultValue):
(JSC::JSObject::toPrimitive):
(JSC::JSObject::getPrimitiveNumber):
(JSC::callDefaultValueFunction): Deleted.
(JSC::throwTypeError): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::toPrimitive): Deleted.
* runtime/SmallStrings.h:
* runtime/SymbolPrototype.cpp:
(JSC::SymbolPrototype::finishCreation):
* runtime/SymbolPrototype.h:
(JSC::SymbolPrototype::create):
* tests/es6.yaml:
* tests/stress/date-symbol-toprimitive.js: Added.
* tests/stress/ropes-symbol-toprimitive.js: Added.
(ropify):
(String.prototype.Symbol.toPrimitive):
* tests/stress/symbol-toprimitive.js: Added.
(foo.Symbol.toPrimitive):
(catch):
2016-03-03 Filip Pizlo <fpizlo@apple.com>
DFG should be able to compile StringReplace
https://bugs.webkit.org/show_bug.cgi?id=154979
Reviewed by Benjamin Poulain.
Adds support for StringReplace to the DFG tier. This is a 3% speed-up on Octane/regexp.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateFinalObject):
(JSC::DFG::SpeculativeJIT::speculateRegExpObject):
(JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JITOperations.h:
2016-03-03 Saam barati <sbarati@apple.com>
[[SetPrototypeOf]] isn't properly implemented everywhere
https://bugs.webkit.org/show_bug.cgi?id=154943
Reviewed by Benjamin Poulain.
We were copy-pasting implememntation bits that belong in OrdinarySetPrototypeOf
in a few different places that call O.[[SetPrototypeOf]](v)
rather than having those bits in OrdinarySetPrototypeOf itself.
We need to put those copy-pasted bits into OrdinarySetPrototypeOf
and not the call sites of O.[[SetPrototypeOf]](v) because
O.[[SetPrototypeOf]](v) won't always call into OrdinarySetPrototypeOf.
This is needed for correctness because this behavior is now observable
with the ES6 Proxy object.
* runtime/ClassInfo.h:
* runtime/JSCell.cpp:
(JSC::JSCell::isExtensible):
(JSC::JSCell::setPrototype):
* runtime/JSCell.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoSetter):
* runtime/JSObject.cpp:
(JSC::JSObject::setPrototypeDirect):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::setPrototype):
(JSC::JSObject::allowsAccessFrom):
* runtime/JSObject.h:
(JSC::JSObject::mayInterceptIndexedAccesses):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSetPrototypeOf):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectSetPrototypeOf):
2016-03-03 Alex Christensen <achristensen@webkit.org>
Fix Windows build after r197489.
* jsc.cpp:
2016-03-02 Filip Pizlo <fpizlo@apple.com>
RegExpExec/RegExpTest should not unconditionally speculate cell
https://bugs.webkit.org/show_bug.cgi?id=154901
Reviewed by Benjamin Poulain.
This is a three part change. It all started with a simple goal: end the rage-recompiles in
Octane/regexp by enabling the DFG and FTL to do untyped RegExpExec/RegExpTest. This keeps us
in the optimized code when you do a regexp match on a number, for example.
While implementing this, I realized that DFGOperations.cpp was bad at exception checking. When
it did check for exceptions, it used exec->hadException() instead of vm.exception(). So I
fixed that. I also made sure that the regexp operations checked for exception after doing
toString().
Unfortunately, the introduction of untyped RegExpExec/RegExpTest caused a regression on
Octane/regexp. This was because we were simultaneously scheduling replacement and OSR compiles
of some large functions with the FTL JIT. The OSR compiles were not useful. This was a
regression from the previous changes to make OSR compiles happen sooner. The problem is that
this change also removed the throttling of OSR compiles even in those cases where we suspect
that replacement is more likely. This patch reintroduces that throttling, but only in the
replacement path.
This change ends up being neutral overall.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
(JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
(JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
* tests/stress/regexp-exec-effect-after-exception.js: Added.
2016-03-02 Benjamin Poulain <bpoulain@apple.com>
[JSC] JSCell_freeListNext and JSCell_structureID are considered not overlapping
https://bugs.webkit.org/show_bug.cgi?id=154947
Reviewed by Filip Pizlo.
This bug was discovered while testing https://bugs.webkit.org/show_bug.cgi?id=154894.
The problem was that JSCell_freeListNext and JSCell_structureID were
considered as disjoint. When reordering instructions, the scheduler
could move the write of the StructureID first to reduce dependencies.
This would erase half of JSCell_freeListNext before we get a chance
to load the value.
This patch changes the hierarchy to make sure nothing is written
until JSCell_freeListNext is processed.
All credits for this patch go to Filip.
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
2016-03-02 Benjamin Poulain <bpoulain@apple.com>
[JSC] Improve Select of Doubles based on Double condition
https://bugs.webkit.org/show_bug.cgi?id=154572
Reviewed by Filip Pizlo.
Octane has a bunch of Select on Double based on comparing Doubles.
A few nodes generate that: ValueRep, Min, Max, etc.
On ARM64, we can improve our code a lot. ARM can do a select
based on flags with the FCSEL instruction.
On x86, this patch adds aggressive aliasing for moveDoubleConditionallyXXX.
This has obviously a much more limited impact.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::moveDoubleConditionally32): Deleted.
(JSC::MacroAssembler::moveDoubleConditionally64): Deleted.
(JSC::MacroAssembler::moveDoubleConditionallyTest32): Deleted.
(JSC::MacroAssembler::moveDoubleConditionallyTest64): Deleted.
(JSC::MacroAssembler::moveDoubleConditionallyDouble): Deleted.
(JSC::MacroAssembler::moveDoubleConditionallyFloat): Deleted.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::moveDoubleConditionallyAfterFloatingPointCompare):
(JSC::MacroAssemblerARM64::moveDoubleConditionallyDouble):
(JSC::MacroAssemblerARM64::moveDoubleConditionallyFloat):
(JSC::MacroAssemblerARM64::moveConditionally32):
(JSC::MacroAssemblerARM64::moveDoubleConditionally32):
(JSC::MacroAssemblerARM64::moveDoubleConditionally64):
(JSC::MacroAssemblerARM64::moveDoubleConditionallyTest32):
(JSC::MacroAssemblerARM64::moveDoubleConditionallyTest64):
(JSC::MacroAssemblerARM64::branch64):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::moveConditionally32):
(JSC::MacroAssemblerX86Common::moveDoubleConditionally32):
(JSC::MacroAssemblerX86Common::moveDoubleConditionallyTest32):
(JSC::MacroAssemblerX86Common::moveDoubleConditionallyDouble):
(JSC::MacroAssemblerX86Common::moveDoubleConditionallyFloat):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::moveDoubleConditionally64):
(JSC::MacroAssemblerX86_64::moveDoubleConditionallyTest64):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::shouldTryAliasingDef):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::populateWithInterestingValues):
(JSC::B3::floatingPointOperands):
(JSC::B3::int64Operands):
(JSC::B3::int32Operands):
(JSC::B3::testSelectCompareFloat):
(JSC::B3::testSelectCompareFloatToDouble):
(JSC::B3::testSelectDoubleCompareDouble):
(JSC::B3::testSelectDoubleCompareDoubleWithAliasing):
(JSC::B3::testSelectFloatCompareFloat):
(JSC::B3::testSelectFloatCompareFloatWithAliasing):
(JSC::B3::run):
2016-03-02 Joseph Pecoraro <pecoraro@apple.com>
Add ability to generate a Heap Snapshot
https://bugs.webkit.org/show_bug.cgi?id=154847
Reviewed by Mark Lam.
This adds HeapSnapshot, HeapSnapshotBuilder, and HeapProfiler.
HeapProfiler hangs off of the VM and holds the list of snapshots.
I expect to add other HeapProfiling features, such as allocation
tracking, to the profiler.
HeapSnapshot contains a collection of live cells and their identifiers.
It can point to a previous HeapSnapshot, to ensure that a cell that
already received an identifier maintains the same identifier across
multiple snapshots. When a snapshotted cell gets garbage collected,
the cell will be swept from the HeapSnapshot at the end of collection
to ensure the list contains only live cells.
When building a HeapSnapshot nodes are added in increasing node
identifier order. When done building, the list of nodes is complete
and the snapshot is finalized. At this point the nodes are sorted
by JSCell* address to allow for quick lookup of a JSCell*.
HeapSnapshotBuilder is where snapshotting begins. The builder
will initiate a specialized heap snapshotting garbage collection.
During this collection the builder will be notified of all marked
(live) cells, and connections between cells, as seen by SlotVisitors.
The builder can reference the previous, readonly, HeapSnapshots to
avoid creating new nodes for cells that have already been snapshotted.
When it is determined that we are visiting a live cell for the first
time, we give the cell a unique identifier and add it to the the
snapshot we are building.
Since edge data is costly, and of little long term utility, this
data is only held by the builder for serialization, and not stored
long term with the HeapSnapshot node data.
The goals of HeapSnapshotting at this time are:
- minimal impact on performance when not profiling the heap
- unique identifier for cells, so they may be identified across multiple snapshots
- nodes and edges to be able to construct a graph of which nodes reference/retain which other nodes
- node data - identifier, type (class name), size
- edge data - from cell, to cell, type / data (to come in a follow-up patch)
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
Add new files to the build.
* heap/Heap.cpp:
(JSC::Heap::isHeapSnapshotting):
(JSC::RemoveDeadHeapSnapshotNodes::RemoveDeadHeapSnapshotNodes):
(JSC::RemoveDeadHeapSnapshotNodes::operator()):
(JSC::Heap::removeDeadHeapSnapshotNodes):
(JSC::Heap::collectImpl):
After every collection, sweep dead cells from in memory snapshots.
* runtime/VM.cpp:
(JSC::VM::ensureHeapProfiler):
* runtime/VM.h:
(JSC::VM::heapProfiler):
* heap/Heap.h:
* heap/HeapProfiler.cpp: Added.
(JSC::HeapProfiler::HeapProfiler):
(JSC::HeapProfiler::~HeapProfiler):
(JSC::HeapProfiler::mostRecentSnapshot):
(JSC::HeapProfiler::appendSnapshot):
(JSC::HeapProfiler::clearSnapshots):
(JSC::HeapProfiler::setActiveSnapshotBuilder):
* heap/HeapProfiler.h: Added.
(JSC::HeapProfiler::vm):
(JSC::HeapProfiler::activeSnapshotBuilder):
VM and Heap can look at the profiler to determine if we are building a
snapshot, or the "head" snapshot to use for sweeping.
* heap/HeapSnapshot.cpp: Added.
(JSC::HeapSnapshot::HeapSnapshot):
(JSC::HeapSnapshot::~HeapSnapshot):
(JSC::HeapSnapshot::appendNode):
Add a node to the unfinalized list of new cells.
(JSC::HeapSnapshot::sweepCell):
(JSC::HeapSnapshot::shrinkToFit):
Collect a list of cells for sweeping and then remove them all at once
in shrinkToFit. This is done to avoid thrashing of individual removes
that could cause many overlapping moves within the Vector.
(JSC::HeapSnapshot::finalize):
Sort the list, and also cache the bounding start/stop identifiers.
No other snapshot can contain an identifier in this range, so it will
improve lookup of a node from an identifier.
(JSC::HeapSnapshot::nodeForCell):
(JSC::HeapSnapshot::nodeForObjectIdentifier):
Search helpers.
* heap/HeapSnapshotBuilder.h: Added.
(JSC::HeapSnapshotNode::HeapSnapshotNode):
(JSC::HeapSnapshotEdge::HeapSnapshotEdge):
Node and Edge struct types the builder creates.
* heap/HeapSnapshotBuilder.cpp: Added.
(JSC::HeapSnapshotBuilder::getNextObjectIdentifier):
(JSC::HeapSnapshotBuilder::HeapSnapshotBuilder):
(JSC::HeapSnapshotBuilder::~HeapSnapshotBuilder):
(JSC::HeapSnapshotBuilder::buildSnapshot):
(JSC::HeapSnapshotBuilder::appendNode):
(JSC::HeapSnapshotBuilder::appendEdge):
When building the snapshot, generating the next identifier, and
appending to any of the lists must be guarded by a lock because
SlotVisitors running in parallel may be accessing the builder.
(JSC::HeapSnapshotBuilder::hasExistingNodeForCell):
Looking up if a node already exists in a previous snapshot can be
done without a lock because at this point the data is readonly.
(JSC::edgeTypeToNumber):
(JSC::edgeTypeToString):
(JSC::HeapSnapshotBuilder::json):
JSON serialization of a heap snapshot contains node and edge data.
* heap/SlotVisitor.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didStartMarking):
(JSC::SlotVisitor::reset):
Set/clear the active snapshot builder to know if this will be a
snapshotting GC or not.
(JSC::SlotVisitor::append):
(JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
Inform the builder of a new node or edge.
(JSC::SlotVisitor::visitChildren):
Remember the current cell we are visiting so that if we need to
inform the builder of edges we know the "from" cell.
* jsc.cpp:
(SimpleObject::SimpleObject):
(SimpleObject::create):
(SimpleObject::finishCreation):
(SimpleObject::visitChildren):
(SimpleObject::createStructure):
(SimpleObject::hiddenValue):
(SimpleObject::setHiddenValue):
Create a new class "SimpleObject" that can be used by heap snapshotting
tests. It is easy to filter for this new class name and test internal
edge relationships created by garbage collection visiting the cell.
(functionCreateSimpleObject):
(functionGetHiddenValue):
(functionSetHiddenValue):
Expose methods to create and interact with a SimpleObject.
(functionGenerateHeapSnapshot):
Expose methods to create a heap snapshot. This currently automatically
turns the serialized string into a JSON object. That may change.
* tests/heapProfiler.yaml: Added.
* tests/heapProfiler/basic-edges.js: Added.
(excludeStructure):
* tests/heapProfiler/basic-nodes.js: Added.
(hasDifferentSizeNodes):
(hasAllInternalNodes):
Add tests for basic node and edge data.
* tests/heapProfiler/driver/driver.js: Added.
(assert):
(CheapHeapSnapshotNode):
(CheapHeapSnapshotEdge):
(CheapHeapSnapshotEdge.prototype.get from):
(CheapHeapSnapshotEdge.prototype.get to):
(CheapHeapSnapshot):
(CheapHeapSnapshot.prototype.get nodes):
(CheapHeapSnapshot.prototype.get edges):
(CheapHeapSnapshot.prototype.nodeWithIdentifier):
(CheapHeapSnapshot.prototype.nodesWithClassName):
(CheapHeapSnapshot.prototype.classNameFromTableIndex):
(CheapHeapSnapshot.prototype.edgeTypeFromTableIndex):
(createCheapHeapSnapshot):
(HeapSnapshotNode):
(HeapSnapshotEdge):
(HeapSnapshot):
(HeapSnapshot.prototype.nodesWithClassName):
(createHeapSnapshot):
Add two HeapSnapshot representations.
CheapHeapSnapshot creates two lists of node and edge data that
lazily creates objects as needed.
HeapSnapshot creates an object for each node and edge. This
is wasteful but easier to use.
2016-03-02 Filip Pizlo <fpizlo@apple.com>
RegExpPrototype should check for exceptions after calling toString and doing so should not be expensive
https://bugs.webkit.org/show_bug.cgi?id=154927
Reviewed by Saam Barati.
While working on regexp optimizations, I found that RegExpPrototype calls toString(), an
effectful operation that could do anything, without then checking for hadException().
So I added a call to hadException().
But that regressed Octane/regexp by 5%! That's a lot! It turns out that
exec->hadException() is soooper slow. So, I made it cheaper to check for exceptions from
toString(): there is now a variant called toStringFast() that returns null iff it throws an
exception.
This allowed me to add the exception check without regressing perf.
Note that toString() must retain its old behavior of returning an empty string on exception.
There is just too much code that relies on that behavior.
* runtime/JSCJSValue.cpp:
(JSC::JSValue::isValidCallee):
(JSC::JSValue::toStringSlowCase):
(JSC::JSValue::toWTFStringSlowCase):
* runtime/JSCJSValue.h:
(JSC::JSValue::asValue):
* runtime/JSString.h:
(JSC::JSValue::toString):
(JSC::JSValue::toStringFast):
(JSC::JSValue::toWTFString):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncTest):
(JSC::regExpProtoFuncExec):
(JSC::regExpProtoFuncCompile):
2016-03-02 Saam barati <sbarati@apple.com>
clean up JSObject::isExtensibleInline and JSObject::setPrototypeOfInline, and rename setPrototypeOf to setPrototype
https://bugs.webkit.org/show_bug.cgi?id=154942
Reviewed by Benjamin Poulain.
These don't need to be inlined in the way they are.
Doing dynamic dispatch is ok performance wise until
we have evidence stating otherwise.
* API/JSObjectRef.cpp:
(JSObjectSetPrototype):
(JSObjectHasProperty):
* runtime/ClassInfo.h:
* runtime/IntlCollatorConstructor.cpp:
(JSC::constructIntlCollator):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::constructIntlDateTimeFormat):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::constructIntlNumberFormat):
* runtime/JSCell.cpp:
(JSC::JSCell::isExtensible):
(JSC::JSCell::setPrototype):
(JSC::JSCell::setPrototypeOf): Deleted.
* runtime/JSCell.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoSetter):
* runtime/JSObject.cpp:
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::setPrototype):
(JSC::JSObject::allowsAccessFrom):
(JSC::JSObject::isExtensible):
(JSC::JSObject::reifyAllStaticProperties):
(JSC::JSObject::defineOwnNonIndexProperty):
(JSC::JSObject::setPrototypeOf): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::mayInterceptIndexedAccesses):
(JSC::JSObject::indexingShouldBeSparse):
(JSC::JSObject::setPrototypeOfInline): Deleted.
(JSC::JSObject::isExtensibleInline): Deleted.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSetPrototypeOf):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
(JSC::objectConstructorIsExtensible):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::performPreventExtensions):
(JSC::ProxyObject::performIsExtensible):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectIsExtensible):
(JSC::reflectObjectSetPrototypeOf):
* runtime/StringObject.cpp:
(JSC::StringObject::defineOwnProperty):
2016-03-02 Konstantin Tokarev <annulen@yandex.ru>
[cmake] Moved PRE/POST_BUILD_COMMAND to WEBKIT_FRAMEWORK.
https://bugs.webkit.org/show_bug.cgi?id=154651
Reviewed by Alex Christensen.
* CMakeLists.txt: Moved shared code to WEBKIT_FRAMEWORK macro.
2016-03-02 Saam barati <sbarati@apple.com>
[[SetPrototypeOf]] should be a fully virtual method in ClassInfo::methodTable
https://bugs.webkit.org/show_bug.cgi?id=154897
Reviewed by Filip Pizlo.
This patch makes us more consistent with how the ES6 specification models the
[[SetPrototypeOf]] trap. Moving this method into ClassInfo::methodTable
is a prerequisite for implementing Proxy.[[SetPrototypeOf]]. This patch
still allows directly setting the prototype for situations where this
is the desired behavior. This is equivalent to setting the internal
[[Prototype]] field as described in the specification.
* API/JSClassRef.cpp:
(OpaqueJSClass::prototype):
* API/JSObjectRef.cpp:
(JSObjectMake):
(JSObjectSetPrototype):
(JSObjectHasProperty):
* API/JSWrapperMap.mm:
(makeWrapper):
* runtime/ClassInfo.h:
* runtime/IntlCollatorConstructor.cpp:
(JSC::constructIntlCollator):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::constructIntlDateTimeFormat):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::constructIntlNumberFormat):
* runtime/JSCell.cpp:
(JSC::JSCell::isExtensible):
(JSC::JSCell::setPrototypeOf):
* runtime/JSCell.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::resetPrototype):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoSetter):
* runtime/JSObject.cpp:
(JSC::JSObject::switchToSlowPutArrayStorage):
(JSC::JSObject::setPrototypeDirect):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::setPrototypeOf):
(JSC::JSObject::allowsAccessFrom):
(JSC::JSObject::setPrototype): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::setPrototypeOfInline):
(JSC::JSObject::mayInterceptIndexedAccesses):
* runtime/JSProxy.cpp:
(JSC::JSProxy::setTarget):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSetPrototypeOf):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectSetPrototypeOf):
2016-03-02 Saam barati <sbarati@apple.com>
SIGSEGV in Proxy [[Get]] and [[Set]] recursion
https://bugs.webkit.org/show_bug.cgi?id=154854
Reviewed by Yusuke Suzuki.
We need to be aware of the possibility that the VM
may recurse and that we can stack overflow.
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performPut):
* tests/stress/proxy-get-and-set-recursion-stack-overflow.js: Added.
(assert):
(testStackOverflowGet):
(testStackOverflowIndexedGet):
(testStackOverflowSet):
(testStackOverflowIndexedSet):
2016-03-02 Benjamin Poulain <bpoulain@apple.com>
[JSC] Use a Move without REX byte when possible
https://bugs.webkit.org/show_bug.cgi?id=154801
Reviewed by Alex Christensen.
Filip wrote an optimization in the register allocator
to use 32bit "Move" when we don't care about the top bytes.
When I moved the commutative ops to the fake 3 operands instruction
I largely destroyed this since all the "Moves" became full register.
In this patch, I switch back to 32bit "Moves" for 32bit operations.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::and32):
(JSC::MacroAssemblerX86Common::lshift32):
(JSC::MacroAssemblerX86Common::mul32):
(JSC::MacroAssemblerX86Common::or32):
(JSC::MacroAssemblerX86Common::rshift32):
(JSC::MacroAssemblerX86Common::urshift32):
(JSC::MacroAssemblerX86Common::xor32):
(JSC::MacroAssemblerX86Common::branchAdd32):
(JSC::MacroAssemblerX86Common::branchMul32):
(JSC::MacroAssemblerX86Common::branchSub32):
(JSC::MacroAssemblerX86Common::move32IfNeeded):
2016-03-01 Benjamin Poulain <benjamin@webkit.org>
[JSC] Simplify ArithMod(ArithMod(x, const1), const2) if const2 >= const1
https://bugs.webkit.org/show_bug.cgi?id=154904
Reviewed by Saam Barati.
The ASM test "ubench" has a "x % 10 % 255".
The second modulo should be eliminated.
This is a 15% improvement on ASMJS' ubench.
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* tests/stress/arith-modulo-twice.js: Added.
(opaqueModuloSmaller):
(opaqueModuloEqual):
(opaqueModuloLarger):
(opaqueModuloSmallerNeg):
(opaqueModuloEqualNeg):
(opaqueModuloLargerNeg):
(opaqueExpectedOther):
2016-03-01 Ryosuke Niwa <rniwa@webkit.org>
Unreviewed. Update the status of Proxy objects to "In Development".
* features.json:
2016-03-01 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r197226 and r197256.
https://bugs.webkit.org/show_bug.cgi?id=154910
Caused crashes on Mac 32-bit and on ARM (Requested by ap on
#webkit).
Reverted changesets:
"Remove the on demand executable allocator"
https://bugs.webkit.org/show_bug.cgi?id=154749
http://trac.webkit.org/changeset/197226
"CLoop build fix."
http://trac.webkit.org/changeset/197256
2016-03-01 Joseph Pecoraro <pecoraro@apple.com>
Simplify some StringBuilder appends
https://bugs.webkit.org/show_bug.cgi?id=154902
Reviewed by Mark Lam.
* runtime/ExceptionHelpers.cpp:
(JSC::notAFunctionSourceAppender):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::stackTracesAsJSON):
Use StringBuilder::append(char) instead of append(char*) where possible.
2016-03-01 Keith Miller <keith_miller@apple.com>
Promise.prototype.then should use Symbol.species to construct the return Promise
https://bugs.webkit.org/show_bug.cgi?id=154862
Reviewed by Saam Barati.
* builtins/PromisePrototype.js:
* tests/stress/promise-species-functions.js: Added.
(Symbol.species):
(id):
(funcThrows):
(makeC):
(test.species):
(test.speciesThrows):
(test):
2016-03-01 Michael Saboff <msaboff@apple.com>
[ES6] Add support for Unicode regular expressions
https://bugs.webkit.org/show_bug.cgi?id=154842
Reviewed by Filip Pizlo.
Added processing of Unicode regular expressions to the Yarr interpreter.
Changed parsing of regular expression patterns and PatternTerms to process characters as
UChar32 in the Yarr code. The parser converts matched surrogate pairs into the appropriate
Unicode character when the expression is parsed. When matching a unicode expression and
reading source characters, we convert proper surrogate pair into a Unicode character and
advance the source cursor, "pos", one more position. The exception to this is when we
know when generating a fixed character atom that we need to match a unicode character
that doesn't fit in 16 bits. The code calls this an extendedUnicodeCharacter and has a
helper to determine this.
Added 'u' flag and 'unicode' identifier to regular expression classes. Added an "isUnicode"
parameter to YarrPattern pattern() and internal users of that function.
Updated the generation of the canonicalization tables to include a new set a tables that
follow the ES 6.0, 21.2.2.8.2 Step 2. Renamed the YarrCanonicalizeUCS2.* files to
YarrCanonicalizeUnicode.*.
Added a new Layout/js test that tests the added functionality. Updated other tests that
have minor es6 unicode checks and look for valid flags.
Ran the ChakraCore Unicode regular expression tests as well.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::findMagicComment):
* yarr/RegularExpression.cpp:
(JSC::Yarr::RegularExpression::Private::compile):
Updated use of pattern().
* runtime/CommonIdentifiers.h:
* runtime/RegExp.cpp:
(JSC::regExpFlags):
(JSC::RegExpFunctionalTestCollector::outputOneTest):
(JSC::RegExp::finishCreation):
(JSC::RegExp::compile):
(JSC::RegExp::compileMatchOnly):
* runtime/RegExp.h:
* runtime/RegExpKey.h:
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
(JSC::flagsString):
(JSC::regExpProtoGetterMultiline):
(JSC::regExpProtoGetterUnicode):
(JSC::regExpProtoGetterFlags):
Updated for new 'y' (unicode) flag. Add check to use the interpreter for unicode regular expressions.
* tests/es6.yaml:
* tests/stress/static-getter-in-names.js:
Updated tests for new flag and for passing the minimal es6 regular expression processing.
* yarr/Yarr.h: Updated the size of information now kept for backtracking.
* yarr/YarrCanonicalizeUCS2.cpp: Removed.
* yarr/YarrCanonicalizeUCS2.h: Removed.
* yarr/YarrCanonicalizeUCS2.js: Removed.
* yarr/YarrCanonicalizeUnicode.cpp: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUCS2.cpp.
* yarr/YarrCanonicalizeUnicode.h: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUCS2.h.
(JSC::Yarr::canonicalCharacterSetInfo):
(JSC::Yarr::canonicalRangeInfoFor):
(JSC::Yarr::getCanonicalPair):
(JSC::Yarr::isCanonicallyUnique):
(JSC::Yarr::areCanonicallyEquivalent):
(JSC::Yarr::rangeInfoFor): Deleted.
* yarr/YarrCanonicalizeUnicode.js: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUCS2.js.
(printHeader):
(printFooter):
(hex):
(canonicalize):
(canonicalizeUnicode):
(createUCS2CanonicalGroups):
(createUnicodeCanonicalGroups):
(cu.in.groupedCanonically.characters.sort): Deleted.
(cu.in.groupedCanonically.else): Deleted.
Refactored to output two sets of tables, one for UCS2 and one for Unicode. The UCS2 tables follow
the legacy canonicalization rules now specified in ES 6.0, 21.2.2.8.2 Step 3. The new Unicode
tables follow the rules specified in ES 6.0, 21.2.2.8.2 Step 2. Eliminated the unused Latin1 tables.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::InputStream::InputStream):
(JSC::Yarr::Interpreter::InputStream::readChecked):
(JSC::Yarr::Interpreter::InputStream::readSurrogatePairChecked):
(JSC::Yarr::Interpreter::InputStream::reread):
(JSC::Yarr::Interpreter::InputStream::prev):
(JSC::Yarr::Interpreter::testCharacterClass):
(JSC::Yarr::Interpreter::checkCharacter):
(JSC::Yarr::Interpreter::checkSurrogatePair):
(JSC::Yarr::Interpreter::checkCasedCharacter):
(JSC::Yarr::Interpreter::tryConsumeBackReference):
(JSC::Yarr::Interpreter::backtrackPatternCharacter):
(JSC::Yarr::Interpreter::matchCharacterClass):
(JSC::Yarr::Interpreter::backtrackCharacterClass):
(JSC::Yarr::Interpreter::matchParenthesesTerminalEnd):
(JSC::Yarr::Interpreter::matchDisjunction):
(JSC::Yarr::Interpreter::Interpreter):
(JSC::Yarr::ByteCompiler::assertionWordBoundary):
(JSC::Yarr::ByteCompiler::atomPatternCharacter):
* yarr/YarrInterpreter.h:
(JSC::Yarr::ByteTerm::ByteTerm):
(JSC::Yarr::BytecodePattern::BytecodePattern):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::optimizeAlternative):
(JSC::Yarr::YarrGenerator::matchCharacterClassRange):
(JSC::Yarr::YarrGenerator::matchCharacterClass):
(JSC::Yarr::YarrGenerator::notAtEndOfInput):
(JSC::Yarr::YarrGenerator::jumpIfCharNotEquals):
(JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
(JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
(JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy):
(JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy):
* yarr/YarrParser.h:
(JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter):
(JSC::Yarr::Parser::Parser):
(JSC::Yarr::Parser::parseEscape):
(JSC::Yarr::Parser::consumePossibleSurrogatePair):
(JSC::Yarr::Parser::parseCharacterClass):
(JSC::Yarr::Parser::parseTokens):
(JSC::Yarr::Parser::parse):
(JSC::Yarr::Parser::atEndOfPattern):
(JSC::Yarr::Parser::patternRemaining):
(JSC::Yarr::Parser::peek):
(JSC::Yarr::parse):
* yarr/YarrPattern.cpp:
(JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
(JSC::Yarr::CharacterClassConstructor::append):
(JSC::Yarr::CharacterClassConstructor::putChar):
(JSC::Yarr::CharacterClassConstructor::putUnicodeIgnoreCase):
(JSC::Yarr::CharacterClassConstructor::putRange):
(JSC::Yarr::CharacterClassConstructor::charClass):
(JSC::Yarr::CharacterClassConstructor::addSorted):
(JSC::Yarr::CharacterClassConstructor::addSortedRange):
(JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
(JSC::Yarr::YarrPatternConstructor::assertionWordBoundary):
(JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
(JSC::Yarr::YarrPatternConstructor::atomCharacterClassBegin):
(JSC::Yarr::YarrPatternConstructor::atomCharacterClassAtom):
(JSC::Yarr::YarrPatternConstructor::atomCharacterClassRange):
(JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets):
(JSC::Yarr::YarrPattern::compile):
(JSC::Yarr::YarrPattern::YarrPattern):
* yarr/YarrPattern.h:
(JSC::Yarr::CharacterRange::CharacterRange):
(JSC::Yarr::CharacterClass::CharacterClass):
(JSC::Yarr::PatternTerm::PatternTerm):
(JSC::Yarr::YarrPattern::reset):
* yarr/YarrSyntaxChecker.cpp:
(JSC::Yarr::SyntaxChecker::assertionBOL):
(JSC::Yarr::SyntaxChecker::assertionEOL):
(JSC::Yarr::SyntaxChecker::assertionWordBoundary):
(JSC::Yarr::SyntaxChecker::atomPatternCharacter):
(JSC::Yarr::SyntaxChecker::atomBuiltInCharacterClass):
(JSC::Yarr::SyntaxChecker::atomCharacterClassBegin):
(JSC::Yarr::SyntaxChecker::atomCharacterClassAtom):
(JSC::Yarr::checkSyntax):
2016-03-01 Saam barati <sbarati@apple.com>
Remove FIXMEs and add valid test cases after necessary patch has landed.
Rubber stamped by Mark Lam.
* tests/stress/proxy-prevent-extensions.js:
(assert.Object.isSealed):
(assert):
2016-03-01 Saam barati <sbarati@apple.com>
[ES6] Implement Proxy.[[IsExtensible]]
https://bugs.webkit.org/show_bug.cgi?id=154872
Reviewed by Oliver Hunt.
This patch is a direct implementation of Proxy.[[IsExtensible]] with respect to section 9.5.3
of the ECMAScript 6 spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-isextensible
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::preventExtensions):
(JSC::ProxyObject::performIsExtensible):
(JSC::ProxyObject::isExtensible):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
* tests/es6.yaml:
* tests/stress/proxy-is-extensible.js: Added.
(assert):
(throw.new.Error.let.handler.get isExtensible):
(throw.new.Error):
(assert.let.handler.isExtensible):
(assert.):
(let.handler.isExtensible):
2016-03-01 Saam barati <sbarati@apple.com>
[ES6] Implement Proxy.[[PreventExtensions]]
https://bugs.webkit.org/show_bug.cgi?id=154873
Reviewed by Oliver Hunt.
This patch is a direct implementation of Proxy.[[PreventExtensions]] with respect to section 9.5.4
of the ECMAScript 6 spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-preventextensions
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::deletePropertyByIndex):
(JSC::ProxyObject::performPreventExtensions):
(JSC::ProxyObject::preventExtensions):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
* tests/es6.yaml:
* tests/stress/proxy-prevent-extensions.js: Added.
(assert):
(throw.new.Error.let.handler.get preventExtensions):
(throw.new.Error):
(assert.let.handler.preventExtensions):
(assert.):
(let.handler.preventExtensions):
(assert.Object.isSealed.let.handler.preventExtensions):
(assert.Object.isSealed):
2016-03-01 Filip Pizlo <fpizlo@apple.com>
FTL should simplify StringReplace with an empty replacement string
https://bugs.webkit.org/show_bug.cgi?id=154871
Reviewed by Michael Saboff.
This is a simple and hugely profitable change. If we do a string.replace(/things/, ""), then
this calls directly into StringPrototype's replace-with-empty-string logic instead of going
through stuff that does checks before reaching that same conclusion.
This speeds up Octane/regexp by about 6-10%. It also speeds up the attached microbenchmark by
about 7%.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
* runtime/StringPrototype.cpp:
(JSC::jsSpliceSubstringsWithSeparators):
(JSC::removeUsingRegExpSearch):
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
(JSC::operationStringProtoFuncReplaceRegExpString):
* runtime/StringPrototype.h:
2016-03-01 Alex Christensen <achristensen@webkit.org>
Reduce size of internal windows build output
https://bugs.webkit.org/show_bug.cgi?id=154763
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.proj:
2016-03-01 Saam barati <sbarati@apple.com>
[[IsExtensible]] should be a virtual method in the method table
https://bugs.webkit.org/show_bug.cgi?id=154799
Reviewed by Mark Lam.
This patch makes us more consistent with how the ES6 specification models the
[[IsExtensible]] trap. Moving this method into ClassInfo::methodTable
is a prerequisite for implementing Proxy.[[IsExtensible]].
* runtime/ClassInfo.h:
* runtime/JSCell.cpp:
(JSC::JSCell::preventExtensions):
(JSC::JSCell::isExtensible):
* runtime/JSCell.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoSetter):
* runtime/JSObject.cpp:
(JSC::JSObject::preventExtensions):
(JSC::JSObject::isExtensible):
(JSC::JSObject::reifyAllStaticProperties):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::defineOwnNonIndexProperty):
(JSC::JSObject::defineOwnProperty):
* runtime/JSObject.h:
(JSC::JSObject::isSealed):
(JSC::JSObject::isFrozen):
(JSC::JSObject::isExtensibleImpl):
(JSC::JSObject::isStructureExtensible):
(JSC::JSObject::isExtensibleInline):
(JSC::JSObject::indexingShouldBeSparse):
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::isExtensible): Deleted.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSetPrototypeOf):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
(JSC::objectConstructorIsExtensible):
(JSC::objectConstructorIs):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectIsExtensible):
(JSC::reflectObjectSetPrototypeOf):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayValueMap::putDirect):
* runtime/StringObject.cpp:
(JSC::StringObject::defineOwnProperty):
* runtime/Structure.cpp:
(JSC::Structure::isSealed):
(JSC::Structure::isFrozen):
* runtime/Structure.h:
2016-03-01 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix CLOOP build.
* jit/JITOperations.h:
2016-03-01 Skachkov Oleksandr <gskachkov@gmail.com>
[ES6] Arrow function. Some not used byte code is emited
https://bugs.webkit.org/show_bug.cgi?id=154639
Reviewed by Saam Barati.
Currently bytecode that is generated for arrow function is not optimal.
Current fix removed following unnecessary bytecode:
1.create_lexical_environment not emited always for arrow function, only if some of
features(this/super/arguments/eval) is used inside of the arrow function.
2.load 'this' from arrow function scope in constructor is done only if super
contains in arrow function
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::isSuperCallUsedInInnerArrowFunction):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
* parser/Nodes.h:
(JSC::ScopeNode::doAnyInnerArrowFunctionsUseAnyFeature):
* tests/stress/arrowfunction-lexical-bind-supercall-4.js:
2016-02-29 Filip Pizlo <fpizlo@apple.com>
Turn String.prototype.replace into an intrinsic
https://bugs.webkit.org/show_bug.cgi?id=154835
Reviewed by Michael Saboff.
Octane/regexp spends a lot of time in String.prototype.replace(). That function does a lot
of checks to see if the parameters are what they are likely to often be (a string, a
regexp, and a string). The intuition of this patch is that it's good to remove those checks
and it's good to call the native function as directly as possible.
This yields a 10% speed-up on a replace microbenchmark and a 3% speed-up on Octane/regexp.
It also improves Octane/jquery.
This is only the beginning of what I want to do with replace optimizations. The other
optimizations will rely on StringReplace being revealed as a construct in DFG IR.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
(JSC::speculationToAbbreviatedString):
(JSC::speculationFromClassInfo):
* bytecode/SpeculatedType.h:
(JSC::isStringOrStringObjectSpeculation):
(JSC::isRegExpObjectSpeculation):
(JSC::isBoolInt32Speculation):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateStringOrStringObject):
(JSC::DFG::Node::shouldSpeculateRegExpObject):
(JSC::DFG::Node::shouldSpeculateSymbol):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateFinalObject):
(JSC::DFG::SpeculativeJIT::speculateRegExpObject):
(JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::isCell):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
(JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
(JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
(JSC::FTL::DFG::LowerDFGToB3::speculate):
(JSC::FTL::DFG::LowerDFGToB3::speculateFinalObject):
(JSC::FTL::DFG::LowerDFGToB3::speculateRegExpObject):
(JSC::FTL::DFG::LowerDFGToB3::speculateString):
* jit/JITOperations.h:
* runtime/Intrinsic.h:
* runtime/JSType.h:
* runtime/RegExpObject.h:
(JSC::RegExpObject::createStructure):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::removeUsingRegExpSearch):
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpString):
(JSC::replaceUsingStringSearch):
(JSC::stringProtoFuncRepeat):
(JSC::replace):
(JSC::stringProtoFuncReplace):
(JSC::operationStringProtoFuncReplaceGeneric):
(JSC::stringProtoFuncToString):
* runtime/StringPrototype.h:
2016-03-01 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r197056.
https://bugs.webkit.org/show_bug.cgi?id=154870
broke win ews (Requested by alexchristensen on #webkit).
Reverted changeset:
"[cmake] Moved PRE/POST_BUILD_COMMAND to WEBKIT_FRAMEWORK."
https://bugs.webkit.org/show_bug.cgi?id=154651
http://trac.webkit.org/changeset/197056
2016-02-29 Saam barati <sbarati@apple.com>
[[PreventExtensions]] should be a virtual method in the method table.
https://bugs.webkit.org/show_bug.cgi?id=154800
Reviewed by Yusuke Suzuki.
This patch makes us more consistent with how the ES6 specification models the
[[PreventExtensions]] trap. Moving this method into ClassInfo::methodTable
is a prerequisite for implementing Proxy.[[PreventExtensions]].
* runtime/ClassInfo.h:
* runtime/JSCell.cpp:
(JSC::JSCell::getGenericPropertyNames):
(JSC::JSCell::preventExtensions):
* runtime/JSCell.h:
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::JSModuleNamespaceObject):
(JSC::JSModuleNamespaceObject::finishCreation):
(JSC::JSModuleNamespaceObject::destroy):
* runtime/JSModuleNamespaceObject.h:
(JSC::JSModuleNamespaceObject::create):
(JSC::JSModuleNamespaceObject::moduleRecord):
* runtime/JSObject.cpp:
(JSC::JSObject::freeze):
(JSC::JSObject::preventExtensions):
(JSC::JSObject::reifyAllStaticProperties):
* runtime/JSObject.h:
(JSC::JSObject::isSealed):
(JSC::JSObject::isFrozen):
(JSC::JSObject::isExtensible):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
(JSC::objectConstructorPreventExtensions):
(JSC::objectConstructorIsSealed):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectPreventExtensions):
* runtime/Structure.cpp:
(JSC::Structure::Structure):
(JSC::Structure::preventExtensionsTransition):
* runtime/Structure.h:
2016-02-29 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Private symbols should not be trapped by proxy handler
https://bugs.webkit.org/show_bug.cgi?id=154817
Reviewed by Mark Lam.
Since the runtime has some assumptions on the properties associated with the private symbols, ES6 Proxy should not trap these property operations.
For example, in ArrayIteratorPrototype.js
var itemKind = this.@arrayIterationKind;
if (itemKind === @undefined)
throw new @TypeError("%ArrayIteratorPrototype%.next requires that |this| be an Array Iterator instance");
Here, we assume that only the array iterator has the @arrayIterationKind property that value is non-undefined.
But If we implement Proxy with the get handler, that returns a non-undefined value for every operations, we accidentally assumes that the given value is an array iterator.
To avoid these situation, we perform the default operations onto property operations with private symbols.
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::deleteProperty):
(JSC::ProxyObject::deletePropertyByIndex):
* tests/stress/proxy-basic.js:
* tests/stress/proxy-with-private-symbols.js: Added.
(assert):
(let.handler.getOwnPropertyDescriptor):
2016-02-29 Filip Pizlo <fpizlo@apple.com>
regress/script-tests/double-pollution-putbyoffset.js.ftl-eager timed out because of a lock ordering deadlock involving InferredType and CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=154841
Reviewed by Benjamin Poulain.
Here's the deadlock:
Main thread:
1) Change an InferredType. This acquires InferredType::m_lock.
2) Fire watchpoint set. This triggers CodeBlock invalidation, which acquires
CodeBlock::m_lock.
DFG thread:
1) Iterate over the information in a CodeBlock. This acquires CodeBlock::m_lock.
2) Ask an InferredType for its descriptor(). This acquires InferredType::m_lock.
I think that the DFG thread's ordering should be legal, because the best logic for lock
hierarchies is that locks that protect the largest set of stuff should be acquired first.
This means that the main thread shouldn't be holding the InferredType::m_lock when firing
watchpoint sets. That's what this patch ensures.
At the time of writing, this test was deadlocking for me on trunk 100% of the time. With
this change I cannot get it to deadlock.
* runtime/InferredType.cpp:
(JSC::InferredType::willStoreValueSlow):
(JSC::InferredType::makeTopSlow):
(JSC::InferredType::set):
(JSC::InferredType::removeStructure):
(JSC::InferredType::InferredStructureWatchpoint::fireInternal):
* runtime/InferredType.h:
2016-02-29 Yusuke Suzuki <utatane.tea@gmail.com>
[DFG][FTL][B3] Support floor and ceil
https://bugs.webkit.org/show_bug.cgi?id=154683
Reviewed by Filip Pizlo.
This patch implements and fixes the following things.
1. Implement Ceil and Floor in DFG, FTL and B3
x86 SSE 4.2 and ARM64 have round instructions that can directly perform Ceil or Floor.
This patch leverages this functionality. We introduce ArithFloor and ArithCeil.
During DFG phase, these nodes attempt to convert itself to Identity (in Fixup phase).
As the same to ArithRound, it tracks arith rounding mode.
And if these nodes are required to emit machine codes, we emit rounding machine code
if it is supported in the current machine. For example, in x86, we emit `round`.
This `Floor` functionality is nice for @toInteger in builtin.
That is used for Array.prototype.{forEach, map, every, some, reduce...}
And according to the benchmark results, Kraken audio-oscillator is slightly improved
due to its frequent Math.round and Math.floor calls.
2. Implement Floor in B3 and Air
As the same to Ceil in B3, we add a new B3 IR and Air opcode, Floor.
This Floor is leveraged to implement ArithFloor in DFG.
3. Fix ArithRound operation
Currently, we used cvtsd2si (in x86) to convert double value to int32.
And we also used this to implement Math.round, like, cvtsd2si(value + 0.5).
However, this implementation is not correct. Because cvtsd2si is not floor operation.
It is trucate operation. This is OK for positive numbers. But NG for negative numbers.
For example, the current implementation accidentally rounds `-0.6` to `-0.0`. This should be `-1.0`.
Using Ceil and Floor instructions, we implement correct ArithRound.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::supportsFloatingPointRounding):
(JSC::MacroAssemblerARM::ceilDouble):
(JSC::MacroAssemblerARM::floorDouble):
(JSC::MacroAssemblerARM::supportsFloatingPointCeil): Deleted.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::supportsFloatingPointRounding):
(JSC::MacroAssemblerARM64::floorFloat):
(JSC::MacroAssemblerARM64::supportsFloatingPointCeil): Deleted.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::supportsFloatingPointRounding):
(JSC::MacroAssemblerARMv7::ceilDouble):
(JSC::MacroAssemblerARMv7::floorDouble):
(JSC::MacroAssemblerARMv7::supportsFloatingPointCeil): Deleted.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::ceilDouble):
(JSC::MacroAssemblerMIPS::floorDouble):
(JSC::MacroAssemblerMIPS::supportsFloatingPointRounding):
(JSC::MacroAssemblerMIPS::supportsFloatingPointCeil): Deleted.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::supportsFloatingPointRounding):
(JSC::MacroAssemblerSH4::ceilDouble):
(JSC::MacroAssemblerSH4::floorDouble):
(JSC::MacroAssemblerSH4::supportsFloatingPointCeil): Deleted.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::floorDouble):
(JSC::MacroAssemblerX86Common::floorFloat):
(JSC::MacroAssemblerX86Common::supportsFloatingPointRounding):
(JSC::MacroAssemblerX86Common::supportsFloatingPointCeil): Deleted.
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::floorConstant):
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.cpp:
(JSC::B3::ConstFloatValue::floorConstant):
* b3/B3ConstFloatValue.h:
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3ReduceDoubleToFloat.cpp:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::floorConstant):
(JSC::B3::Value::isRounded):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/air/AirFixPartialRegisterStalls.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testFloorCeilArg):
(JSC::B3::testFloorArg):
(JSC::B3::testFloorImm):
(JSC::B3::testFloorMem):
(JSC::B3::testFloorFloorArg):
(JSC::B3::testCeilFloorArg):
(JSC::B3::testFloorIToD64):
(JSC::B3::testFloorIToD32):
(JSC::B3::testFloorArgWithUselessDoubleConversion):
(JSC::B3::testFloorArgWithEffectfulDoubleConversion):
(JSC::B3::run):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArithMode.cpp:
(WTF::printInternal):
* dfg/DFGArithMode.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::roundShouldSpeculateInt32):
* dfg/DFGNode.h:
(JSC::DFG::Node::arithNodeFlags):
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasArithRoundingMode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithRounding):
(JSC::DFG::SpeculativeJIT::compileArithRound): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
(JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
(JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
* ftl/FTLOutput.h:
(JSC::FTL::Output::doubleFloor):
* jit/ThunkGenerators.cpp:
(JSC::ceilThunkGenerator):
* tests/stress/math-ceil-arith-rounding-mode.js: Added.
(firstCareAboutZeroSecondDoesNot):
(firstDoNotCareAboutZeroSecondDoes):
(warmup):
(verifyNegativeZeroIsPreserved):
* tests/stress/math-ceil-basics.js: Added.
(mathCeilOnIntegers):
(mathCeilOnDoubles):
(mathCeilOnBooleans):
(uselessMathCeil):
(mathCeilWithOverflow):
(mathCeilConsumedAsDouble):
(mathCeilDoesNotCareAboutMinusZero):
(mathCeilNoArguments):
(mathCeilTooManyArguments):
(testMathCeilOnConstants):
(mathCeilStructTransition):
(Math.ceil):
* tests/stress/math-floor-arith-rounding-mode.js: Added.
(firstCareAboutZeroSecondDoesNot):
(firstDoNotCareAboutZeroSecondDoes):
(warmup):
(verifyNegativeZeroIsPreserved):
* tests/stress/math-floor-basics.js: Added.
(mathFloorOnIntegers):
(mathFloorOnDoubles):
(mathFloorOnBooleans):
(uselessMathFloor):
(mathFloorWithOverflow):
(mathFloorConsumedAsDouble):
(mathFloorDoesNotCareAboutMinusZero):
(mathFloorNoArguments):
(mathFloorTooManyArguments):
(testMathFloorOnConstants):
(mathFloorStructTransition):
(Math.floor):
* tests/stress/math-round-should-not-use-truncate.js: Added.
(mathRoundDoesNotCareAboutMinusZero):
* tests/stress/math-rounding-infinity.js: Added.
(shouldBe):
(testRound):
(testFloor):
(testCeil):
* tests/stress/math-rounding-nan.js: Added.
(shouldBe):
(testRound):
(testFloor):
(testCeil):
* tests/stress/math-rounding-negative-zero.js: Added.
(shouldBe):
(testRound):
(testFloor):
(testCeil):
(testRoundNonNegativeZero):
(testRoundNonNegativeZero2):
2016-02-29 Joseph Pecoraro <pecoraro@apple.com>
Add new MethodTable method to get an estimated size for a cell
https://bugs.webkit.org/show_bug.cgi?id=154838
Reviewed by Filip Pizlo.
The new class method estimatedSize(JSCell*) estimates the size for a single cell.
As the name implies, this is meant to be an approximation. It is more important
that big objects report a large size, then to get perfect size information for
all objects in the heap.
Base implementation (JSCell):
- returns the MarkedBlock bucket size for this cell.
- This gets us the object size include inline storage. Basically a better sizeof.
Subclasses with "Extra Memory Cost":
- Any class that reports extra memory (reportExtraMemoryVisited) should include that in the estimated size.
- E.g. CodeBlock, JSGenericTypedArrayView, WeakMapData, etc.
Subclasses with "Copied Space" storage:
- Any class with data in copied space (copyBackingStore) should include that in the estimated size.
- E.g. JSObject, JSGenericTypedArrayView, JSMap, JSSet, DirectArguments, etc.
Add reportExtraMemoryVisited for UnlinkedCodeBlock's compressed unlinked
instructions because this can be larger than 1kb, which is significant.
This has one special case for RegExp generated bytecode / JIT code, which
does not currently fall into the extra memory cost or copied space storage.
In practice I haven't seen this grow to a significant cost.
* runtime/ClassInfo.h:
Add the new estimatedSize method to the table.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::visitChildren):
(JSC::UnlinkedCodeBlock::estimatedSize):
(JSC::UnlinkedCodeBlock::setInstructions):
* bytecode/UnlinkedCodeBlock.h:
Report an extra memory cost for unlinked code blocks like
we do for linked code blocks.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::estimatedSize):
* bytecode/CodeBlock.h:
* bytecode/UnlinkedInstructionStream.cpp:
(JSC::UnlinkedInstructionStream::sizeInBytes):
* bytecode/UnlinkedInstructionStream.h:
* runtime/DirectArguments.cpp:
(JSC::DirectArguments::estimatedSize):
* runtime/DirectArguments.h:
* runtime/JSCell.cpp:
(JSC::JSCell::estimatedSizeInBytes):
(JSC::JSCell::estimatedSize):
* runtime/JSCell.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
* runtime/JSMap.cpp:
(JSC::JSMap::estimatedSize):
* runtime/JSMap.h:
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterfly):
* runtime/JSObject.h:
* runtime/JSSet.cpp:
(JSC::JSSet::estimatedSize):
* runtime/JSSet.h:
* runtime/JSString.cpp:
(JSC::JSString::estimatedSize):
* runtime/JSString.h:
* runtime/MapData.h:
(JSC::MapDataImpl::capacityInBytes):
* runtime/WeakMapData.cpp:
(JSC::WeakMapData::estimatedSize):
(JSC::WeakMapData::visitChildren):
* runtime/WeakMapData.h:
Implement estimated size following the pattern of reporting
extra visited size, or copy space memory.
* runtime/RegExp.cpp:
(JSC::RegExp::estimatedSize):
* runtime/RegExp.h:
* yarr/YarrInterpreter.h:
(JSC::Yarr::ByteDisjunction::estimatedSizeInBytes):
(JSC::Yarr::BytecodePattern::estimatedSizeInBytes):
* yarr/YarrJIT.h:
(JSC::Yarr::YarrCodeBlock::size):
Include generated bytecode / JITCode to a RegExp's size.
2016-02-29 Filip Pizlo <fpizlo@apple.com>
SpeculatedType should be easier to edit
https://bugs.webkit.org/show_bug.cgi?id=154840
Reviewed by Mark Lam.
We used to specify the bitmasks in SpeculatedType.h using hex codes. This used to work
great because we didn't have so many masks and you could use the mask to visually see
which ones overlapped. It also made it easy to visualize subset relationships.
But now we have a lot of masks with a lot of confusing overlaps, and it's no longer
possible to just see their relationship by looking at hex codes. Worse, the use of hex
codes makes it super annoying to move the bits around. For example, right now we have two
bits free, but if we wanted to reclaim them by editing the old hex masks, it would be a
nightmare.
So this patch replaces the hex masks with shift expressions (1u << 15 for example) and it
makes any derived masks (i.e. masks that are the bit-or of other masks) be expressed using
an or expression (SpecFoo | SpecBar | SpecBaz for example).
This makes it easier to see the relationships and it makes it easier to take bits for new
types.
* bytecode/SpeculatedType.h:
2016-02-29 Keith Miller <keith_miller@apple.com>
OverridesHasInstance constant folding is wrong
https://bugs.webkit.org/show_bug.cgi?id=154833
Reviewed by Filip Pizlo.
The current implementation of OverridesHasInstance constant folding
is incorrect. Since it relies on OSR exit information it has been
moved to the StrengthReductionPhase. Normally, such an optimazation would be
put in FixupPhase, however, there are a number of cases where we don't
determine an edge of OverridesHasInstance is a constant until after fixup.
Performing the optimization during StrengthReductionPhase means we can defer
our decision until later.
In the future we should consider creating a version of this optimization
that does not depend on OSR exit information and move the optimization back
to ConstantFoldingPhase.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants): Deleted.
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2016-02-28 Filip Pizlo <fpizlo@apple.com>
B3 should have global store elimination
https://bugs.webkit.org/show_bug.cgi?id=154658
Reviewed by Benjamin Poulain.
Implements fairly comprehensive global store elimination:
1) If you store the result of a load with no interference in between, remove the store.
2) If you store the same thing you stored previously, remove the store.
3) If you store something that you either loaded previously or stored previously along
arbitrarily many paths, remove the store.
4) If you store to something that is stored to again in the future with no interference in
between, remove the store.
Rule (4) is super relevant to FTL since the DFG does not eliminate redundant PutStructures.
A constructor that produces a large object will have many redundant stores to the same base
pointer, offset, and heap range, with no code to observe that heap raneg in between.
This doesn't have a decisive effect on major benchmarks, but it's an enormous win for
microbenchmarks:
- 30% faster to construct an object with many fields.
- 5x faster to do many stores to a global variable.
The compile time cost should be very small. Although the optimization is global, it aborts as
soon as it sees anything that would confound store elimination. For rules (1)-(3), we
piggy-back the existing load elimination, which gives up on interfering stores. For rule (4),
we search forward through the current block and then globally a block at a time (skipping
block contents thanks to summary data), which could be expensive. But rule (4) aborts as soon
as it sees a read, write, or end block (Return or Oops). Any Check will claim to read TOP. Any
Patchpoint that results from an InvalidationPoint will claim to read TOP, as will any
Patchpoints for ICs. Those are usually sprinkled all over the program.
In other words, this optimization rarely kicks in. When it does kick in, it makes programs run
faster. When it doesn't kick in, it's usually O(1) because there are reasons for aborting all
over a "normal" program so the search will halt almost immediately. This of course raises the
question: how much more in compile time do we pay when the optimization does kick in? The
optimization kicks in the most for the microbenchmarks I wrote for this patch. Amazingly, the
effect of the optimization a wash for compile time: whatever cost we pay doing the O(n^2)
searches is balanced by the massive reduction in work in the backend. On one of the two
microbenchmarks, overall compile time actually shrank with this optimization even though CSE
itself cost more. That's not too surprising - the backend costs much more per instruction, so
things that remove instructions before we get to the backend tend to be a good idea.
We could consider adding a more aggressive version of this in the future, which could sink
stores into checks. That could be crazy fun: https://bugs.webkit.org/show_bug.cgi?id=152162#c3
But mainly, I'm adding this optimization because it was super fun to implement during the
WebAssembly CG summit.
* b3/B3EliminateCommonSubexpressions.cpp:
* b3/B3MemoryValue.h:
* b3/B3SuccessorCollection.h:
(JSC::B3::SuccessorCollection::begin):
(JSC::B3::SuccessorCollection::end):
(JSC::B3::SuccessorCollection::const_iterator::const_iterator):
(JSC::B3::SuccessorCollection::const_iterator::operator*):
(JSC::B3::SuccessorCollection::const_iterator::operator++):
(JSC::B3::SuccessorCollection::const_iterator::operator==):
(JSC::B3::SuccessorCollection::const_iterator::operator!=):
2016-02-29 Filip Pizlo <fpizlo@apple.com>
Make it cheap to #include "JITOperations.h"
https://bugs.webkit.org/show_bug.cgi?id=154836
Reviewed by Mark Lam.
Prior to this change, this header included the whole world even though it did't have any
definitions. This patch turns almost all of the includes into forward declarations. Right
now this header is very cheap to include.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGSpeculativeJIT.h:
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/Repatch.h:
* runtime/CommonSlowPaths.h:
(JSC::encodeResult): Deleted.
(JSC::decodeResult): Deleted.
* runtime/SlowPathReturnType.h: Added.
(JSC::encodeResult):
(JSC::decodeResult):
2016-02-28 Filip Pizlo <fpizlo@apple.com>
FTL should be able to run everything in Octane/regexp
https://bugs.webkit.org/show_bug.cgi?id=154266
Reviewed by Saam Barati.
Adds FTL support for NewRegexp, RegExpTest, and RegExpExec. I couldn't figure out how to
make the RegExpExec peephole optimization work in FTL. This optimizations shouldn't be a
DFG backend optimization anyway - if we need this optimization then it should be a
strength reduction rule over IR. That way, it can be shared by all backends.
I measured whether removing that optimization had any effect on performance separately
from measuring the performance of this patch. Removing that optimization did not change
our score on any benchmarks.
This patch does have an overall negative effect on the Octane/regexp score. This is
presumably because tiering up to the FTL has no value to the code in the regexp test. Or
maybe it's something else. No matter - the overall effect on the Octane score is not
statistically significant and we don't want this kind of coverage blocked by the fact
that adding coverage hurts a benchmark.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGNode.h:
(JSC::DFG::Node::setIndexingType):
(JSC::DFG::Node::hasRegexpIndex):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNotifyWrite):
(JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
(JSC::DFG::SpeculativeJIT::compileRegExpExec): Deleted.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckWatchdogTimer):
(JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
(JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
(JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
(JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
* tests/stress/ftl-regexp-exec.js: Added.
* tests/stress/ftl-regexp-test.js: Added.
2016-02-28 Andreas Kling <akling@apple.com>
Make JSFunction.name allocation fully lazy.
<https://webkit.org/b/154806>
Reviewed by Saam Barati.
We were reifying the "name" field on functions lazily, but created the string
value itself up front. This patch gets rid of the up-front allocation,
saving us a JSString allocation per function in most cases.
* builtins/BuiltinExecutables.cpp:
(JSC::createExecutableInternal):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::visitChildren):
* bytecode/UnlinkedFunctionExecutable.h:
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/Executable.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::reifyName):
2016-02-28 Andreas Kling <akling@apple.com>
REGRESSION(r197303): 4 jsc tests failing on bots.
Unreviewed follow-up fix.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset): This function
can still get called with !m_rareData, in case the type profiler is active but this
particular code block doesn't have type profiler data. Handle it gracefully.
2016-02-28 Andreas Kling <akling@apple.com>
Shrink UnlinkedCodeBlock a bit.
<https://webkit.org/b/154797>
Reviewed by Anders Carlsson.
Move profiler-related members of UnlinkedCodeBlock into its RareData
structure, saving 40 bytes, and then reorder the other members of
UnlinkedCodeBlock to save another 24 bytes, netting a nice total 64.
The VM member was removed entirely since UnlinkedCodeBlock is a cell
and can retrieve its VM through MarkedBlock header lookup.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::vm):
(JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset):
(JSC::UnlinkedCodeBlock::addTypeProfilerExpressionInfo):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addRegExp):
(JSC::UnlinkedCodeBlock::addConstant):
(JSC::UnlinkedCodeBlock::addFunctionDecl):
(JSC::UnlinkedCodeBlock::addFunctionExpr):
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets):
(JSC::UnlinkedCodeBlock::vm): Deleted.
2016-02-27 Filip Pizlo <fpizlo@apple.com>
FTL should lower its abstract heaps to B3 heap ranges
https://bugs.webkit.org/show_bug.cgi?id=154782
Reviewed by Saam Barati.
The FTL can describe the abstract heaps (points-to sets) that a memory operation will
affect. The abstract heaps are arranged as a hierarchy. We used to transform this into
TBAA hierarchies in LLVM, but we never got around to wiring this up to B3's equivalent
notion - the HeapRange. That's what this patch fixes.
B3 has a minimalistic alias analysis. It represents abstract heaps using unsigned 32-bit
integers. There are 1<<32 abstract heaps. The B3 client can describe what an operation
affects by specifying a heap range: a begin...end pair that says that the operation
affects all abstract heaps H such that begin <= H < end.
This peculiar scheme was a deliberate attempt to distill what the abstract heap
hierarchy is all about. We can assign begin...end numbers to abstract heaps so that:
- A heap's end is greater than its begin.
- A heap's begin is greater than or equal to its parent's begin.
- A heap's end is less than or equal to its parent's end.
This is easy to do using a recursive traversal of the abstract heap hierarchy. I almost
went for the iterative traversal, which is a splendid algorithm, but it's totally
unnecessary here since we tightly control the height of the heap hierarchy.
Because abstract heaps are produced on-the-fly by FTL lowering, due to the fact that we
generate new ones for field names and constant indices we encounter, we can't actually
decorate the B3 instructions we create in lowering until all lowering is done. Adding a
new abstract heap to the hierarchy after ranges were already computed would require
updating the ranges of any heaps "to the right" of that heap in the hierarchy. This
patch solves that problem by recording the associations between abstract heaps and their
intended roles in the generated IR, and then decorating all of the relevant B3 values
after we compute the ranges of the hierarchy after lowering.
This is perf-neutral. I was hoping for a small speed-up, but I could not detect a
speed-up on any benchmark. That's not too surprising. We already have very precise CSE
in the DFG, so there aren't many opportunities left for the B3 CSE and it may have
already been getting the big ones even without alias analysis.
Even without a speed-up, this patch is valuable because it makes it easier to implement
other optimizations, like store elimination.
* b3/B3HeapRange.h:
(JSC::B3::HeapRange::HeapRange):
* ftl/FTLAbstractHeap.cpp:
(JSC::FTL::AbstractHeap::AbstractHeap):
(JSC::FTL::AbstractHeap::changeParent):
(JSC::FTL::AbstractHeap::compute):
(JSC::FTL::AbstractHeap::shallowDump):
(JSC::FTL::AbstractHeap::dump):
(JSC::FTL::AbstractHeap::deepDump):
(JSC::FTL::AbstractHeap::badRangeError):
(JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
(JSC::FTL::IndexedAbstractHeap::baseIndex):
(JSC::FTL::IndexedAbstractHeap::atSlow):
(JSC::FTL::IndexedAbstractHeap::initialize):
(JSC::FTL::AbstractHeap::decorateInstruction): Deleted.
(JSC::FTL::AbstractField::dump): Deleted.
* ftl/FTLAbstractHeap.h:
(JSC::FTL::AbstractHeap::AbstractHeap):
(JSC::FTL::AbstractHeap::isInitialized):
(JSC::FTL::AbstractHeap::initialize):
(JSC::FTL::AbstractHeap::parent):
(JSC::FTL::AbstractHeap::heapName):
(JSC::FTL::AbstractHeap::range):
(JSC::FTL::AbstractHeap::offset):
(JSC::FTL::IndexedAbstractHeap::atAnyIndex):
(JSC::FTL::IndexedAbstractHeap::at):
(JSC::FTL::IndexedAbstractHeap::operator[]):
(JSC::FTL::IndexedAbstractHeap::returnInitialized):
(JSC::FTL::IndexedAbstractHeap::WithoutZeroOrOneHashTraits::constructDeletedValue):
(JSC::FTL::IndexedAbstractHeap::WithoutZeroOrOneHashTraits::isDeletedValue):
(JSC::FTL::AbstractHeap::changeParent): Deleted.
(JSC::FTL::AbstractField::AbstractField): Deleted.
(JSC::FTL::AbstractField::initialize): Deleted.
(JSC::FTL::AbstractField::offset): Deleted.
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
(JSC::FTL::AbstractHeapRepository::~AbstractHeapRepository):
(JSC::FTL::AbstractHeapRepository::decorateMemory):
(JSC::FTL::AbstractHeapRepository::decorateCCallRead):
(JSC::FTL::AbstractHeapRepository::decorateCCallWrite):
(JSC::FTL::AbstractHeapRepository::decoratePatchpointRead):
(JSC::FTL::AbstractHeapRepository::decoratePatchpointWrite):
(JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
* ftl/FTLAbstractHeapRepository.h:
(JSC::FTL::AbstractHeapRepository::forArrayType):
(JSC::FTL::AbstractHeapRepository::HeapForValue::HeapForValue):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::load):
(JSC::FTL::Output::load8SignExt32):
(JSC::FTL::Output::load8ZeroExt32):
(JSC::FTL::Output::load16SignExt32):
(JSC::FTL::Output::load16ZeroExt32):
(JSC::FTL::Output::store):
(JSC::FTL::Output::store32As8):
(JSC::FTL::Output::store32As16):
(JSC::FTL::Output::baseIndex):
* ftl/FTLOutput.h:
(JSC::FTL::Output::address):
(JSC::FTL::Output::absolute):
(JSC::FTL::Output::load8SignExt32):
(JSC::FTL::Output::load8ZeroExt32):
(JSC::FTL::Output::load16SignExt32):
(JSC::FTL::Output::load16ZeroExt32):
(JSC::FTL::Output::load32):
(JSC::FTL::Output::load64):
(JSC::FTL::Output::loadPtr):
(JSC::FTL::Output::loadDouble):
(JSC::FTL::Output::store32):
(JSC::FTL::Output::store64):
(JSC::FTL::Output::storePtr):
(JSC::FTL::Output::storeDouble):
(JSC::FTL::Output::ascribeRange):
(JSC::FTL::Output::nonNegative32):
(JSC::FTL::Output::load32NonNegative):
(JSC::FTL::Output::equal):
(JSC::FTL::Output::notEqual):
* ftl/FTLTypedPointer.h:
(JSC::FTL::TypedPointer::operator!):
(JSC::FTL::TypedPointer::heap):
(JSC::FTL::TypedPointer::value):
2016-02-28 Skachkov Oleksandr <gskachkov@gmail.com>
[ES6] Arrow function syntax. Emit loading&putting this/super only if they are used in arrow function
https://bugs.webkit.org/show_bug.cgi?id=153981
Reviewed by Saam Barati.
In first iteration of implemenation arrow function, we emit load and store variables 'this', 'arguments',
'super', 'new.target' in case if arrow function is exist even variables are not used in arrow function.
Current patch added logic that prevent from emiting those varibles if they are not used in arrow function.
During syntax analyze parser store information about using variables in arrow function inside of
the ordinary function scope and then put to BytecodeGenerator through UnlinkedCodeBlock
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isArgumentsUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
(JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
(JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
(JSC::EvalFunctionCallNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createBracketAccess):
(JSC::ASTBuilder::createDotAccess):
(JSC::ASTBuilder::usesSuperCall):
(JSC::ASTBuilder::usesSuperProperty):
(JSC::ASTBuilder::makeFunctionCallNode):
* parser/Nodes.cpp:
(JSC::ScopeNode::ScopeNode):
(JSC::ProgramNode::ProgramNode):
(JSC::ModuleProgramNode::ModuleProgramNode):
(JSC::EvalNode::EvalNode):
(JSC::FunctionNode::FunctionNode):
* parser/Nodes.h:
(JSC::ScopeNode::innerArrowFunctionCodeFeatures):
(JSC::ScopeNode::doAnyInnerArrowFunctionsUseArguments):
(JSC::ScopeNode::doAnyInnerArrowFunctionsUseSuperCall):
(JSC::ScopeNode::doAnyInnerArrowFunctionsUseSuperProperty):
(JSC::ScopeNode::doAnyInnerArrowFunctionsUseEval):
(JSC::ScopeNode::doAnyInnerArrowFunctionsUseThis):
(JSC::ScopeNode::doAnyInnerArrowFunctionsUseNewTarget):
(JSC::ScopeNode::doAnyInnerArrowFunctionUseAnyFeature):
(JSC::ScopeNode::usesSuperCall):
(JSC::ScopeNode::usesSuperProperty):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::isArrowFunctionBoundary):
(JSC::Scope::innerArrowFunctionFeatures):
(JSC::Scope::setInnerArrowFunctionUsesSuperCall):
(JSC::Scope::setInnerArrowFunctionUsesSuperProperty):
(JSC::Scope::setInnerArrowFunctionUsesEval):
(JSC::Scope::setInnerArrowFunctionUsesThis):
(JSC::Scope::setInnerArrowFunctionUsesNewTarget):
(JSC::Scope::setInnerArrowFunctionUsesArguments):
(JSC::Scope::setInnerArrowFunctionUsesEvalAndUseArgumentsIfNeeded):
(JSC::Scope::collectFreeVariables):
(JSC::Scope::mergeInnerArrowFunctionFeatures):
(JSC::Scope::fillParametersForSourceProviderCache):
(JSC::Scope::restoreFromSourceProviderCache):
(JSC::Scope::setIsFunction):
(JSC::Scope::setIsArrowFunction):
(JSC::Parser::closestParentNonArrowFunctionNonLexicalScope):
(JSC::Parser::pushScope):
(JSC::Parser::popScopeInternal):
(JSC::Parser<LexerType>::parse):
* parser/ParserModes.h:
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionMetadata):
* tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js:
* tests/stress/arrowfunction-lexical-bind-arguments-strict.js:
* tests/stress/arrowfunction-lexical-bind-newtarget.js:
* tests/stress/arrowfunction-lexical-bind-superproperty.js:
* tests/stress/arrowfunction-lexical-bind-this-8.js: Added.
2016-02-28 Saam barati <sbarati@apple.com>
ProxyObject.[[GetOwnProperty]] is partially broken because it doesn't propagate information back to the slot
https://bugs.webkit.org/show_bug.cgi?id=154768
Reviewed by Ryosuke Niwa.
This fixes a big bug with ProxyObject.[[GetOwnProperty]]:
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-proxy-object-internal-methods-and-internal-slots-getownproperty-p
We weren't correctly propagating the result of this operation to the
out PropertySlot& parameter. This patch fixes that and adds tests.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptor):
I added a missing exception check after object allocation
because I saw that it was missing while reading the code.
* runtime/PropertyDescriptor.cpp:
(JSC::PropertyDescriptor::setUndefined):
(JSC::PropertyDescriptor::slowGetterSetter):
(JSC::PropertyDescriptor::getter):
* runtime/PropertyDescriptor.h:
(JSC::PropertyDescriptor::attributes):
(JSC::PropertyDescriptor::value):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
* tests/es6.yaml:
* tests/stress/proxy-get-own-property.js:
(let.handler.getOwnPropertyDescriptor):
(set get let.handler.return):
(set get let.handler.getOwnPropertyDescriptor):
(set get let):
(set get let.a):
(let.b):
(let.setter):
(let.getter):
2016-02-27 Andy VanWagoner <thetalecrafter@gmail.com>
Intl.Collator uses POSIX locale (detected by js/intl-collator.html on iOS Simulator)
https://bugs.webkit.org/show_bug.cgi?id=152448
Reviewed by Darin Adler.
Add defaultLanguage to the globalObjectMethodTable and use it for the
default locale in Intl object initializations. Fall back to ICU default
locale only if the defaultLanguage function is null, or returns an
empty string.
* jsc.cpp:
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlObject.cpp:
(JSC::defaultLocale):
(JSC::lookupMatcher):
(JSC::bestFitMatcher):
(JSC::resolveLocale):
* runtime/IntlObject.h:
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
* runtime/StringPrototype.cpp:
(JSC::toLocaleCase):
2016-02-27 Oliver Hunt <oliver@apple.com>
CLoop build fix.
* jit/ExecutableAllocatorFixedVMPool.cpp:
2016-02-26 Oliver Hunt <oliver@apple.com>
Remove the on demand executable allocator
https://bugs.webkit.org/show_bug.cgi?id=154749
Reviewed by Geoffrey Garen.
Remove all the DemandExecutable code and executable allocator ifdefs.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/ExecutableAllocator.cpp: Removed.
(JSC::DemandExecutableAllocator::DemandExecutableAllocator): Deleted.
(JSC::DemandExecutableAllocator::~DemandExecutableAllocator): Deleted.
(JSC::DemandExecutableAllocator::bytesAllocatedByAllAllocators): Deleted.
(JSC::DemandExecutableAllocator::bytesCommittedByAllocactors): Deleted.
(JSC::DemandExecutableAllocator::dumpProfileFromAllAllocators): Deleted.
(JSC::DemandExecutableAllocator::allocateNewSpace): Deleted.
(JSC::DemandExecutableAllocator::notifyNeedPage): Deleted.
(JSC::DemandExecutableAllocator::notifyPageIsFree): Deleted.
(JSC::DemandExecutableAllocator::allocators): Deleted.
(JSC::DemandExecutableAllocator::allocatorsMutex): Deleted.
(JSC::ExecutableAllocator::initializeAllocator): Deleted.
(JSC::ExecutableAllocator::ExecutableAllocator): Deleted.
(JSC::ExecutableAllocator::~ExecutableAllocator): Deleted.
(JSC::ExecutableAllocator::isValid): Deleted.
(JSC::ExecutableAllocator::underMemoryPressure): Deleted.
(JSC::ExecutableAllocator::memoryPressureMultiplier): Deleted.
(JSC::ExecutableAllocator::allocate): Deleted.
(JSC::ExecutableAllocator::committedByteCount): Deleted.
(JSC::ExecutableAllocator::dumpProfile): Deleted.
(JSC::ExecutableAllocator::getLock): Deleted.
(JSC::ExecutableAllocator::isValidExecutableMemory): Deleted.
(JSC::ExecutableAllocator::reprotectRegion): Deleted.
* jit/ExecutableAllocator.h:
* jit/ExecutableAllocatorFixedVMPool.cpp:
* jit/JITStubRoutine.h:
(JSC::JITStubRoutine::canPerformRangeFilter): Deleted.
(JSC::JITStubRoutine::filteringStartAddress): Deleted.
(JSC::JITStubRoutine::filteringExtentSize): Deleted.
2016-02-26 Joseph Pecoraro <pecoraro@apple.com>
Reduce direct callers of Structure::findStructuresAndMapForMaterialization
https://bugs.webkit.org/show_bug.cgi?id=154751
Reviewed by Mark Lam.
* runtime/Structure.cpp:
(JSC::Structure::toStructureShape):
This property name iteration is identical to Structure::forEachPropertyConcurrently.
Share the code and reduce callers to the subtle findStructuresAndMapForMaterialization.
2016-02-26 Mark Lam <mark.lam@apple.com>
Function.name and Function.length should be configurable.
https://bugs.webkit.org/show_bug.cgi?id=154604
Reviewed by Saam Barati.
According to https://tc39.github.io/ecma262/#sec-ecmascript-language-functions-and-classes,
"Unless otherwise specified, the name property of a built-in Function object,
if it exists, has the attributes { [[Writable]]: false, [[Enumerable]]: false,
[[Configurable]]: true }."
Similarly, "the length property of a built-in Function object has the attributes
{ [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }."
This patch makes Function.name and Function.length configurable.
We do this by lazily reifying the JSFunction name and length properties on first
access. We track whether each of these properties have been reified using flags
in the FunctionRareData. On first access, if not already reified, we will put
the property into the object with its default value and attributes and set the
reified flag. Thereafter, we rely on the base JSObject to handle access to the
property.
Also, lots of test results have to be re-baselined because the old Function.length
has attribute DontDelete, which is in conflict with the ES6 requirement that it
is configurable.
* runtime/FunctionRareData.h:
(JSC::FunctionRareData::hasReifiedLength):
(JSC::FunctionRareData::setHasReifiedLength):
(JSC::FunctionRareData::hasReifiedName):
(JSC::FunctionRareData::setHasReifiedName):
- Flags for tracking whether each property has been reified.
* runtime/JSFunction.cpp:
(JSC::JSFunction::finishCreation):
(JSC::JSFunction::createBuiltinFunction):
- Host and builtin functions currently always reify their name and length
properties. Currently, for builtins, the default names that are used may
differ from the executable name. For now, we'll stay with keeping this
alternate approach to getting the name and length properties for host and
builtin functions.
However, we need their default attribute to be configurable as well.
(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::getOwnNonIndexPropertyNames):
(JSC::JSFunction::put):
(JSC::JSFunction::deleteProperty):
(JSC::JSFunction::defineOwnProperty):
(JSC::JSFunction::reifyLength):
(JSC::JSFunction::reifyName):
(JSC::JSFunction::reifyLazyPropertyIfNeeded):
(JSC::JSFunction::lengthGetter): Deleted.
(JSC::JSFunction::nameGetter): Deleted.
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::hasReifiedLength):
(JSC::JSFunction::hasReifiedName):
* tests/es6.yaml:
- 4 new passing tests.
* tests/mozilla/ecma/Array/15.4.4.3-1.js:
* tests/mozilla/ecma/Array/15.4.4.4-1.js:
* tests/mozilla/ecma/Array/15.4.4.4-2.js:
* tests/mozilla/ecma/GlobalObject/15.1.2.1-1.js:
* tests/mozilla/ecma/GlobalObject/15.1.2.2-1.js:
* tests/mozilla/ecma/GlobalObject/15.1.2.3-1.js:
* tests/mozilla/ecma/GlobalObject/15.1.2.4.js:
* tests/mozilla/ecma/GlobalObject/15.1.2.5-1.js:
* tests/mozilla/ecma/GlobalObject/15.1.2.6.js:
* tests/mozilla/ecma/GlobalObject/15.1.2.7.js:
* tests/mozilla/ecma/String/15.5.4.10-1.js:
* tests/mozilla/ecma/String/15.5.4.11-1.js:
* tests/mozilla/ecma/String/15.5.4.11-5.js:
* tests/mozilla/ecma/String/15.5.4.12-1.js:
* tests/mozilla/ecma/String/15.5.4.6-2.js:
* tests/mozilla/ecma/String/15.5.4.7-2.js:
* tests/mozilla/ecma/String/15.5.4.8-1.js:
* tests/mozilla/ecma/String/15.5.4.9-1.js:
- Rebase expected test results.
* tests/stress/function-configurable-properties.js: Added.
2016-02-26 Keith Miller <keith_miller@apple.com>
Folding of OverridesHasInstance DFG nodes shoud happen in constant folding not fixup
https://bugs.webkit.org/show_bug.cgi?id=154743
Reviewed by Mark Lam.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2016-02-26 Keith Miller <keith_miller@apple.com>
Native Typed Array functions should use Symbol.species
https://bugs.webkit.org/show_bug.cgi?id=154569
Reviewed by Michael Saboff.
This patch adds support for Symbol.species in the native Typed Array prototype
functions. Additionally, now that other types of typedarrays are creatable inside
the slice we use the JSGenericTypedArrayView::set function, which has been beefed
up, to put everything into the correct place.
* runtime/JSDataView.cpp:
(JSC::JSDataView::set):
* runtime/JSDataView.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewFromIterator):
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::setWithSpecificType):
(JSC::JSGenericTypedArrayView<Adaptor>::set):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewProtoFuncSubarray):
* tests/stress/typedarray-slice.js:
(subclasses.typedArrays.map):
(testSpecies):
(forEach):
(subclasses.forEach):
(testSpeciesRemoveConstructor):
(testSpeciesWithSameBuffer):
* tests/stress/typedarray-subarray.js: Added.
(subclasses.typedArrays.map):
(testSpecies):
(forEach):
(subclasses.forEach):
(testSpeciesRemoveConstructor):
2016-02-26 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add32(Imm, Tmp, Tmp) does not ZDef the destination if Imm is zero
https://bugs.webkit.org/show_bug.cgi?id=154704
Reviewed by Geoffrey Garen.
If the Imm is zero, we should still zero the top bits
to match the definition in AirOpcodes.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::add32):
* b3/testb3.cpp:
2016-02-26 Oliver Hunt <oliver@apple.com>
Make testRegExp not crash when given an invalid regexp
https://bugs.webkit.org/show_bug.cgi?id=154732
Reviewed by Mark Lam.
* testRegExp.cpp:
(parseRegExpLine):
2016-02-26 Benjamin Poulain <benjamin@webkit.org>
[JSC] Add the test for r197155
https://bugs.webkit.org/show_bug.cgi?id=154715
Reviewed by Mark Lam.
Silly me. I forgot the test in the latest patch update.
* tests/stress/class-syntax-tdz-osr-entry-in-loop.js: Added.
2016-02-26 Yusuke Suzuki <utatane.tea@gmail.com>
[DFG] Drop unnecessary proved type branch in ToPrimitive
https://bugs.webkit.org/show_bug.cgi?id=154716
Reviewed by Geoffrey Garen.
This branching based on the proved types is unnecessary because this is already handled in constant folding phase.
In fact, the DFGSpeculativeJIT64.cpp case is already removed in r164243.
This patch removes the remaining JIT32_64 case.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2016-02-25 Benjamin Poulain <bpoulain@apple.com>
[JSC] Be aggressive with OSR Entry to FTL if the DFG function was only used for OSR Entry itself
https://bugs.webkit.org/show_bug.cgi?id=154575
Reviewed by Filip Pizlo.
I noticed that imaging-gaussian-blur spends most of its
samples in DFG code despite executing most of the loop
iterations in FTL.
On this particular test, the main function is only entered
once and have a very heavy loop there. What happens is DFG
starts by compiling the full function in FTL. That takes about
8 to 10 milliseconds during which the DFG code makes very little
progress. The calls to triggerOSREntryNow() try to OSR Enter
for a while then finally start compiling something. By the time
the function is ready, we have wasted a lot of time in DFG code.
What this patch does is set a flag when a DFG function is entered.
If we try to triggerOSREntryNow() and the flag was never set,
we start compiling both the full function and the one for OSR Entry.
* dfg/DFGJITCode.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileEntryExecutionFlag):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
* dfg/DFGOperations.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan): Deleted.
* dfg/DFGPlan.h:
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
2016-02-25 Benjamin Poulain <benjamin@webkit.org>
[JSC] Temporal Dead Zone checks on "this" are eliminated when doing OSR Entry to FTL
https://bugs.webkit.org/show_bug.cgi?id=154664
Reviewed by Saam Barati.
When doing OSR Enter into a constructor, we lose the information
that this may have been set to empty by a previously executed block.
All the code just assumed the type for a FlushedJS value and thus
not an empty value. It was then okay to eliminate the TDZ checks.
In this patch, the values on root entry now assume they may be empty.
As a result, the SetArgument() for "this" has "empty" as possible
type and the TDZ checks are no longer eliminated.
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::initialize):
2016-02-25 Ada Chan <adachan@apple.com>
Update the definition of ENABLE_VIDEO_PRESENTATION_MODE for Mac platform
https://bugs.webkit.org/show_bug.cgi?id=154702
Reviewed by Dan Bernstein.
* Configurations/FeatureDefines.xcconfig:
2016-02-25 Saam barati <sbarati@apple.com>
[ES6] for...in iteration doesn't comply with the specification
https://bugs.webkit.org/show_bug.cgi?id=154665
Reviewed by Michael Saboff.
If you read ForIn/OfHeadEvaluation inside the spec:
https://tc39.github.io/ecma262/#sec-runtime-semantics-forin-div-ofheadevaluation-tdznames-expr-iterationkind
It calls EnumerateObjectProperties(obj) to get a set of properties
to enumerate over (it models this "set" as en ES6 generator function).
EnumerateObjectProperties is defined in section 13.7.5.15:
https://tc39.github.io/ecma262/#sec-enumerate-object-properties
The implementation calls Reflect.getOwnPropertyDescriptor(.) on the
properties it sees. We must do the same by modeling the operation as
a [[GetOwnProperty]] instead of a [[HasProperty]] internal method call.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSObject.cpp:
(JSC::JSObject::hasProperty):
(JSC::JSObject::hasPropertyGeneric):
* runtime/JSObject.h:
* tests/stress/proxy-get-own-property.js:
(assert):
(let.handler.getOwnPropertyDescriptor):
(i.set assert):
2016-02-25 Saam barati <sbarati@apple.com>
[ES6] Implement Proxy.[[Set]]
https://bugs.webkit.org/show_bug.cgi?id=154511
Reviewed by Filip Pizlo.
This patch is mostly an implementation of
Proxy.[[Set]] with respect to section 9.5.9
of the ECMAScript spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-set-p-v-receiver
This patch also changes JSObject::putInline and JSObject::putByIndex
to be aware that a Proxy in the prototype chain will intercept
property accesses.
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::canPerformFastPutInline):
(JSC::JSObject::putInline):
* runtime/JSType.h:
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::getOwnPropertySlotByIndex):
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::put):
(JSC::ProxyObject::putByIndexCommon):
(JSC::ProxyObject::putByIndex):
(JSC::performProxyCall):
(JSC::ProxyObject::getCallData):
(JSC::performProxyConstruct):
(JSC::ProxyObject::deletePropertyByIndex):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
(JSC::ProxyObject::create):
(JSC::ProxyObject::createStructure):
(JSC::ProxyObject::target):
(JSC::ProxyObject::handler):
* tests/es6.yaml:
* tests/stress/proxy-set.js: Added.
(assert):
(throw.new.Error.let.handler.set 45):
(throw.new.Error):
(let.target.set x):
(let.target.get x):
(set let):
2016-02-25 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove a useless "Move" in the lowering of Select
https://bugs.webkit.org/show_bug.cgi?id=154670
Reviewed by Geoffrey Garen.
I left the Move instruction when creating the aliasing form
of Select.
On ARM64, that meant a useless move for any case that can't
be coalesced.
On x86, that meant an extra constraint on child2, making it
stupidly hard to alias child1.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createSelect): Deleted.
2016-02-24 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Expose Proxy target and handler internal properties to Inspector
https://bugs.webkit.org/show_bug.cgi?id=154663
Reviewed by Timothy Hatcher.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::getInternalProperties):
Expose the ProxyObject's target and handler.
2016-02-24 Nikos Andronikos <nikos.andronikos-webkit@cisra.canon.com.au>
[web-animations] Add AnimationTimeline, DocumentTimeline and add extensions to Document interface
https://bugs.webkit.org/show_bug.cgi?id=151688
Reviewed by Dean Jackson.
Enables the WEB_ANIMATIONS compiler switch.
* Configurations/FeatureDefines.xcconfig:
2016-02-24 Konstantin Tokarev <annulen@yandex.ru>
[cmake] Moved PRE/POST_BUILD_COMMAND to WEBKIT_FRAMEWORK.
https://bugs.webkit.org/show_bug.cgi?id=154651
Reviewed by Alex Christensen.
* CMakeLists.txt: Moved shared code to WEBKIT_FRAMEWORK macro.
2016-02-24 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r197033.
https://bugs.webkit.org/show_bug.cgi?id=154649
"It broke JSC tests when 'this' was loaded from global scope"
(Requested by saamyjoon on #webkit).
Reverted changeset:
"[ES6] Arrow function syntax. Emit loading&putting this/super
only if they are used in arrow function"
https://bugs.webkit.org/show_bug.cgi?id=153981
http://trac.webkit.org/changeset/197033
2016-02-24 Saam Barati <sbarati@apple.com>
[ES6] Implement Proxy.[[Delete]]
https://bugs.webkit.org/show_bug.cgi?id=154607
Reviewed by Mark Lam.
This patch implements Proxy.[[Delete]] with respect to section 9.5.10 of the ECMAScript spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-delete-p
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::getConstructData):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::deleteProperty):
(JSC::ProxyObject::deletePropertyByIndex):
* runtime/ProxyObject.h:
* tests/es6.yaml:
* tests/stress/proxy-delete.js: Added.
(assert):
(throw.new.Error.let.handler.get deleteProperty):
(throw.new.Error):
(assert.let.handler.deleteProperty):
(let.handler.deleteProperty):
2016-02-24 Filip Pizlo <fpizlo@apple.com>
Stackmaps have problems with double register constraints
https://bugs.webkit.org/show_bug.cgi?id=154643
Reviewed by Geoffrey Garen.
This is currently a benign bug. I found it while playing.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::fillStackmap):
* b3/testb3.cpp:
(JSC::B3::testURShiftSelf64):
(JSC::B3::testPatchpointDoubleRegs):
(JSC::B3::zero):
(JSC::B3::run):
2016-02-24 Skachkov Oleksandr <gskachkov@gmail.com>
[ES6] Arrow function syntax. Emit loading&putting this/super only if they are used in arrow function
https://bugs.webkit.org/show_bug.cgi?id=153981
Reviewed by Saam Barati.
In first iteration of implemenation arrow function, we emit load and store variables 'this', 'arguments',
'super', 'new.target' in case if arrow function is exist even variables are not used in arrow function.
Current patch added logic that prevent from emiting those varibles if they are not used in arrow function.
During syntax analyze parser store information about using variables in arrow function inside of
the ordinary function scope and then put to BytecodeGenerator through UnlinkedCodeBlock
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::arrowFunctionCodeFeatures):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::arrowFunctionCodeFeatures):
(JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseArguments):
(JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseSuperCall):
(JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseSuperProperty):
(JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseEval):
(JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseThis):
(JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseNewTarget):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isArgumentsUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
(JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
(JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
(JSC::EvalFunctionCallNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionMetadata):
* parser/Nodes.cpp:
(JSC::FunctionMetadataNode::FunctionMetadataNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::isArrowFunctionBoundary):
(JSC::Scope::innerArrowFunctionFeatures):
(JSC::Scope::setInnerArrowFunctionUseSuperCall):
(JSC::Scope::setInnerArrowFunctionUseSuperProperty):
(JSC::Scope::setInnerArrowFunctionUseEval):
(JSC::Scope::setInnerArrowFunctionUseThis):
(JSC::Scope::setInnerArrowFunctionUseNewTarget):
(JSC::Scope::setInnerArrowFunctionUseArguments):
(JSC::Scope::setInnerArrowFunctionUseEvalAndUseArgumentsIfNeeded):
(JSC::Scope::collectFreeVariables):
(JSC::Scope::mergeInnerArrowFunctionFeatures):
(JSC::Scope::fillParametersForSourceProviderCache):
(JSC::Scope::restoreFromSourceProviderCache):
(JSC::Scope::setIsFunction):
(JSC::Scope::setIsArrowFunction):
(JSC::Parser::closestParentNonArrowFunctionNonLexicalScope):
(JSC::Parser::pushScope):
(JSC::Parser::popScopeInternal):
* parser/ParserModes.h:
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionMetadata):
* tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js:
* tests/stress/arrowfunction-lexical-bind-arguments-strict.js:
* tests/stress/arrowfunction-lexical-bind-newtarget.js:
* tests/stress/arrowfunction-lexical-bind-superproperty.js:
* tests/stress/arrowfunction-lexical-bind-this-8.js: Added.
2016-02-23 Brian Burg <bburg@apple.com>
Web Inspector: teach the Objective-C protocol generators about --frontend and --backend directives
https://bugs.webkit.org/show_bug.cgi?id=154615
<rdar://problem/24804330>
Reviewed by Timothy Hatcher.
Some of the generated Objective-C bindings are only relevant to code acting as the
protocol backend. Add a per-generator setting mechanism and propagate --frontend and
--backend to all generators. Use the setting in a few generators to omit code that's
not needed.
Also fix a few places where the code emits the wrong Objective-C class prefix.
There is some common non-generated code that must always have the RWIProtocol prefix.
Lastly, change includes to use RWIProtocolJSONObjectPrivate.h instead of *Internal.h. The
macros defined in the internal header now need to be used outside of the framework.
* inspector/scripts/codegen/generate_objc_conversion_helpers.py:
Use OBJC_STATIC_PREFIX along with the file name and use different include syntax
depending on the target framework.
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator.generate_output):
For now, omit generating command protocol and event dispatchers when generating for --frontend.
(ObjCHeaderGenerator._generate_type_interface):
Use OBJC_STATIC_PREFIX along with the unprefixed file name.
* inspector/scripts/codegen/generate_objc_internal_header.py:
Use RWIProtocolJSONObjectPrivate.h instead.
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.generate_output):
Include the Internal header if it's being generated (only for --backend).
* inspector/scripts/codegen/generator.py:
(Generator.__init__):
(Generator.set_generator_setting):
(Generator):
(Generator.get_generator_setting):
Crib a simple setting system from the Framework class. Make the names more obnoxious.
(Generator.string_for_file_include):
Inspired by the replay input generator, this is a function that uses the proper syntax
for a file include depending on the file's framework and target framework.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.and):
(ObjCGenerator.and.objc_prefix):
(ObjCGenerator):
(ObjCGenerator.objc_type_for_raw_name):
(ObjCGenerator.objc_class_for_raw_name):
Whitelist the 'Automation' domain for the ObjC generators. Revise use of OBJC_STATIC_PREFIX.
* inspector/scripts/generate-inspector-protocol-bindings.py:
(generate_from_specification):
Change the generators to use for the frontend. Propagate --frontend and --backend.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
Rebaseline tests. They now correctly include RWIProtocolJSONObject.h and the like.
2016-02-23 Saam barati <sbarati@apple.com>
arrayProtoFuncConcat doesn't check for an exception after allocating an array
https://bugs.webkit.org/show_bug.cgi?id=154621
Reviewed by Michael Saboff.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncConcat):
2016-02-23 Dan Bernstein <mitz@apple.com>
[Xcode] Linker errors display mangled names, but no longer should
https://bugs.webkit.org/show_bug.cgi?id=154632
Reviewed by Sam Weinig.
* Configurations/Base.xcconfig: Stop setting LINKER_DISPLAYS_MANGLED_NAMES to YES.
2016-02-23 Gavin Barraclough <barraclough@apple.com>
Remove HIDDEN_PAGE_DOM_TIMER_THROTTLING feature define
https://bugs.webkit.org/show_bug.cgi?id=112323
Reviewed by Chris Dumez.
This feature is controlled by a runtime switch, and defaults off.
* Configurations/FeatureDefines.xcconfig:
2016-02-23 Keith Miller <keith_miller@apple.com>
JSC stress tests' standalone-pre.js should exit on the first failure by default
https://bugs.webkit.org/show_bug.cgi?id=154565
Reviewed by Mark Lam.
Currently, if a test writer does not call finishJSTest() at the end of
any test using stress/resources/standalone-pre.js then the test can fail
without actually reporting an error to the harness. By default, we
should throw on the first error so, in the event someone does not call
finishJSTest() the harness will still notice the error.
* tests/stress/regress-151324.js:
* tests/stress/resources/standalone-pre.js:
(testFailed):
2016-02-23 Saam barati <sbarati@apple.com>
Make JSObject::getMethod have fewer branches
https://bugs.webkit.org/show_bug.cgi?id=154603
Reviewed by Mark Lam.
Writing code with fewer branches is almost always better.
* runtime/JSObject.cpp:
(JSC::JSObject::getMethod):
2016-02-23 Filip Pizlo <fpizlo@apple.com>
B3::Value doesn't self-destruct virtually enough (Causes many leaks in LowerDFGToB3::appendOSRExit)
https://bugs.webkit.org/show_bug.cgi?id=154592
Reviewed by Saam Barati.
If Foo has a virtual destructor, then:
foo->Foo::~Foo() does a non-virtual call to Foo's destructor. Even if foo points to a
subclass of Foo that overrides the destructor, this syntax will not call that override.
foo->~Foo() does a virtual call to the destructor, and so if foo points to a subclass, you
get the subclass's override.
In B3, we used this->Value::~Value() thinking that it would call the subclass's override.
This caused leaks because this didn't actually call the subclass's override. This fixes the
problem by using this->~Value() instead.
* b3/B3ControlValue.cpp:
(JSC::B3::ControlValue::convertToJump):
(JSC::B3::ControlValue::convertToOops):
* b3/B3Value.cpp:
(JSC::B3::Value::replaceWithIdentity):
(JSC::B3::Value::replaceWithNop):
(JSC::B3::Value::replaceWithPhi):
2016-02-23 Brian Burg <bburg@apple.com>
Web Inspector: the protocol generator's Objective-C name prefix should be configurable
https://bugs.webkit.org/show_bug.cgi?id=154596
<rdar://problem/24794962>
Reviewed by Timothy Hatcher.
In order to support different generated protocol sets that don't have conflicting
file and type names, allow the Objective-C prefix to be configurable based on the
target framework. Each name also has the implicit prefix 'Protocol' appended to the
per-target framework prefix.
For example, the existing protocol for remote inspection has the prefix 'RWI'
and is generated as 'RWIProtocol'. The WebKit framework has the 'Automation' prefix
and is generated as 'AutomationProtocol'.
To make this change, convert ObjCGenerator to be a subclass of Generator and use
the instance method model() to find the target framework and its setting for
'objc_prefix'. Make all ObjC generators subclass ObjCGenerator so they can use
these instance methods that used to be static methods. This is a large but
mechanical change to use self instead of ObjCGenerator.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator):
(ObjCBackendDispatcherHeaderGenerator.__init__):
(ObjCBackendDispatcherHeaderGenerator.output_filename):
(ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
(ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCConfigurationImplementationGenerator):
(ObjCConfigurationImplementationGenerator.__init__):
(ObjCConfigurationImplementationGenerator.output_filename):
(ObjCConfigurationImplementationGenerator.generate_output):
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command.and):
(ObjCConfigurationImplementationGenerator._generate_conversions_for_command):
* inspector/scripts/codegen/generate_objc_configuration_header.py:
(ObjCConfigurationHeaderGenerator):
(ObjCConfigurationHeaderGenerator.__init__):
(ObjCConfigurationHeaderGenerator.output_filename):
(ObjCConfigurationHeaderGenerator.generate_output):
(ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
(ObjCConfigurationHeaderGenerator._generate_properties_for_domain):
* inspector/scripts/codegen/generate_objc_configuration_implementation.py:
(ObjCBackendDispatcherImplementationGenerator):
(ObjCBackendDispatcherImplementationGenerator.__init__):
(ObjCBackendDispatcherImplementationGenerator.output_filename):
(ObjCBackendDispatcherImplementationGenerator.generate_output):
(ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
(ObjCBackendDispatcherImplementationGenerator._generate_ivars):
(ObjCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain):
(ObjCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain):
* inspector/scripts/codegen/generate_objc_conversion_helpers.py:
(ObjCConversionHelpersGenerator):
(ObjCConversionHelpersGenerator.__init__):
(ObjCConversionHelpersGenerator.output_filename):
(ObjCConversionHelpersGenerator.generate_output):
(ObjCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_declaration):
(ObjCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_member):
(ObjCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_parameter):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator):
(ObjCFrontendDispatcherImplementationGenerator.__init__):
(ObjCFrontendDispatcherImplementationGenerator.output_filename):
(ObjCFrontendDispatcherImplementationGenerator.generate_output):
(ObjCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
(ObjCFrontendDispatcherImplementationGenerator._generate_event):
(ObjCFrontendDispatcherImplementationGenerator._generate_event.and):
(ObjCFrontendDispatcherImplementationGenerator._generate_event_signature):
(ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator):
(ObjCHeaderGenerator.__init__):
(ObjCHeaderGenerator.output_filename):
(ObjCHeaderGenerator.generate_output):
(ObjCHeaderGenerator._generate_forward_declarations):
(ObjCHeaderGenerator._generate_anonymous_enum_for_declaration):
(ObjCHeaderGenerator._generate_anonymous_enum_for_member):
(ObjCHeaderGenerator._generate_anonymous_enum_for_parameter):
(ObjCHeaderGenerator._generate_type_interface):
(ObjCHeaderGenerator._generate_init_method_for_required_members):
(ObjCHeaderGenerator._generate_member_property):
(ObjCHeaderGenerator._generate_command_protocols):
(ObjCHeaderGenerator._generate_single_command_protocol):
(ObjCHeaderGenerator._callback_block_for_command):
(ObjCHeaderGenerator._generate_event_interfaces):
(ObjCHeaderGenerator._generate_single_event_interface):
* inspector/scripts/codegen/generate_objc_internal_header.py:
(ObjCInternalHeaderGenerator):
(ObjCInternalHeaderGenerator.__init__):
(ObjCInternalHeaderGenerator.output_filename):
(ObjCInternalHeaderGenerator.generate_output):
(ObjCInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator):
(ObjCProtocolTypesImplementationGenerator.__init__):
(ObjCProtocolTypesImplementationGenerator.output_filename):
(ObjCProtocolTypesImplementationGenerator.generate_output):
(ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members.and):
(ObjCProtocolTypesImplementationGenerator._generate_setter_for_member):
(ObjCProtocolTypesImplementationGenerator._generate_setter_for_member.and):
(ObjCProtocolTypesImplementationGenerator._generate_getter_for_member):
* inspector/scripts/codegen/models.py:
* inspector/scripts/codegen/objc_generator.py:
(ObjCTypeCategory.category_for_type):
(ObjCGenerator):
(ObjCGenerator.__init__):
(ObjCGenerator.objc_prefix):
(ObjCGenerator.objc_name_for_type):
(ObjCGenerator.objc_enum_name_for_anonymous_enum_declaration):
(ObjCGenerator.objc_enum_name_for_anonymous_enum_member):
(ObjCGenerator.objc_enum_name_for_anonymous_enum_parameter):
(ObjCGenerator.objc_enum_name_for_non_anonymous_enum):
(ObjCGenerator.objc_class_for_type):
(ObjCGenerator.objc_class_for_array_type):
(ObjCGenerator.objc_accessor_type_for_member):
(ObjCGenerator.objc_accessor_type_for_member_internal):
(ObjCGenerator.objc_type_for_member):
(ObjCGenerator.objc_type_for_member_internal):
(ObjCGenerator.objc_type_for_param):
(ObjCGenerator.objc_type_for_param_internal):
(ObjCGenerator.objc_protocol_export_expression_for_variable):
(ObjCGenerator.objc_protocol_import_expression_for_member):
(ObjCGenerator.objc_protocol_import_expression_for_parameter):
(ObjCGenerator.objc_protocol_import_expression_for_variable):
(ObjCGenerator.objc_to_protocol_expression_for_member):
(ObjCGenerator.protocol_to_objc_expression_for_member):
Change the prefix for the 'Test' target framework to be 'Test.' Rebaseline results.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-02-23 Mark Lam <mark.lam@apple.com>
Debug assertion failure while loading http://kangax.github.io/compat-table/es6/.
https://bugs.webkit.org/show_bug.cgi?id=154542
Reviewed by Saam Barati.
According to the spec, the constructors of the following types "are not intended
to be called as a function and will throw an exception". These types are:
TypedArrays - https://tc39.github.io/ecma262/#sec-typedarray-constructors
Map - https://tc39.github.io/ecma262/#sec-map-constructor
Set - https://tc39.github.io/ecma262/#sec-set-constructor
WeakMap - https://tc39.github.io/ecma262/#sec-weakmap-constructor
WeakSet - https://tc39.github.io/ecma262/#sec-weakset-constructor
ArrayBuffer - https://tc39.github.io/ecma262/#sec-arraybuffer-constructor
DataView - https://tc39.github.io/ecma262/#sec-dataview-constructor
Promise - https://tc39.github.io/ecma262/#sec-promise-constructor
Proxy - https://tc39.github.io/ecma262/#sec-proxy-constructor
This patch does the foillowing:
1. Ensures that these constructors can be called but will throw a TypeError
when called.
2. Makes all these objects use throwConstructorCannotBeCalledAsFunctionTypeError()
in their implementation to be consistent.
3. Change the error message to "calling XXX constructor without new is invalid".
This is clearer because the error is likely due to the user forgetting to use
the new operator on these constructors.
* runtime/Error.h:
* runtime/Error.cpp:
(JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
- Added a convenience function to throw the TypeError.
* runtime/JSArrayBufferConstructor.cpp:
(JSC::constructArrayBuffer):
(JSC::callArrayBuffer):
(JSC::JSArrayBufferConstructor::getCallData):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::callGenericTypedArrayView):
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getCallData):
* runtime/JSPromiseConstructor.cpp:
(JSC::callPromise):
* runtime/MapConstructor.cpp:
(JSC::callMap):
* runtime/ProxyConstructor.cpp:
(JSC::callProxy):
(JSC::ProxyConstructor::getCallData):
* runtime/SetConstructor.cpp:
(JSC::callSet):
* runtime/WeakMapConstructor.cpp:
(JSC::callWeakMap):
* runtime/WeakSetConstructor.cpp:
(JSC::callWeakSet):
* tests/es6.yaml:
- The typed_arrays_%TypedArray%[Symbol.species].js test now passes.
* tests/stress/call-non-calleable-constructors-as-function.js: Added.
(test):
* tests/stress/map-constructor.js:
(testCallTypeError):
* tests/stress/promise-cannot-be-called.js:
(shouldThrow):
* tests/stress/proxy-basic.js:
* tests/stress/set-constructor.js:
* tests/stress/throw-from-ftl-call-ic-slow-path-cells.js:
(i.catch):
* tests/stress/throw-from-ftl-call-ic-slow-path-undefined.js:
(i.catch):
* tests/stress/throw-from-ftl-call-ic-slow-path.js:
(i.catch):
* tests/stress/weak-map-constructor.js:
(testCallTypeError):
* tests/stress/weak-set-constructor.js:
- Updated error message string.
2016-02-23 Alexey Proskuryakov <ap@apple.com>
ASan build fix.
Let's not export a template function that is only used in InspectorBackendDispatcher.cpp.
* inspector/InspectorBackendDispatcher.h:
2016-02-23 Brian Burg <bburg@apple.com>
Connect WebAutomationSession to its backend dispatcher as if it were an agent and add stub implementations
https://bugs.webkit.org/show_bug.cgi?id=154518
<rdar://problem/24761096>
Reviewed by Timothy Hatcher.
* inspector/InspectorBackendDispatcher.h:
Export all the classes since they are used by WebKit::WebAutomationSession.
2016-02-22 Brian Burg <bburg@apple.com>
Web Inspector: add 'Automation' protocol domain and generate its backend classes separately in WebKit2
https://bugs.webkit.org/show_bug.cgi?id=154509
<rdar://problem/24759098>
Reviewed by Timothy Hatcher.
Add a new 'WebKit' framework, which is used to generate protocol code
in WebKit2.
Add --backend and --frontend flags to the main generator script.
These allow a framework to trigger two different sets of generators
so they can be separately generated and compiled.
* inspector/scripts/codegen/models.py:
(Framework.fromString):
(Frameworks): Add new framework.
* inspector/scripts/generate-inspector-protocol-bindings.py:
If neither --backend or --frontend is specified, assume both are wanted.
This matches the behavior for JavaScriptCore and WebInspector frameworks.
(generate_from_specification):
Generate C++ files for the backend and Objective-C files for the frontend.
2016-02-22 Saam barati <sbarati@apple.com>
JSGlobalObject doesn't visit ProxyObjectStructure during GC
https://bugs.webkit.org/show_bug.cgi?id=154564
Rubber stamped by Mark Lam.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::visitChildren):
2016-02-22 Saam barati <sbarati@apple.com>
InternalFunction::createSubclassStructure doesn't take into account that get() might throw
https://bugs.webkit.org/show_bug.cgi?id=154548
Reviewed by Mark Lam and Geoffrey Garen and Andreas Kling.
InternalFunction::createSubclassStructure calls newTarget.get(...) which can throw
an exception. Neither the function nor the call sites of the function took this into
account. This patch audits the call sites of the function to make it work in
the event that an exception is thrown.
* runtime/BooleanConstructor.cpp:
(JSC::constructWithBooleanConstructor):
* runtime/DateConstructor.cpp:
(JSC::constructDate):
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructure):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::constructArrayBuffer):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayView):
* runtime/JSGlobalObject.h:
(JSC::constructEmptyArray):
(JSC::constructArray):
(JSC::constructArrayNegativeIndexed):
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/NativeErrorConstructor.cpp:
(JSC::Interpreter::constructWithNativeErrorConstructor):
* runtime/NumberConstructor.cpp:
(JSC::constructWithNumberConstructor):
* runtime/RegExpConstructor.cpp:
(JSC::getRegExpStructure):
(JSC::constructRegExp):
(JSC::constructWithRegExpConstructor):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/StringConstructor.cpp:
(JSC::constructWithStringConstructor):
(JSC::StringConstructor::getConstructData):
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
* runtime/WeakSetConstructor.cpp:
(JSC::constructWeakSet):
* tests/stress/create-subclass-structure-might-throw.js: Added.
(assert):
2016-02-22 Ting-Wei Lan <lantw44@gmail.com>
Fix build and implement functions to retrieve registers on FreeBSD
https://bugs.webkit.org/show_bug.cgi?id=152258
Reviewed by Michael Catanzaro.
* heap/MachineStackMarker.cpp:
(pthreadSignalHandlerSuspendResume):
struct ucontext is not specified in POSIX and it is not available on
FreeBSD. Replacing it with ucontext_t fixes the build problem.
(JSC::MachineThreads::Thread::Registers::stackPointer):
(JSC::MachineThreads::Thread::Registers::framePointer):
(JSC::MachineThreads::Thread::Registers::instructionPointer):
(JSC::MachineThreads::Thread::Registers::llintPC):
* heap/MachineStackMarker.h:
2016-02-22 Saam barati <sbarati@apple.com>
JSValue::isConstructor and JSValue::isFunction should check getConstructData and getCallData
https://bugs.webkit.org/show_bug.cgi?id=154552
Reviewed by Mark Lam.
ES6 Proxy breaks our isFunction() and isConstructor() JSValue methods.
They return false on a Proxy with internal [[Call]] and [[Construct]]
properties. It seems safest, most forward looking, and most adherent
to the specification to check getCallData() and getConstructData() to
implement these functions.
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructure):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::isFunction):
(JSC::JSValue::isConstructor):
2016-02-22 Keith Miller <keith_miller@apple.com>
Bound functions should use the prototype of the function being bound
https://bugs.webkit.org/show_bug.cgi?id=154195
Reviewed by Geoffrey Garen.
Per ES6, the result of Function.prototype.bind should have the same
prototype as the the function being bound. In order to avoid creating
a new structure each time a function is bound we store the new
structure in our structure map. However, we cannot currently store
structures that have a different GlobalObject than their prototype.
In the rare case that the GlobalObject differs or the prototype of
the bindee is null we create a new structure each time. To further
minimize new structures, as well as making structure lookup faster,
we also store the structure in the RareData of the function we
are binding.
* runtime/FunctionRareData.cpp:
(JSC::FunctionRareData::visitChildren):
* runtime/FunctionRareData.h:
(JSC::FunctionRareData::getBoundFunctionStructure):
(JSC::FunctionRareData::setBoundFunctionStructure):
* runtime/JSBoundFunction.cpp:
(JSC::getBoundFunctionStructure):
(JSC::JSBoundFunction::create):
* tests/es6.yaml:
* tests/stress/bound-function-uses-prototype.js: Added.
(testChangeProto.foo):
(testChangeProto):
(testBuiltins):
* tests/stress/class-subclassing-function.js:
2016-02-22 Keith Miller <keith_miller@apple.com>
Unreviewed, fix stress test to not print on success.
* tests/stress/call-apply-builtin-functions-dont-use-iterators.js:
(catch): Deleted.
2016-02-22 Keith Miller <keith_miller@apple.com>
Use Symbol.species in the builtin TypedArray.prototype functions
https://bugs.webkit.org/show_bug.cgi?id=153384
Reviewed by Geoffrey Garen.
This patch adds the use of species constructors to the TypedArray.prototype map and filter
functions. It also adds a new private function typedArrayGetOriginalConstructor that
returns the TypedArray constructor used to originally create a TypedArray instance.
There are no ES6 tests to update for this patch as species creation for these functions is
not tested in the compatibility table.
* builtins/TypedArrayPrototype.js:
(map):
(filter):
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
* bytecode/BytecodeIntrinsicRegistry.h:
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::typedArrayConstructor):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::typedArrayViewPrivateFuncGetOriginalConstructor):
* runtime/JSTypedArrayViewPrototype.h:
* tests/stress/typedarray-filter.js:
(subclasses.typedArrays.map):
(prototype.accept):
(testSpecies):
(accept):
(forEach):
(subclasses.forEach):
(testSpeciesRemoveConstructor):
* tests/stress/typedarray-map.js:
(subclasses.typedArrays.map):
(prototype.id):
(testSpecies):
(id):
(forEach):
(subclasses.forEach):
(testSpeciesRemoveConstructor):
2016-02-22 Keith Miller <keith_miller@apple.com>
Builtins that should not rely on iteration do.
https://bugs.webkit.org/show_bug.cgi?id=154475
Reviewed by Geoffrey Garen.
When changing the behavior of varargs calls to use ES6 iterators the
call builtin function's use of a varargs call was overlooked. The use
of iterators is observable outside the scope of the the call function,
thus it must be reimplemented.
* builtins/FunctionPrototype.js:
(call):
* tests/stress/call-apply-builtin-functions-dont-use-iterators.js: Added.
(test):
(addAll):
(catch):
2016-02-22 Konstantin Tokarev <annulen@yandex.ru>
[JSC shell] Don't put empty arguments array to VM.
https://bugs.webkit.org/show_bug.cgi?id=154516
Reviewed by Geoffrey Garen.
This allows arrowfunction-lexical-bind-arguments-top-level test to pass
in jsc as well as in browser.
* jsc.cpp:
(GlobalObject::finishCreation):
2016-02-22 Konstantin Tokarev <annulen@yandex.ru>
[cmake] Moved library setup code to WEBKIT_FRAMEWORK macro.
https://bugs.webkit.org/show_bug.cgi?id=154450
Reviewed by Alex Christensen.
* CMakeLists.txt:
2016-02-22 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r196891.
https://bugs.webkit.org/show_bug.cgi?id=154539
it broke Production builds (Requested by brrian on #webkit).
Reverted changeset:
"Web Inspector: add 'Automation' protocol domain and generate
its backend classes separately in WebKit2"
https://bugs.webkit.org/show_bug.cgi?id=154509
http://trac.webkit.org/changeset/196891
2016-02-21 Joseph Pecoraro <pecoraro@apple.com>
CodeBlock always visits its unlinked code twice
https://bugs.webkit.org/show_bug.cgi?id=154494
Reviewed by Saam Barati.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
The unlinked code is always visited in stronglyVisitStrongReferences.
2016-02-21 Brian Burg <bburg@apple.com>
Web Inspector: add 'Automation' protocol domain and generate its backend classes separately in WebKit2
https://bugs.webkit.org/show_bug.cgi?id=154509
<rdar://problem/24759098>
Reviewed by Timothy Hatcher.
Add a new 'WebKit' framework, which is used to generate protocol code
in WebKit2.
Add --backend and --frontend flags to the main generator script.
These allow a framework to trigger two different sets of generators
so they can be separately generated and compiled.
* inspector/scripts/codegen/models.py:
(Framework.fromString):
(Frameworks): Add new framework.
* inspector/scripts/generate-inspector-protocol-bindings.py:
If neither --backend or --frontend is specified, assume both are wanted.
This matches the behavior for JavaScriptCore and WebInspector frameworks.
(generate_from_specification):
Generate C++ files for the backend and Objective-C files for the frontend.
2016-02-21 Sukolsak Sakshuwong <sukolsak@gmail.com>
Improvements to Intl code
https://bugs.webkit.org/show_bug.cgi?id=154486
Reviewed by Darin Adler.
This patch does several things:
- Use std::unique_ptr to store ICU objects.
- Pass Vector::size() to ICU functions that take a buffer size instead
of Vector::capacity().
- If U_SUCCESS(status) is true, it means there is no error, but there
could be warnings. ICU functions ignore warnings. So, there is no need
to reset status to U_ZERO_ERROR.
- Remove the initialization of the String instance variables of
IntlDateTimeFormat. These values are never read and cause unnecessary
memory allocation.
- Fix coding style.
- Some small optimization.
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::UCollatorDeleter::operator()):
(JSC::IntlCollator::createCollator):
(JSC::IntlCollator::compareStrings):
(JSC::IntlCollator::~IntlCollator): Deleted.
* runtime/IntlCollator.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::UDateFormatDeleter::operator()):
(JSC::defaultTimeZone):
(JSC::canonicalizeTimeZoneName):
(JSC::toDateTimeOptionsAnyDate):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::weekdayString):
(JSC::IntlDateTimeFormat::format):
(JSC::IntlDateTimeFormat::~IntlDateTimeFormat): Deleted.
(JSC::localeData): Deleted.
* runtime/IntlDateTimeFormat.h:
* runtime/IntlDateTimeFormatConstructor.cpp:
* runtime/IntlNumberFormatConstructor.cpp:
* runtime/IntlObject.cpp:
(JSC::numberingSystemsForLocale):
2016-02-21 Skachkov Oleksandr <gskachkov@gmail.com>
Remove arrowfunction test cases that rely on arguments variable in jsc
https://bugs.webkit.org/show_bug.cgi?id=154517
Reviewed by Yusuke Suzuki.
Allow to jsc has the same behavior in javascript as browser has
* tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js:
* tests/stress/arrowfunction-lexical-bind-arguments-strict.js:
2016-02-21 Brian Burg <bburg@apple.com>
Web Inspector: it should be possible to omit generated code guarded by INSPECTOR_ALTERNATE_DISPATCHERS
https://bugs.webkit.org/show_bug.cgi?id=154508
<rdar://problem/24759077>
Reviewed by Timothy Hatcher.
In preparation for being able to generate protocol files for WebKit2,
make it possible to not emit generated code that's guarded by
ENABLE(INSPECTOR_ALTERNATE_DISPATCHERS). This code is not needed by
backend dispatchers generated outside of JavaScriptCore. We can't just
define it to 0 for WebKit2, since it's defined to 1 in <wtf/Platform.h>
in the configurations where the code is actually used.
Add a new opt-in Framework configuration option that turns on generating
this code. Adjust how the code is generated so that it can be easily excluded.
* inspector/scripts/codegen/cpp_generator_templates.py:
Make a separate template for the declarations that are guarded.
Add an initializer expression so the order of initalizers doesn't matter.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator.generate_output): Add a setting check.
(CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
If the declarations are needed, they will be appended to the end of the
declarations list.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator.generate_output): Add a setting check.
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): Add a setting check.
* inspector/scripts/codegen/models.py: Set the 'alternate_dispatchers' setting
to True for Framework.JavaScriptCore only. It's not needed elsewhere.
Rebaseline affected tests.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2016-02-21 Brian Burg <bburg@apple.com>
Web Inspector: clean up generator selection in generate-inspector-protocol-bindings.py
https://bugs.webkit.org/show_bug.cgi?id=154505
<rdar://problem/24758042>
Reviewed by Timothy Hatcher.
It should be possible to generate code for a framework using some generators
that other frameworks also use. Right now the generator selection code assumes
that use of a generator is mutually exclusive among non-test frameworks.
Make this code explicitly switch on the framework. Reorder generators
alpabetically within each case.
* inspector/scripts/generate-inspector-protocol-bindings.py:
(generate_from_specification):
Rebaseline tests that are affected by generator reorderings.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-02-19 Saam Barati <sbarati@apple.com>
[ES6] Implement Proxy.[[Construct]]
https://bugs.webkit.org/show_bug.cgi?id=154440
Reviewed by Oliver Hunt.
This patch is mostly an implementation of
Proxy.[[Construct]] with respect to section 9.5.13
of the ECMAScript spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-construct-argumentslist-newtarget
This patch also changes op_create_this to accept new.target's
that aren't JSFunctions. This is necessary implementing Proxy.[[Construct]]
because we might construct a JSFunction with a new.target being
a Proxy. This will also be needed when we implement Reflect.construct.
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emitSlow_op_create_this):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emitSlow_op_create_this):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::finishCreation):
(JSC::ProxyObject::visitChildren):
(JSC::performProxyConstruct):
(JSC::ProxyObject::getConstructData):
* runtime/ProxyObject.h:
* tests/es6.yaml:
* tests/stress/proxy-construct.js: Added.
(assert):
(throw.new.Error.let.target):
(throw.new.Error):
(assert.let.target):
(assert.let.handler.get construct):
(let.target):
(let.handler.construct):
(i.catch):
(assert.let.handler.construct):
(assert.let.construct):
(assert.else.assert.let.target):
(assert.else.assert.let.construct):
(assert.else.assert):
(new.proxy.let.target):
(new.proxy.let.construct):
(new.proxy):
2016-02-19 Sukolsak Sakshuwong <sukolsak@gmail.com>
[INTL] Implement Number Format Functions
https://bugs.webkit.org/show_bug.cgi?id=147605
Reviewed by Darin Adler.
This patch implements Intl.NumberFormat.prototype.format() according
to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.)
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::UNumberFormatDeleter::operator()):
(JSC::IntlNumberFormat::initializeNumberFormat):
(JSC::IntlNumberFormat::createNumberFormat):
(JSC::IntlNumberFormat::formatNumber):
(JSC::IntlNumberFormatFuncFormatNumber): Deleted.
* runtime/IntlNumberFormat.h:
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatFuncFormatNumber):
2016-02-18 Gavin Barraclough <barraclough@apple.com>
JSObject::getPropertySlot - index-as-propertyname, override on prototype, & shadow
https://bugs.webkit.org/show_bug.cgi?id=154416
Reviewed by Geoff Garen.
Here's the bug. Suppose you call JSObject::getOwnProperty and -
- PropertyName contains an index,
- An object on the prototype chain overrides getOwnPropertySlot, and has that index property,
- The base of the access (or another object on the prototype chain) shadows that property.
JSObject::getPropertySlot is written assuming the common case is that propertyName is not an
index, and as such walks up the prototype chain looking for non-index properties before it
tries calling parseIndex.
At the point we reach an object on the prototype chain overriding getOwnPropertySlot (which
would potentially return the property) we may have already skipped over non-overriding
objects that contain the property in index storage.
* runtime/JSObject.h:
(JSC::JSObject::getOwnNonIndexPropertySlot):
- renamed from inlineGetOwnPropertySlot to better describe behaviour;
added ASSERT guarding that this method never returns index properties -
if it ever does, this is unsafe for getPropertySlot.
(JSC::JSObject::getOwnPropertySlot):
- inlineGetOwnPropertySlot -> getOwnNonIndexPropertySlot.
(JSC::JSObject::getPropertySlot):
- In case of object overriding getOwnPropertySlot check if propertyName is an index.
(JSC::JSObject::getNonIndexPropertySlot):
- called by getPropertySlot if we encounter an object that overrides getOwnPropertySlot,
in order to avoid repeated calls to parseIndex.
(JSC::JSObject::inlineGetOwnPropertySlot): Deleted.
- this was renamed to getOwnNonIndexPropertySlot.
(JSC::JSObject::fastGetOwnPropertySlot): Deleted.
- this was folded back in to getPropertySlot.
2016-02-19 Saam Barati <sbarati@apple.com>
[ES6] Implement Proxy.[[Call]]
https://bugs.webkit.org/show_bug.cgi?id=154425
Reviewed by Mark Lam.
This patch is a straight forward implementation of
Proxy.[[Call]] with respect to section 9.5.12
of the ECMAScript spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-call-thisargument-argumentslist
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::finishCreation):
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::getOwnPropertySlotByIndex):
(JSC::performProxyCall):
(JSC::ProxyObject::getCallData):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
(JSC::ProxyObject::create):
* tests/es6.yaml:
* tests/stress/proxy-call.js: Added.
(assert):
(throw.new.Error.let.target):
(throw.new.Error.let.handler.apply):
(throw.new.Error):
(assert.let.target):
(assert.let.handler.get apply):
(let.target):
(let.handler.apply):
(i.catch):
(assert.let.handler.apply):
2016-02-19 Csaba Osztrogonác <ossy@webkit.org>
Remove more LLVM related dead code after r196729
https://bugs.webkit.org/show_bug.cgi?id=154387
Reviewed by Filip Pizlo.
* Configurations/CompileRuntimeToLLVMIR.xcconfig: Removed.
* Configurations/LLVMForJSC.xcconfig: Removed.
* JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.props: Removed.
* JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj: Removed.
* JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj.filters: Removed.
* JavaScriptCore.xcodeproj/project.pbxproj:
* disassembler/X86Disassembler.cpp:
2016-02-19 Joseph Pecoraro <pecoraro@apple.com>
Add isJSString(JSCell*) variant to avoid Cell->JSValue->Cell conversion
https://bugs.webkit.org/show_bug.cgi?id=154442
Reviewed by Saam Barati.
* runtime/JSString.h:
(JSC::isJSString):
2016-02-19 Joseph Pecoraro <pecoraro@apple.com>
Remove unused SymbolTable::createNameScopeTable
https://bugs.webkit.org/show_bug.cgi?id=154443
Reviewed by Saam Barati.
* runtime/SymbolTable.h:
2016-02-18 Benjamin Poulain <bpoulain@apple.com>
[JSC] Improve the instruction selection of Select
https://bugs.webkit.org/show_bug.cgi?id=154432
Reviewed by Filip Pizlo.
Plenty of code but this patch is pretty dumb:
-On ARM64: use the 3 operand form of CSEL instead of forcing a source
to be alised to the destination. This gives more freedom to the register
allocator and it is one less Move to process per Select.
-On x86, introduce a fake 3 operands form and use aggressive aliasing
to try to alias both sources to the destination.
If aliasing succeed on the "elseCase", the condition of the Select
is reverted in the MacroAssembler.
If no aliasing is possible and we end up with 3 registers, the missing
move instruction is generated by the MacroAssembler.
The missing move is generated after testing the values because the destination
can use the same register as one of the test operand.
Experimental testing seems to indicate there is no macro-fusion on CMOV,
there is no measurable cost to having the move there.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::isInvertible):
(JSC::MacroAssembler::invert):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::moveConditionallyDouble):
(JSC::MacroAssemblerARM64::moveConditionallyFloat):
(JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare):
(JSC::MacroAssemblerARM64::moveConditionally32):
(JSC::MacroAssemblerARM64::moveConditionally64):
(JSC::MacroAssemblerARM64::moveConditionallyTest32):
(JSC::MacroAssemblerARM64::moveConditionallyTest64):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::moveConditionallyDouble):
(JSC::MacroAssemblerX86Common::moveConditionallyFloat):
(JSC::MacroAssemblerX86Common::moveConditionally32):
(JSC::MacroAssemblerX86Common::moveConditionallyTest32):
(JSC::MacroAssemblerX86Common::invert):
(JSC::MacroAssemblerX86Common::isInvertible):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::moveConditionally64):
(JSC::MacroAssemblerX86_64::moveConditionallyTest64):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createSelect):
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::shouldTryAliasingDef):
* b3/air/AirOpcode.opcodes:
2016-02-18 Gyuyoung Kim <gyuyoung.kim@webkit.org>
[CMake][GTK] Clean up llvm guard in PlatformGTK.cmake
https://bugs.webkit.org/show_bug.cgi?id=154430
Reviewed by Saam Barati.
llvm isn't used anymore.
* PlatformGTK.cmake: Remove USE_LLVM_DISASSEMBLER guard.
2016-02-18 Saam Barati <sbarati@apple.com>
Implement Proxy.[[HasProperty]]
https://bugs.webkit.org/show_bug.cgi?id=154313
Reviewed by Filip Pizlo.
This patch is a straight forward implementation of
Proxy.[[HasProperty]] with respect to section 9.5.7
of the ECMAScript spec.
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-hasproperty-p
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::getOwnPropertySlotCommon):
* runtime/ProxyObject.h:
* tests/es6.yaml:
* tests/stress/proxy-basic.js:
(assert):
(let.handler.has):
* tests/stress/proxy-has-property.js: Added.
(assert):
(throw.new.Error.let.handler.get has):
(throw.new.Error):
(assert.let.handler.has):
(let.handler.has):
(getOwnPropertyDescriptor):
(i.catch):
2016-02-18 Saam Barati <sbarati@apple.com>
Proxy's don't properly handle Symbols as PropertyKeys.
https://bugs.webkit.org/show_bug.cgi?id=154385
Reviewed by Mark Lam and Yusuke Suzuki.
We were converting all PropertyKeys to strings, even when
the PropertyName was a Symbol. In the spec, PropertyKeys are
either a Symbol or a String. We now respect that in Proxy.[[Get]] and
Proxy.[[GetOwnProperty]].
* runtime/Completion.cpp:
(JSC::profiledEvaluate):
(JSC::createSymbolForEntryPointModule):
(JSC::identifierToJSValue): Deleted.
* runtime/Identifier.h:
(JSC::parseIndex):
* runtime/IdentifierInlines.h:
(JSC::Identifier::fromString):
(JSC::identifierToJSValue):
(JSC::identifierToSafePublicJSValue):
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
* tests/es6.yaml:
* tests/stress/proxy-basic.js:
(let.handler.getOwnPropertyDescriptor):
2016-02-18 Saam Barati <sbarati@apple.com>
Follow up fix to Implement Proxy.[[GetOwnProperty]]
https://bugs.webkit.org/show_bug.cgi?id=154314
Reviewed by Filip Pizlo.
Part of the implementation was broken because
of how JSObject::getOwnPropertyDescriptor worked.
I've fixed JSObject::getOwnPropertyDescriptor to
be able to handle ProxyObject.
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyDescriptor):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
* tests/stress/proxy-get-own-property.js:
(assert):
(assert.let.handler.get getOwnPropertyDescriptor):
2016-02-18 Saam Barati <sbarati@apple.com>
Implement Proxy.[[GetOwnProperty]]
https://bugs.webkit.org/show_bug.cgi?id=154314
Reviewed by Filip Pizlo.
This patch implements Proxy.[[GetOwnProperty]].
It's a straight forward implementation as described
in section 9.5.5 of the specification:
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-proxy-object-internal-methods-and-internal-slots-getownproperty-p
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncBind):
* runtime/JSObject.cpp:
(JSC::validateAndApplyPropertyDescriptor):
(JSC::JSObject::defineOwnNonIndexProperty):
(JSC::JSObject::defineOwnProperty):
(JSC::JSObject::getGenericPropertyNames):
(JSC::JSObject::getMethod):
* runtime/JSObject.h:
(JSC::JSObject::butterflyAddress):
(JSC::makeIdentifier):
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::getOwnPropertySlotCommon):
(JSC::ProxyObject::getOwnPropertySlot):
(JSC::ProxyObject::getOwnPropertySlotByIndex):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h:
* tests/es6.yaml:
* tests/stress/proxy-basic.js:
(let.handler.get null):
* tests/stress/proxy-get-own-property.js: Added.
(assert):
(throw.new.Error.let.handler.getOwnPropertyDescriptor):
(throw.new.Error):
(let.handler.getOwnPropertyDescriptor):
(i.catch):
(assert.let.handler.getOwnPropertyDescriptor):
2016-02-18 Andreas Kling <akling@apple.com>
JSString resolution of substrings should use StringImpl sharing optimization.
<https://webkit.org/b/154068>
<rdar://problem/24629358>
Reviewed by Antti Koivisto.
When resolving a JSString that's actually a substring of another JSString,
use the StringImpl sharing optimization to create a new string pointing into
the parent one, instead of copying out the bytes of the string.
This dramatically reduces peak memory usage on Gerrit diff viewer pages.
Another approach to this would be to induce GC far more frequently due to
the added cost of copying out these substrings. It would reduce the risk
of prolonging the life of strings only kept alive by substrings.
This patch chooses to trade that risk for less GC and lower peak memory.
* runtime/JSString.cpp:
(JSC::JSRopeString::resolveRope):
2016-02-18 Chris Dumez <cdumez@apple.com>
Crash on SES selftest page when loading the page while WebInspector is open
https://bugs.webkit.org/show_bug.cgi?id=154378
<rdar://problem/24713422>
Reviewed by Mark Lam.
Do a partial revert of r196676 so that JSObject::getOwnPropertyDescriptor()
returns early again if it detects that getOwnPropertySlot() returns a
non-own property. This check was removed in r196676 because we assumed that
only JSDOMWindow::getOwnPropertySlot() could return non-own properties.
However, as it turns out, DebuggerScope::getOwnPropertySlot() does so as
well.
Not having the check would lead to crashes when using the debugger because
we would get a slot with the CustomAccessor attribute but getDirect() would
then fail to return the property (because it is not an own property). We
would then cast the value returned by getDirect() to a CustomGetterSetter*
and dereference it.
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyDescriptor):
2016-02-18 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix VS build. I didn't know we still did that, but apparently there's a bot
for that.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2016-02-18 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix CMake build. This got messed up when rebasing.
* CMakeLists.txt:
2016-02-18 Csaba Osztrogonác <ossy@webkit.org>
Fix the !ENABLE(DFG_JIT) build after r195865
https://bugs.webkit.org/show_bug.cgi?id=154391
Reviewed by Filip Pizlo.
* runtime/SamplingProfiler.cpp:
(JSC::tryGetBytecodeIndex):
2016-02-17 Filip Pizlo <fpizlo@apple.com>
Remove remaining references to LLVM, and make sure comments refer to the backend as "B3" not "LLVM"
https://bugs.webkit.org/show_bug.cgi?id=154383
Reviewed by Saam Barati.
I did a grep -i llvm of all of our code and did one of the following for each occurence:
- Renamed it to B3. This is appropriate when we were using "LLVM" to mean "the FTL
backend".
- Removed the reference because I found it to be dead. In some cases it was a dead
comment: it was telling us things about what LLVM did and that's just not relevant
anymore. In other cases it was dead code that I forgot to delete in a previous patch.
- Edited the comment in some smart way. There were comments talking about what LLVM did
that were still of interest. In some cases, I added a FIXME to consider changing the
code below the comment on the grounds that it was written in a weird way to placate
LLVM and so we can do it better now.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGOSRAvailabilityAnalysisPhase.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::compileInThreadImpl):
(JSC::DFG::Plan::compileTimeStats):
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGSSAConversionPhase.h:
* dfg/DFGStaticExecutionCountEstimationPhase.h:
* dfg/DFGUnificationPhase.cpp:
(JSC::DFG::UnificationPhase::run):
* disassembler/ARM64Disassembler.cpp:
(JSC::tryToDisassemble): Deleted.
* disassembler/X86Disassembler.cpp:
(JSC::tryToDisassemble):
* ftl/FTLAbstractHeap.cpp:
(JSC::FTL::IndexedAbstractHeap::initialize):
* ftl/FTLAbstractHeap.h:
* ftl/FTLFormattedValue.h:
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLocation.cpp:
(JSC::FTL::Location::restoreInto):
* ftl/FTLLowerDFGToB3.cpp: Copied from Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.cpp.
(JSC::FTL::DFG::ftlUnreachable):
(JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
(JSC::FTL::DFG::LowerDFGToB3::compileBlock):
(JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
(JSC::FTL::DFG::LowerDFGToB3::isBoolean):
(JSC::FTL::DFG::LowerDFGToB3::unboxBoolean):
(JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
(JSC::FTL::lowerDFGToB3):
(JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::compileBlock): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithNegate): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::compileMultiGetByOffset): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::compileOverridesHasInstance): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::isBoolean): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::unboxBoolean): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier): Deleted.
(JSC::FTL::lowerDFGToLLVM): Deleted.
* ftl/FTLLowerDFGToB3.h: Copied from Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.h.
* ftl/FTLLowerDFGToLLVM.cpp: Removed.
* ftl/FTLLowerDFGToLLVM.h: Removed.
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* ftl/FTLWeight.h:
(JSC::FTL::Weight::frequencyClass):
(JSC::FTL::Weight::inverse):
(JSC::FTL::Weight::scaleToTotal): Deleted.
* ftl/FTLWeightedTarget.h:
(JSC::FTL::rarely):
(JSC::FTL::unsure):
* jit/CallFrameShuffler64.cpp:
(JSC::CallFrameShuffler::emitDisplace):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::ftlCalleeSaveRegisters):
* llvm: Removed.
* llvm/InitializeLLVMLinux.cpp: Removed.
* llvm/InitializeLLVMWin.cpp: Removed.
* llvm/library: Removed.
* llvm/library/LLVMTrapCallback.h: Removed.
* llvm/library/libllvmForJSC.version: Removed.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
(JSC::Options::initialize):
* runtime/Options.h:
* wasm/WASMFunctionB3IRGenerator.h: Copied from Source/JavaScriptCore/wasm/WASMFunctionLLVMIRGenerator.h.
* wasm/WASMFunctionLLVMIRGenerator.h: Removed.
* wasm/WASMFunctionParser.cpp:
2016-02-18 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Build system cleanup
https://bugs.webkit.org/show_bug.cgi?id=154337
Reviewed by Žan Doberšek.
* CMakeLists.txt:
2016-02-17 Mark Lam <mark.lam@apple.com>
Callers of JSString::value() should check for exceptions thereafter.
https://bugs.webkit.org/show_bug.cgi?id=154346
Reviewed by Geoffrey Garen.
JSString::value() can throw an exception if the JS string is a rope and value()
needs to resolve the rope but encounters an OutOfMemory error. If value() is not
able to resolve the rope, it will return a null string (in addition to throwing
the exception). If a caller does not check for exceptions after calling
JSString::value(), they may eventually use the returned null string and crash the
VM.
The fix is to add all the necessary exception checks, and do the appropriate
handling if needed.
* jsc.cpp:
(functionRun):
(functionLoad):
(functionReadFile):
(functionCheckSyntax):
(functionLoadWebAssembly):
(functionLoadModule):
(functionCheckModuleSyntax):
* runtime/DateConstructor.cpp:
(JSC::dateParse):
(JSC::dateNow):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* tools/JSDollarVMPrototype.cpp:
(JSC::functionPrint):
2016-02-17 Benjamin Poulain <bpoulain@apple.com>
[JSC] ARM64: Support the immediate format used for bit operations in Air
https://bugs.webkit.org/show_bug.cgi?id=154327
Reviewed by Filip Pizlo.
ARM64 supports a pretty rich form of immediates for bit operation.
There are two formats used to encode repeating patterns and common
input in a dense form.
In this patch, I add 2 new type of Arg: BitImm32 and BitImm64.
Those represents the valid immediate forms for bit operation.
On x86, any 32bits value is valid. On ARM64, all the encoding
form are tried and the immediate is used when possible.
The arg type Imm64 is renamed to BigImm to better represent what
it is: an immediate that does not fit into Imm.
* assembler/ARM64Assembler.h:
(JSC::LogicalImmediate::create32): Deleted.
(JSC::LogicalImmediate::create64): Deleted.
(JSC::LogicalImmediate::value): Deleted.
(JSC::LogicalImmediate::isValid): Deleted.
(JSC::LogicalImmediate::is64bit): Deleted.
(JSC::LogicalImmediate::LogicalImmediate): Deleted.
(JSC::LogicalImmediate::mask): Deleted.
(JSC::LogicalImmediate::partialHSB): Deleted.
(JSC::LogicalImmediate::highestSetBit): Deleted.
(JSC::LogicalImmediate::findBitRange): Deleted.
(JSC::LogicalImmediate::encodeLogicalImmediate): Deleted.
* assembler/AssemblerCommon.h:
(JSC::ARM64LogicalImmediate::create32):
(JSC::ARM64LogicalImmediate::create64):
(JSC::ARM64LogicalImmediate::value):
(JSC::ARM64LogicalImmediate::isValid):
(JSC::ARM64LogicalImmediate::is64bit):
(JSC::ARM64LogicalImmediate::ARM64LogicalImmediate):
(JSC::ARM64LogicalImmediate::mask):
(JSC::ARM64LogicalImmediate::partialHSB):
(JSC::ARM64LogicalImmediate::highestSetBit):
(JSC::ARM64LogicalImmediate::findBitRange):
(JSC::ARM64LogicalImmediate::encodeLogicalImmediate):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::and64):
(JSC::MacroAssemblerARM64::or64):
(JSC::MacroAssemblerARM64::xor64):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::bitImm):
(JSC::B3::Air::LowerToAir::bitImm64):
(JSC::B3::Air::LowerToAir::appendBinOp):
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::dump):
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::bitImm):
(JSC::B3::Air::Arg::bitImm64):
(JSC::B3::Air::Arg::isBitImm):
(JSC::B3::Air::Arg::isBitImm64):
(JSC::B3::Air::Arg::isSomeImm):
(JSC::B3::Air::Arg::value):
(JSC::B3::Air::Arg::isGP):
(JSC::B3::Air::Arg::isFP):
(JSC::B3::Air::Arg::hasType):
(JSC::B3::Air::Arg::isValidBitImmForm):
(JSC::B3::Air::Arg::isValidBitImm64Form):
(JSC::B3::Air::Arg::isValidForm):
(JSC::B3::Air::Arg::asTrustedImm32):
(JSC::B3::Air::Arg::asTrustedImm64):
* b3/air/AirOpcode.opcodes:
* b3/air/opcode_generator.rb:
2016-02-17 Keith Miller <keith_miller@apple.com>
Spread operator should be allowed when not the first argument of parameter list
https://bugs.webkit.org/show_bug.cgi?id=152721
Reviewed by Saam Barati.
Spread arguments to functions should now be ES6 compliant. Before we
would only take a spread operator if it was the sole argument to a
function. Additionally, we would not use the Symbol.iterator on the
object to generate the arguments. Instead we would do a loop up to the
length mapping indexed properties to the corresponding argument. We fix
both these issues by doing an AST transformation from foo(...a, b, ...c, d)
to foo(...[...a, b, ...c, d]) (where the spread on the rhs uses the
old spread semantics). This solution has the downside of requiring the
allocation of another object and copying each element twice but avoids a
large change to the vm calling convention.
* interpreter/Interpreter.cpp:
(JSC::loadVarargs):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createElementList):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseArguments):
(JSC::Parser<LexerType>::parseArgument):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createElementList):
* tests/es6.yaml:
* tests/stress/spread-calling.js: Added.
(testFunction):
(testEmpty):
(makeObject):
(otherIterator.return.next):
(otherIterator):
(totalIter):
(throwingIter.return.next):
(throwingIter):
(i.catch):
2016-02-17 Brian Burg <bburg@apple.com>
Remove a wrong cast in RemoteInspector::receivedSetupMessage
https://bugs.webkit.org/show_bug.cgi?id=154361
<rdar://problem/24709281>
Reviewed by Joseph Pecoraro.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::receivedSetupMessage):
Not only is this cast unnecessary (the constructor accepts the base class),
but it is wrong since the target could be an automation target. Remove it.
2016-02-17 Filip Pizlo <fpizlo@apple.com>
Rename FTLB3Blah to FTLBlah
https://bugs.webkit.org/show_bug.cgi?id=154365
Rubber stamped by Geoffrey Garen, Benjamin Poulain, Awesome Kling, and Saam Barati.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLB3Compile.cpp: Removed.
* ftl/FTLB3Output.cpp: Removed.
* ftl/FTLB3Output.h: Removed.
* ftl/FTLCompile.cpp: Copied from Source/JavaScriptCore/ftl/FTLB3Compile.cpp.
* ftl/FTLOutput.cpp: Copied from Source/JavaScriptCore/ftl/FTLB3Output.cpp.
* ftl/FTLOutput.h: Copied from Source/JavaScriptCore/ftl/FTLB3Output.h.
2016-02-17 Filip Pizlo <fpizlo@apple.com>
Remove LLVM dependencies from WebKit
https://bugs.webkit.org/show_bug.cgi?id=154323
Reviewed by Antti Koivisto and Benjamin Poulain.
We have switched all ports that use the FTL JIT to using B3 as the backend. This renders all
LLVM-related code dead, including the disassembler, which was only reachable when you were on
a platform that already had an in-tree disassembler.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGCommon.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::compileInThreadImpl):
(JSC::DFG::Plan::compileTimeStats):
* disassembler/ARM64Disassembler.cpp:
(JSC::tryToDisassemble):
* disassembler/ARMv7Disassembler.cpp:
(JSC::tryToDisassemble):
* disassembler/Disassembler.cpp:
(JSC::disassemble):
(JSC::disassembleAsynchronously):
* disassembler/Disassembler.h:
(JSC::tryToDisassemble):
* disassembler/LLVMDisassembler.cpp: Removed.
* disassembler/LLVMDisassembler.h: Removed.
* disassembler/UDis86Disassembler.cpp:
(JSC::tryToDisassembleWithUDis86):
* disassembler/UDis86Disassembler.h:
(JSC::tryToDisassembleWithUDis86):
* disassembler/X86Disassembler.cpp:
(JSC::tryToDisassemble):
* ftl/FTLAbbreviatedTypes.h:
* ftl/FTLAbbreviations.h: Removed.
* ftl/FTLAbstractHeap.cpp:
(JSC::FTL::AbstractHeap::decorateInstruction):
(JSC::FTL::AbstractHeap::dump):
(JSC::FTL::AbstractField::dump):
(JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
(JSC::FTL::IndexedAbstractHeap::~IndexedAbstractHeap):
(JSC::FTL::IndexedAbstractHeap::baseIndex):
(JSC::FTL::IndexedAbstractHeap::dump):
(JSC::FTL::NumberedAbstractHeap::NumberedAbstractHeap):
(JSC::FTL::NumberedAbstractHeap::dump):
(JSC::FTL::AbsoluteAbstractHeap::AbsoluteAbstractHeap):
(JSC::FTL::AbstractHeap::tbaaMetadataSlow): Deleted.
* ftl/FTLAbstractHeap.h:
(JSC::FTL::AbstractHeap::AbstractHeap):
(JSC::FTL::AbstractHeap::heapName):
(JSC::FTL::IndexedAbstractHeap::atAnyIndex):
(JSC::FTL::NumberedAbstractHeap::atAnyNumber):
(JSC::FTL::AbsoluteAbstractHeap::atAnyAddress):
(JSC::FTL::AbstractHeap::tbaaMetadata): Deleted.
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLB3Compile.cpp:
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::Output):
(JSC::FTL::Output::check):
(JSC::FTL::Output::load):
(JSC::FTL::Output::store):
* ftl/FTLB3Output.h:
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
(JSC::FTL::CommonValues::initializeConstants):
* ftl/FTLCommonValues.h:
(JSC::FTL::CommonValues::initialize): Deleted.
* ftl/FTLCompile.cpp: Removed.
* ftl/FTLCompileBinaryOp.cpp: Removed.
* ftl/FTLCompileBinaryOp.h: Removed.
* ftl/FTLDWARFDebugLineInfo.cpp: Removed.
* ftl/FTLDWARFDebugLineInfo.h: Removed.
* ftl/FTLDWARFRegister.cpp: Removed.
* ftl/FTLDWARFRegister.h: Removed.
* ftl/FTLDataSection.cpp: Removed.
* ftl/FTLDataSection.h: Removed.
* ftl/FTLExceptionHandlerManager.cpp: Removed.
* ftl/FTLExceptionHandlerManager.h: Removed.
* ftl/FTLExceptionTarget.cpp:
* ftl/FTLExceptionTarget.h:
* ftl/FTLExitThunkGenerator.cpp: Removed.
* ftl/FTLExitThunkGenerator.h: Removed.
* ftl/FTLFail.cpp:
(JSC::FTL::fail):
* ftl/FTLInlineCacheDescriptor.h: Removed.
* ftl/FTLInlineCacheSize.cpp: Removed.
* ftl/FTLInlineCacheSize.h: Removed.
* ftl/FTLIntrinsicRepository.cpp: Removed.
* ftl/FTLIntrinsicRepository.h: Removed.
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::~JITCode):
(JSC::FTL::JITCode::initializeB3Code):
(JSC::FTL::JITCode::initializeB3Byproducts):
(JSC::FTL::JITCode::initializeAddressForCall):
(JSC::FTL::JITCode::contains):
(JSC::FTL::JITCode::ftl):
(JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
(JSC::FTL::JITCode::initializeExitThunks): Deleted.
(JSC::FTL::JITCode::addHandle): Deleted.
(JSC::FTL::JITCode::addDataSection): Deleted.
(JSC::FTL::JITCode::exitThunks): Deleted.
* ftl/FTLJITCode.h:
(JSC::FTL::JITCode::b3Code):
(JSC::FTL::JITCode::handles): Deleted.
(JSC::FTL::JITCode::dataSections): Deleted.
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::codeSize):
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLJITFinalizer.h:
* ftl/FTLJSCall.cpp: Removed.
* ftl/FTLJSCall.h: Removed.
* ftl/FTLJSCallBase.cpp: Removed.
* ftl/FTLJSCallBase.h: Removed.
* ftl/FTLJSCallVarargs.cpp: Removed.
* ftl/FTLJSCallVarargs.h: Removed.
* ftl/FTLJSTailCall.cpp: Removed.
* ftl/FTLJSTailCall.h: Removed.
* ftl/FTLLazySlowPath.cpp:
(JSC::FTL::LazySlowPath::LazySlowPath):
(JSC::FTL::LazySlowPath::generate):
* ftl/FTLLazySlowPath.h:
(JSC::FTL::LazySlowPath::createGenerator):
(JSC::FTL::LazySlowPath::patchableJump):
(JSC::FTL::LazySlowPath::done):
(JSC::FTL::LazySlowPath::usedRegisters):
(JSC::FTL::LazySlowPath::callSiteIndex):
(JSC::FTL::LazySlowPath::stub):
(JSC::FTL::LazySlowPath::patchpoint): Deleted.
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLocation.cpp:
(JSC::FTL::Location::forValueRep):
(JSC::FTL::Location::dump):
(JSC::FTL::Location::forStackmaps): Deleted.
* ftl/FTLLocation.h:
(JSC::FTL::Location::forRegister):
(JSC::FTL::Location::forIndirect):
(JSC::FTL::Location::forConstant):
(JSC::FTL::Location::kind):
(JSC::FTL::Location::hasReg):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::createPhiVariables):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePhi):
(JSC::FTL::DFG::LowerDFGToLLVM::compileDoubleConstant):
(JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithNegate):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitAnd):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitOr):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitXor):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitRShift):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitLShift):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitURShift):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterfly):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileLoadVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIsUndefined):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyWithBarrier):
(JSC::FTL::DFG::LowerDFGToLLVM::stringsEqual):
(JSC::FTL::DFG::LowerDFGToLLVM::emitRightShiftSnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToLLVM::speculate):
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::preparePatchpointForExceptions):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
(JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::exitValueForAvailability):
(JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode):
(JSC::FTL::DFG::LowerDFGToLLVM::probe):
(JSC::FTL::DFG::LowerDFGToLLVM::crash):
(JSC::FTL::DFG::LowerDFGToLLVM::compileUntypedBinaryOp): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::callStackmap): Deleted.
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
(JSC::FTL::OSRExitDescriptor::validateReferences):
(JSC::FTL::OSRExitDescriptor::emitOSRExit):
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
(JSC::FTL::OSRExit::OSRExit):
(JSC::FTL::OSRExit::codeLocationForRepatch):
(JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException): Deleted.
(JSC::FTL::OSRExit::spillRegistersToSpillSlot): Deleted.
(JSC::FTL::OSRExit::recoverRegistersFromSpillSlot): Deleted.
(JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck): Deleted.
(JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation): Deleted.
(JSC::FTL::OSRExit::needsRegisterRecoveryOnGenericUnwindOSRExitPath): Deleted.
* ftl/FTLOSRExit.h:
(JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
(JSC::FTL::OSRExitDescriptorImpl::OSRExitDescriptorImpl): Deleted.
* ftl/FTLOSRExitCompilationInfo.h: Removed.
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileRecovery):
(JSC::FTL::compileStub):
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLOSRExitHandle.cpp:
* ftl/FTLOSRExitHandle.h:
* ftl/FTLOutput.cpp: Removed.
* ftl/FTLOutput.h: Removed.
* ftl/FTLPatchpointExceptionHandle.cpp:
* ftl/FTLPatchpointExceptionHandle.h:
* ftl/FTLStackMaps.cpp: Removed.
* ftl/FTLStackMaps.h: Removed.
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
(JSC::FTL::State::~State):
(JSC::FTL::State::dumpState): Deleted.
* ftl/FTLState.h:
* ftl/FTLUnwindInfo.cpp: Removed.
* ftl/FTLUnwindInfo.h: Removed.
* ftl/FTLValueRange.cpp:
(JSC::FTL::ValueRange::decorateInstruction):
* ftl/FTLValueRange.h:
(JSC::FTL::ValueRange::ValueRange):
(JSC::FTL::ValueRange::begin):
(JSC::FTL::ValueRange::end):
* ftl/FTLWeight.h:
(JSC::FTL::Weight::value):
(JSC::FTL::Weight::frequencyClass):
(JSC::FTL::Weight::scaleToTotal):
* llvm/InitializeLLVM.cpp: Removed.
* llvm/InitializeLLVM.h: Removed.
* llvm/InitializeLLVMMac.cpp: Removed.
* llvm/InitializeLLVMPOSIX.cpp: Removed.
* llvm/InitializeLLVMPOSIX.h: Removed.
* llvm/LLVMAPI.cpp: Removed.
* llvm/LLVMAPI.h: Removed.
* llvm/LLVMAPIFunctions.h: Removed.
* llvm/LLVMHeaders.h: Removed.
* llvm/library/LLVMAnchor.cpp: Removed.
* llvm/library/LLVMExports.cpp: Removed.
* llvm/library/LLVMOverrides.cpp: Removed.
* llvm/library/config_llvm.h: Removed.
2016-02-17 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove the overflow check on ArithAbs when possible
https://bugs.webkit.org/show_bug.cgi?id=154325
Reviewed by Filip Pizlo.
This patch adds support for ArithMode for ArithAbs.
It is useful for kraken tests where Math.abs() is used
on values for which the range is known.
For example, imaging-gaussian-blur has two Math.abs() with
integers that are always in a small range around zero.
The IntegerRangeOptimizationPhase detects the range correctly
so we can just update the ArithMode depending on the input.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToArithNegate):
(JSC::DFG::Node::hasArithMode):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAbs):
* tests/stress/arith-abs-integer-range-optimization.js: Added.
(negativeRange):
(negativeRangeIncludingZero):
(negativeRangeWithOverflow):
(positiveRange):
(positiveRangeIncludingZero):
(rangeWithoutOverflow):
* tests/stress/arith-abs-with-bitwise-or-zero.js: Added.
(opaqueAbs):
2016-02-17 Chris Dumez <cdumez@apple.com>
SES selftest page crashes on nightly r196694
https://bugs.webkit.org/show_bug.cgi?id=154350
<rdar://problem/24704334>
Reviewed by Mark Lam.
SES selftest page crashes after r196001 / r196145 when calling
Object.getOwnPropertyDescriptor(window, "length") after the window
has been reified and "length" has been shadowed by a value property.
It was crashing in JSObject::getOwnPropertyDescriptor() because
we are getting a slot that has attribute "CustomAccessor" but
the property is not a CustomGetterSetter. In this case, since
window.length is [Replaceable] and has been set to a numeric value,
it makes that the property is not a CustomGetterSetter. However,
the "CustomAccessor" attribute should have been dropped from the
slot when window.length was shadowed. Therefore, this code path
should not be exercised at all when calling
getOwnPropertyDescriptor().
The issue was that putDirectInternal() was updating the slot
attributes only if the "Accessor" flag has changed, but not
the "customAccessor" flag. This patch fixes the issue.
* runtime/JSObject.h:
(JSC::JSObject::putDirectInternal):
2016-02-17 Saam barati <sbarati@apple.com>
Implement Proxy [[Get]]
https://bugs.webkit.org/show_bug.cgi?id=154081
Reviewed by Michael Saboff.
This patch implements ProxyObject and ProxyConstructor. Their
implementations are straight forward and follow the spec.
The largest change in this patch is adding a second parameter
to PropertySlot's constructor that specifies the internal method type of
the getOwnPropertySlot inquiry. We use getOwnPropertySlot to
implement more than one Internal Method in the spec. Because
of this, we need InternalMethodType to give us context about
which Internal Method we're executing. Specifically, Proxy will
call into different handlers based on this information.
InternalMethodType is an enum with the following values:
- Get
This corresponds to [[Get]] internal method in the spec.
- GetOwnProperty
This corresponds to [[GetOwnProperty]] internal method in the spec.
- HasProperty
This corresponds to [[HasProperty]] internal method in the spec.
- VMInquiry
This is basically everything else that isn't one of the above
types. This value also mandates that getOwnPropertySlot does
not perform any user observable effects. I.e, it can't call
a JS function.
The other non-VMInquiry InternalMethodTypes are allowed to perform user
observable effects. I.e, in future patches, ProxyObject will implement
InternalMethodType::HasProperty and InternalMethodType::GetOwnProperty, which will both be defined
to call user defined JS functions, which clearly have the right to perform
user observable effects.
This patch implements getOwnPropertySlot of ProxyObject under
InternalMethodType::Get.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::put):
(JSC::JSCallbackObject<Parent>::staticFunctionGetter):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::caughtValue):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/ArrayPrototype.cpp:
(JSC::getProperty):
* runtime/CommonIdentifiers.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::get):
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnNonIndexPropertyNames):
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::defineOwnProperty):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::regExpMatchesArrayStructure):
(JSC::JSGlobalObject::moduleRecordStructure):
(JSC::JSGlobalObject::moduleNamespaceObjectStructure):
(JSC::JSGlobalObject::proxyObjectStructure):
(JSC::JSGlobalObject::wasmModuleStructure):
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::getOwnPropertySlot):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::callbackGetter):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::Walker::walk):
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
(JSC::JSObject::putDirectNonIndexAccessor):
(JSC::JSObject::hasProperty):
(JSC::JSObject::deleteProperty):
(JSC::JSObject::hasOwnProperty):
(JSC::JSObject::getOwnPropertyDescriptor):
* runtime/JSObject.h:
(JSC::JSObject::getDirectIndex):
(JSC::JSObject::get):
* runtime/JSScope.cpp:
(JSC::abstractAccess):
* runtime/ObjectConstructor.cpp:
(JSC::toPropertyDescriptor):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncLookupGetter):
(JSC::objectProtoFuncLookupSetter):
(JSC::objectProtoFuncToString):
* runtime/PropertySlot.h:
(JSC::attributesForStructure):
(JSC::PropertySlot::PropertySlot):
(JSC::PropertySlot::isCacheableGetter):
(JSC::PropertySlot::isCacheableCustom):
(JSC::PropertySlot::internalMethodType):
(JSC::PropertySlot::disableCaching):
(JSC::PropertySlot::getValue):
* runtime/ProxyConstructor.cpp: Added.
(JSC::ProxyConstructor::create):
(JSC::ProxyConstructor::ProxyConstructor):
(JSC::ProxyConstructor::finishCreation):
(JSC::constructProxyObject):
(JSC::ProxyConstructor::getConstructData):
(JSC::ProxyConstructor::getCallData):
* runtime/ProxyConstructor.h: Added.
(JSC::ProxyConstructor::createStructure):
* runtime/ProxyObject.cpp: Added.
(JSC::ProxyObject::ProxyObject):
(JSC::ProxyObject::finishCreation):
(JSC::performProxyGet):
(JSC::ProxyObject::getOwnPropertySlotCommon):
(JSC::ProxyObject::getOwnPropertySlot):
(JSC::ProxyObject::getOwnPropertySlotByIndex):
(JSC::ProxyObject::visitChildren):
* runtime/ProxyObject.h: Added.
(JSC::ProxyObject::create):
(JSC::ProxyObject::createStructure):
(JSC::ProxyObject::target):
(JSC::ProxyObject::handler):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectGet):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::nameFromCallee):
* tests/es6.yaml:
* tests/stress/proxy-basic.js: Added.
(assert):
(let.handler.get null):
(get let):
(let.handler.get switch):
(let.handler):
(let.theTarget.get x):
* tests/stress/proxy-in-proto-chain.js: Added.
(assert):
* tests/stress/proxy-of-a-proxy.js: Added.
(assert):
(throw.new.Error.):
* tests/stress/proxy-property-descriptor.js: Added.
(assert):
(set Object):
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::getImportedValue):
2016-02-17 Mark Lam <mark.lam@apple.com>
StringPrototype functions should check for exceptions after calling JSString::value().
https://bugs.webkit.org/show_bug.cgi?id=154340
Reviewed by Filip Pizlo.
JSString::value() can throw an exception if the JS string is a rope and value()
needs to resolve the rope but encounters an OutOfMemory error. If value() is not
able to resolve the rope, it will return a null string (in addition to throwing
the exception). If StringPrototype functions do not check for exceptions after
calling JSString::value(), they may eventually use the returned null string and
crash the VM.
The fix is to add all the necessary exception checks, and do the appropriate
handling if needed.
Also in a few place where when an exception is detected, we return JSValue(), I
changed it to return jsUndefined() instead to be consistent with the rest of the
file.
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
(JSC::stringProtoFuncMatch):
(JSC::stringProtoFuncSlice):
(JSC::stringProtoFuncSplit):
(JSC::stringProtoFuncLocaleCompare):
(JSC::stringProtoFuncBig):
(JSC::stringProtoFuncSmall):
(JSC::stringProtoFuncBlink):
(JSC::stringProtoFuncBold):
(JSC::stringProtoFuncFixed):
(JSC::stringProtoFuncItalics):
(JSC::stringProtoFuncStrike):
(JSC::stringProtoFuncSub):
(JSC::stringProtoFuncSup):
(JSC::stringProtoFuncFontcolor):
(JSC::stringProtoFuncFontsize):
(JSC::stringProtoFuncAnchor):
(JSC::stringProtoFuncLink):
(JSC::trimString):
2016-02-17 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r196675.
https://bugs.webkit.org/show_bug.cgi?id=154344
"Causes major slowdowns on deltablue-varargs" (Requested by
keith_miller on #webkit).
Reverted changeset:
"Spread operator should be allowed when not the first argument
of parameter list"
https://bugs.webkit.org/show_bug.cgi?id=152721
http://trac.webkit.org/changeset/196675
2016-02-17 Gavin Barraclough <barraclough@apple.com>
JSDOMWindow::put should not do the same thing twice
https://bugs.webkit.org/show_bug.cgi?id=154334
Reviewed by Chris Dumez.
It either calls JSGlobalObject::put or Base::put. Hint: these are basically the same thing.
In the latter case it might call lookupPut. That's redundant; JSObject::put handles static
table entries.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::hasOwnPropertyForWrite): Deleted.
- no longer needed.
2016-02-16 Filip Pizlo <fpizlo@apple.com>
FTL_USES_B3 should be unconditionally true
https://bugs.webkit.org/show_bug.cgi?id=154324
Reviewed by Benjamin Poulain.
* dfg/DFGCommon.h:
2016-02-16 Filip Pizlo <fpizlo@apple.com>
FTL should support CompareEq(String:, String:)
https://bugs.webkit.org/show_bug.cgi?id=154269
rdar://problem/24499921
Reviewed by Benjamin Poulain.
Looks like a slight pdfjs slow-down, probably because we're having some recompilations. I
think we should land the increased coverage first and fix the issues after, especially since
the regression is so small and doesn't have a statistically significant effect on the overall
score.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare):
(JSC::FTL::DFG::LowerDFGToLLVM::stringsEqual):
* tests/stress/ftl-string-equality.js: Added.
* tests/stress/ftl-string-ident-equality.js: Added.
* tests/stress/ftl-string-strict-equality.js: Added.
2016-02-16 Filip Pizlo <fpizlo@apple.com>
FTL should support NewTypedArray
https://bugs.webkit.org/show_bug.cgi?id=154268
Reviewed by Saam Barati.
3% speed-up on pdfjs. This was already covered by many different tests.
Rolling this back in after fixing the butterfly argument.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToLLVM::compileAllocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorageAndGetEnd):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorage):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateObject):
2016-02-16 Gavin Barraclough <barraclough@apple.com>
JSDOMWindow::getOwnPropertySlot should just call getStaticPropertySlot
https://bugs.webkit.org/show_bug.cgi?id=154257
Reviewed by Chris Dumez.
* runtime/Lookup.h:
(JSC::getStaticPropertySlot):
(JSC::getStaticFunctionSlot):
(JSC::getStaticValueSlot):
- this could all do with a little more love.
But enforce the basic precedence:
(1) regular storage properties always win over static table properties.
(2) if properties have been reified, don't consult the static tables.
(3) only if the property is not present on the object & not reified
should the static hashtable be consulted.
2016-02-16 Gavin Barraclough <barraclough@apple.com>
JSDOMWindow::getOwnPropertySlot should not search photo chain
https://bugs.webkit.org/show_bug.cgi?id=154102
Reviewed by Chris Dumez.
Should only return *own* properties.
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyDescriptor):
- remove hack/special-case for DOMWindow; we no longer need this.
2016-02-16 Keith Miller <keith_miller@apple.com>
Spread operator should be allowed when not the first argument of parameter list
https://bugs.webkit.org/show_bug.cgi?id=152721
Reviewed by Saam Barati.
Spread arguments to functions should now be ES6 compliant. Before we
would only take a spread operator if it was the sole argument to a
function. Additionally, we would not use the Symbol.iterator on the
object to generate the arguments. Instead we would do a loop up to the
length mapping indexed properties to the corresponding argument. We fix
both these issues by doing an AST transformation from foo(...a, b, ...c, d)
to foo(...[...a, b, ...c, d]) (where the spread on the rhs uses the
old spread semantics). This solution has the downside of requiring the
allocation of another object and copying each element twice but avoids a
large change to the vm calling convention.
* interpreter/Interpreter.cpp:
(JSC::loadVarargs):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createElementList):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseArguments):
(JSC::Parser<LexerType>::parseArgument):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createElementList):
* tests/es6.yaml:
* tests/stress/spread-calling.js: Added.
(testFunction):
(testEmpty):
(makeObject):
(otherIterator.return.next):
(otherIterator):
(totalIter):
(throwingIter.return.next):
(throwingIter):
(i.catch):
2016-02-16 Benjamin Poulain <bpoulain@apple.com>
[JSC] Enable B3 on ARM64
https://bugs.webkit.org/show_bug.cgi?id=154275
Reviewed by Mark Lam.
The port passes more tests than LLVM now, let's use it by default.
* dfg/DFGCommon.h:
2016-02-16 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r196652.
https://bugs.webkit.org/show_bug.cgi?id=154315
This change caused LayoutTest crashes (Requested by ryanhaddad
on #webkit).
Reverted changeset:
"FTL should support NewTypedArray"
https://bugs.webkit.org/show_bug.cgi?id=154268
http://trac.webkit.org/changeset/196652
2016-02-16 Brian Burg <bburg@apple.com>
RemoteInspector should forward new automation session requests to its client
https://bugs.webkit.org/show_bug.cgi?id=154260
<rdar://problem/24663313>
Reviewed by Timothy Hatcher.
* inspector/remote/RemoteInspector.h:
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::xpcConnectionReceivedMessage):
(Inspector::RemoteInspector::listingForAutomationTarget):
Use the correct key for the session identifier in the listing. The name()
override for RemoteAutomationTarget is actually the session identifier.
(Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
* inspector/remote/RemoteInspectorConstants.h: Add new constants.
2016-02-16 Saam barati <sbarati@apple.com>
SamplingProfiler still fails with ASan enabled
https://bugs.webkit.org/show_bug.cgi?id=154301
<rdar://problem/24679502>
Reviewed by Filip Pizlo.
To fix this issue, I've come up with unsafe versions
of all operations that load memory from the thread's call
frame. All these new unsafe methods are marked with SUPPRESS_ASAN.
* interpreter/CallFrame.cpp:
(JSC::CallFrame::callSiteAsRawBits):
(JSC::CallFrame::unsafeCallSiteAsRawBits):
(JSC::CallFrame::callSiteIndex):
(JSC::CallFrame::unsafeCallSiteIndex):
(JSC::CallFrame::stack):
(JSC::CallFrame::callerFrame):
(JSC::CallFrame::unsafeCallerFrame):
(JSC::CallFrame::friendlyFunctionName):
* interpreter/CallFrame.h:
(JSC::ExecState::calleeAsValue):
(JSC::ExecState::callee):
(JSC::ExecState::unsafeCallee):
(JSC::ExecState::codeBlock):
(JSC::ExecState::unsafeCodeBlock):
(JSC::ExecState::scope):
(JSC::ExecState::callerFrame):
(JSC::ExecState::callerFrameOrVMEntryFrame):
(JSC::ExecState::unsafeCallerFrameOrVMEntryFrame):
(JSC::ExecState::callerFrameOffset):
(JSC::ExecState::callerFrameAndPC):
(JSC::ExecState::unsafeCallerFrameAndPC):
* interpreter/Register.h:
(JSC::Register::codeBlock):
(JSC::Register::asanUnsafeCodeBlock):
(JSC::Register::unboxedInt32):
(JSC::Register::tag):
(JSC::Register::unsafeTag):
(JSC::Register::payload):
* interpreter/VMEntryRecord.h:
(JSC::VMEntryRecord::prevTopCallFrame):
(JSC::VMEntryRecord::unsafePrevTopCallFrame):
(JSC::VMEntryRecord::prevTopVMEntryFrame):
(JSC::VMEntryRecord::unsafePrevTopVMEntryFrame):
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::walk):
(JSC::FrameWalker::advanceToParentFrame):
(JSC::FrameWalker::isAtTop):
(JSC::FrameWalker::resetAtMachineFrame):
2016-02-16 Filip Pizlo <fpizlo@apple.com>
FTL should support NewTypedArray
https://bugs.webkit.org/show_bug.cgi?id=154268
Reviewed by Saam Barati.
3% speed-up on pdfjs. This was already covered by many different tests.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToLLVM::compileAllocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorageAndGetEnd):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorage):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateObject):
2016-02-16 Saam barati <sbarati@apple.com>
stress/sampling-profiler-deep-stack.js fails on ARM 32bit
https://bugs.webkit.org/show_bug.cgi?id=154255
<rdar://problem/24662996>
Reviewed by Mark Lam.
The bug here wasn't in the implementation of the sampling profiler
itself. Rather, it was a bug in the test. JSC wasn't spending a lot
of time in a function that the test assumed a lot of time was spent in.
That's because the DFG was doing a good job at optimizing the function
at the leaf of the recursion. Because of that, we often wouldn't sample it.
I fixed this by making the leaf function do more work.
* tests/stress/sampling-profiler-deep-stack.js:
(platformSupportsSamplingProfiler.foo):
2016-02-16 Chris Dumez <cdumez@apple.com>
[Web IDL] Operations should be on the instance for global objects or if [Unforgeable]
https://bugs.webkit.org/show_bug.cgi?id=154120
<rdar://problem/24613231>
Reviewed by Gavin Barraclough.
Have putEntry() take a thisValue parameter in addition to the base,
instead of relying on PropertySlot::thisValue() because this did not
always do the right thing. In particular, when JSDOMWindow::put() was
called to set a function, it would end up setting the new value on the
JSDOMWindowShell instead of the actual JSDOMWindow.
JSDOMWindow::getOwnPropertySlot() would then not be able to find it.
Therefore the following would fail:
$ window.open = "test"
$ console.log(window.open) // prints the native function instead of "test"
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):
* runtime/Lookup.h:
(JSC::putEntry):
(JSC::lookupPut):
2016-02-16 Keith Miller <keith_miller@apple.com>
ClonedArguments should not materialize its special properties unless they are being changed or deleted
https://bugs.webkit.org/show_bug.cgi?id=154128
Reviewed by Filip Pizlo.
Before we would materialize ClonedArguments whenever they were being accessed.
However this would cause the IC to miss every time as the structure for
the arguments object would change as we went to IC it. Thus on the next
function call we would miss the cache since the new arguments object
would not have materialized the value.
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::getOwnPropertySlot):
* tests/stress/cloned-arguments-modification.js: Added.
(foo):
2016-02-16 Filip Pizlo <fpizlo@apple.com>
FTL should support StringFromCharCode
https://bugs.webkit.org/show_bug.cgi?id=154267
rdar://problem/24192536
Reviewed by Mark Lam.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Fix a bug preventing the UntypedUse from being effective.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileStringFromCharCode): Implement the opcode.
* tests/stress/string-from-char-code-slow.js: Added.
2016-02-15 Benjamin Poulain <bpoulain@apple.com>
[JSC] BranchAdd can override arguments of its stackmap
https://bugs.webkit.org/show_bug.cgi?id=154274
Reviewed by Filip Pizlo.
With the 3 operands BranchAdd added in r196513, we can run into
a register allocation such that the destination register is also
used by a value in the stack map.
It use to be that BranchAdd was a 2 operand instruction.
In that form, the destination is also one of the source and
can be recovered through Sub. There is no conflict between
destination and the stackmap.
After r196513, the destination has its own value. It is uncommon
on x86 because of the aggressive aliasing but that can happen.
On ARM, that's a standard form since there is no need for aliasing.
Since the arguments of the stackmap are of type EarlyUse,
they appeared as not interfering with the destination. When the register
allocator gives the same register to the destination and something in
the stack map, the result of BranchAdd destroys the value kept alive
for the stackmap.
In this patch, I introduce a concept very similar to ForceLateUse
to keep the argument of the stackmap live in CheckAdd. The new
role is "ForceLateUseUnlessRecoverable".
In this mode, anything that is not also an input argument becomes
LateUse. As such, it interferes with the destination of CheckAdd.
The arguments are recovered by the slow patch of CheckAdd. They
remain Early use.
This new modes ensure that destination can be aliased to the source
when that's useful, while making sure it is not aliased with another
value that needs to be live on exit.
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::forEachArg):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::forEachArg):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
(WTF::printInternal):
* b3/B3StackmapSpecial.h:
* b3/B3StackmapValue.h:
2016-02-15 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Web Workers have no access to console for debugging
https://bugs.webkit.org/show_bug.cgi?id=26237
Reviewed by Timothy Hatcher.
* inspector/ConsoleMessage.h:
Add accessor for MessageLevel.
2016-02-15 Mark Lam <mark.lam@apple.com>
[ARMv7] stress/op_rshift.js and stress/op_urshift.js are failing.
https://bugs.webkit.org/show_bug.cgi?id=151514
Reviewed by Filip Pizlo.
The issue turns out to be trivial: on ARMv7 (and traditional ARM too), arithmetic
shift right (ASR) and logical shift right (LSR) takes an immediate shift amount
from 1-32. See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cjacbgca.html.
An immediate shift amount of 0 is interpreted as a shift of 32 bits.
Meanwhile, our macro assembler is expecting the immediate shift value to be
between 0-31. As a result, a shift amount of 0 is being wrongly encoded with 0
bits which means shift right by 32 bits.
The fix is to check if the shift amount is 0, and if so, emit a move. Else,
emit the right shift as usual.
This issue does not affect left shifts, as the immediate shift amount for left
shifts is between 0-31 as our macro assembler expects.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::rshift32):
(JSC::MacroAssemblerARM::urshift32):
(JSC::MacroAssemblerARM::sub32):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::rshift32):
(JSC::MacroAssemblerARMv7::urshift32):
* tests/stress/op_rshift.js:
* tests/stress/op_urshift.js:
- Un-skip these tests. They should always pass now.
2016-02-15 Filip Pizlo <fpizlo@apple.com>
Parser::parseVariableDeclarationList should null check the node before attempting to create a new CommaExpr
https://bugs.webkit.org/show_bug.cgi?id=154244
rdar://problem/24290670
Reviewed by Michael Saboff.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::appendToCommaExpr): Catch the bug sooner in debug.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVariableDeclarationList): Fix the bug.
* tests/stress/for-let-comma.js: Added. This used to crash in debug and release.
2016-02-15 Benjamin Poulain <bpoulain@apple.com>
[JSC] Improve the interface of Inst::shouldTryAliasingDef()
https://bugs.webkit.org/show_bug.cgi?id=154227
Reviewed by Andreas Kling.
Using Optional<> instead of a bool+reference looks cleaner
at the call sites.
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::shouldTryAliasingDef):
* b3/B3CheckSpecial.h:
* b3/air/AirCustom.h:
(JSC::B3::Air::PatchCustom::shouldTryAliasingDef):
* b3/air/AirInst.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::shouldTryAliasingDef):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirSpecial.cpp:
(JSC::B3::Air::Special::shouldTryAliasingDef):
* b3/air/AirSpecial.h:
2016-02-14 Brian Burg <bburg@apple.com>
WKAutomationDelegate's requestAutomationSession should take a suggested session identifier
https://bugs.webkit.org/show_bug.cgi?id=154012
<rdar://problem/24557697>
Reviewed by Darin Adler.
Add a string parameter to the client method for requesting a new session.
* inspector/remote/RemoteInspector.h:
2016-02-13 Timothy Hatcher <timothy@apple.com>
Fix WebAssembly bug URL in the feature list.
* features.json:
2016-02-12 Sukolsak Sakshuwong <sukolsak@gmail.com>
Change the last RefPtr::get() to release() in String.prototype.normalize
https://bugs.webkit.org/show_bug.cgi?id=154211
Reviewed by Ryosuke Niwa.
Change the last RefPtr::get() to release() in String.prototype.normalize.
* runtime/StringPrototype.cpp:
(JSC::normalize):
2016-02-12 Saam barati <sbarati@apple.com>
[ES6] we have an incorrect syntax error when a callee of a function expression has the same name as a top-level lexical declaration
https://bugs.webkit.org/show_bug.cgi?id=154143
Reviewed by Benjamin Poulain.
We were raising syntax errors on the following type of programs when
we shouldn't have been.
```
(function foo() { const foo = 20; });
```
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/Parser.h:
(JSC::Scope::computeLexicallyCapturedVariablesAndPurgeCandidates):
(JSC::Scope::declareCallee):
(JSC::Scope::declareVariable):
(JSC::Scope::hasDeclaredVariable):
(JSC::Scope::hasLexicallyDeclaredVariable):
(JSC::Scope::hasDeclaredParameter):
(JSC::Scope::declareWrite):
(JSC::Scope::getCapturedVars):
2016-02-12 Benjamin Poulain <bpoulain@apple.com>
[JSC] ZeroExtend and SignExtend use incorrect addressing on ARM64
https://bugs.webkit.org/show_bug.cgi?id=154208
Reviewed by Filip Pizlo.
When lowering:
@1 = Load32(@x)
@2 = SExt8(@1)
LowerToAir would see there is a form of SignExtend8To32 (an alias for Load8S)
and use that.
There are two problems with that:
1) If we have an Addr, it went through legalizeMemoryOffsets() for a 32bits
load. If used on an other kind of load, there is no guarantee the addressing
is still valid.
2) If we have an Index, it is computed for the 32bits MemoryValue.
The computed index is not valid for the 8bits load.
(2) could be fixed by changing LowerToAir to use the current instruction width
instead of the B3ValueWidth but that's a bit tricky. We should just embrace
that one of our target is a Load-Store architecture.
In this patch, I just disabled the faulty forms on ARM64. We still need those operations
to be fast, this will be addressed in: https://bugs.webkit.org/show_bug.cgi?id=154207
I also strengthened the m_allowScratchRegister assertion. The instructions that do not
invalidate the temporary did not run the assertion, making this harder to debug.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load8):
(JSC::MacroAssemblerARM64::store64):
(JSC::MacroAssemblerARM64::store32):
(JSC::MacroAssemblerARM64::loadDouble):
(JSC::MacroAssemblerARM64::storeDouble):
(JSC::MacroAssemblerARM64::branch32):
(JSC::MacroAssemblerARM64::branch64):
(JSC::MacroAssemblerARM64::getCachedDataTempRegisterIDAndInvalidate):
(JSC::MacroAssemblerARM64::getCachedMemoryTempRegisterIDAndInvalidate):
(JSC::MacroAssemblerARM64::dataMemoryTempRegister):
(JSC::MacroAssemblerARM64::cachedMemoryTempRegister):
(JSC::MacroAssemblerARM64::load):
(JSC::MacroAssemblerARM64::store):
* b3/air/AirOpcode.opcodes:
2016-02-12 Michael Saboff <msaboff@apple.com>
offlineasm: Emit Dwarf2 file and location directives to allow for debugging .asm files
https://bugs.webkit.org/show_bug.cgi?id=152703
Reviewed by Mark Lam.
Added support to output Dwarf2 .file and .loc assembler directives to provide the debugging
information needed to correlate the offline assembler generated code with the source lines
in the .asm files.
Changed the tracking of file data to include a file index that was provided to the .file
directive. That index is used when emitting the .loc directives.
* offlineasm/arm.rb:
* offlineasm/arm64.rb:
* offlineasm/asm.rb:
* offlineasm/backends.rb:
* offlineasm/config.rb:
* offlineasm/parser.rb:
* offlineasm/x86.rb:
2016-02-12 Saam barati <sbarati@apple.com>
The parser doesn't properly protect against global variable references in builtins
https://bugs.webkit.org/show_bug.cgi?id=154144
Reviewed by Geoffrey Garen.
This patch fixes our global variable reference detection
algorithm that was broken. After fixing the algorithm, I
detected many places where we were incorrectly using global
variables. I've fixed all those.
* builtins/BuiltinExecutables.cpp:
(JSC::createExecutableInternal):
* builtins/NumberPrototype.js:
(toLocaleString):
* builtins/PromiseConstructor.js:
(race):
(reject):
(resolve):
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ModuleProgramNode::ModuleProgramNode):
(JSC::ProgramNode::setClosedVariables): Deleted.
* parser/Nodes.h:
(JSC::ScopeNode::setClosedVariables): Deleted.
(JSC::ProgramNode::closedVariables): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::didFinishParsing):
* parser/Parser.h:
(JSC::Scope::setIsLexicalScope):
(JSC::Scope::isLexicalScope):
(JSC::Scope::closedVariableCandidates):
(JSC::Scope::declaredVariables):
(JSC::Scope::lexicalVariables):
(JSC::Scope::finalizeLexicalEnvironment):
(JSC::Parser::positionBeforeLastNewline):
(JSC::Parser::locationBeforeLastToken):
(JSC::Parser::isFunctionMetadataNode):
(JSC::parse):
(JSC::Parser::closedVariables): Deleted.
2016-02-12 Filip Pizlo <fpizlo@apple.com>
JSObject::putByIndexBeyondVectorLengthWithoutAttributes needs to go to the sparse map based on MAX_STORAGE_VECTOR_INDEX
https://bugs.webkit.org/show_bug.cgi?id=154201
rdar://problem/24291387
Reviewed by Saam Barati.
I decided against adding a test for this, because it runs for a very long time.
* runtime/JSObject.cpp:
(JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): Fix the bug.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncSplit): Fix a related bug: if this code creates an array that would have
hit the above bug, then it would probably manifest as a spin or as swapping.
2016-02-12 Jonathan Davis <jond@apple.com>
Add WebAssembly to the status page
https://bugs.webkit.org/show_bug.cgi?id=154199
Reviewed by Timothy Hatcher.
* features.json:
2016-02-12 Brian Burg <bburg@apple.com>
Web Inspector: disambiguate the various identifier and connection types in RemoteInspector
https://bugs.webkit.org/show_bug.cgi?id=154130
Reviewed by Joseph Pecoraro.
There are multiple identifier types:
- connection identifier, a string UUID for a remote debugger process.
- session identifier, a string UUID for a remote driver/debugger instance.
- page/target identifier, a number unique within a single process.
There are multiple connection types:
- RemoteInspectorXPCConnection, a connection from RemoteInspectorXPCConnectionor to a relay.
- RemoteConnectionToTarget, a class that bridges to targets' dispatch queues.
Use consistent variable and getter names so that these don't get confused and
so that the code is easier to read. This is especially an improvement when working
with multiple target types or connection types within the same function.
* inspector/remote/RemoteConnectionToTarget.h:
* inspector/remote/RemoteConnectionToTarget.mm:
Remove the member for m_identifier since we can ask the target for its target identifier
or use a default value via WTF::Optional. There's no reason to cache the value.
(Inspector::RemoteTargetHandleRunSourceWithInfo):
(Inspector::RemoteConnectionToTarget::targetIdentifier):
(Inspector::RemoteConnectionToTarget::destination):
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
Bail out if the target pointer was somehow cleared and we can't get a useful target identifier.
(Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget): Deleted.
* inspector/remote/RemoteControllableTarget.h:
* inspector/remote/RemoteInspectionTarget.cpp:
(Inspector::RemoteInspectionTarget::pauseWaitingForAutomaticInspection):
(Inspector::RemoteInspectionTarget::unpauseForInitializedInspector):
* inspector/remote/RemoteInspector.h:
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::nextAvailableTargetIdentifier):
(Inspector::RemoteInspector::registerTarget):
(Inspector::RemoteInspector::unregisterTarget):
(Inspector::RemoteInspector::updateTarget):
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
(Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage):
(Inspector::RemoteInspector::sendMessageToRemote):
(Inspector::RemoteInspector::setupFailed):
(Inspector::RemoteInspector::setupCompleted):
(Inspector::RemoteInspector::stopInternal):
(Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
(Inspector::RemoteInspector::xpcConnectionFailed):
(Inspector::RemoteInspector::listingForInspectionTarget):
(Inspector::RemoteInspector::listingForAutomationTarget):
(Inspector::RemoteInspector::pushListingsNow):
(Inspector::RemoteInspector::pushListingsSoon):
(Inspector::RemoteInspector::updateHasActiveDebugSession):
(Inspector::RemoteInspector::receivedSetupMessage):
(Inspector::RemoteInspector::receivedDataMessage):
(Inspector::RemoteInspector::receivedDidCloseMessage):
(Inspector::RemoteInspector::receivedIndicateMessage):
(Inspector::RemoteInspector::receivedProxyApplicationSetupMessage):
(Inspector::RemoteInspector::receivedConnectionDiedMessage):
(Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
(Inspector::RemoteInspector::nextAvailableIdentifier): Deleted.
* inspector/remote/RemoteInspectorConstants.h:
2016-02-12 Benjamin Poulain <benjamin@webkit.org>
[JSC] On x86, improve the selection of which value are selected for the UseDef part of commutative operations
https://bugs.webkit.org/show_bug.cgi?id=154151
Reviewed by Filip Pizlo.
Previously, when an instruction destroy an argument with
a UseDef use, we would try to pick a good target for the UseDef
while doing instruction selection.
For example:
@x = Add(@1, @2)
can be lowered to:
Move @1 Tmp3
Add @2 Tmp3
or
Move @2 Tmp3
Add @1 Tmp3
The choice of which value ends up copied is done by preferRightForResult()
at lowering time.
There are two common problems with the code we generate:
1) It is based on UseCount. If a value is at its last use,
it is a good target for coalescing even with a use-count > 1.
2) When both values are at their last use, the best choice
depends on the register pressure of each. We don't have that information
until we do register allocation.
This patch implements a simple idea to minimize how many of those Moves are needed.
Each commutative operation gets a 3 op variant. The register allocator then attempts
to alias *both* of them to the destination.
Since our aliasing is conservative, it removes as many copy as possible without causing
spilling.
There was an unexpected cool impovement too. If you have:
Move Tmp1, Tmp2
BranchAdd32 Tmp3, Tmp2
we would previously restore Tmp2 by substracting Tmp3 from the result.
We can now just use Tmp1. That removes quite a few Sub from the slow paths.
The problem is that simple idea uncoverred a bunch of issues that had to be fixed too.
I detail them inline below.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::and64):
* assembler/MacroAssemblerX86Common.h:
Most addition are adding an Address version of the 3 operands opcodes.
The reason for this is allow the complex addressing forms of instructions
when spilling.
(JSC::MacroAssemblerX86Common::and32):
(JSC::MacroAssemblerX86Common::mul32):
(JSC::MacroAssemblerX86Common::or32):
(JSC::MacroAssemblerX86Common::xor32):
(JSC::MacroAssemblerX86Common::moveDouble):
This was an unexpected discovery: removing tons of Move32 made floating-point heavy
code much slower.
It turns out the MoveDouble we were using has partial register dependencies.
The x86 optimization manual, Chapter 3, section 3.4.1.13 lists the move instructions executed
directly on the frontend. That's what we use now.
(JSC::MacroAssemblerX86Common::addDouble):
(JSC::MacroAssemblerX86Common::addFloat):
(JSC::MacroAssemblerX86Common::mulDouble):
(JSC::MacroAssemblerX86Common::mulFloat):
(JSC::MacroAssemblerX86Common::andDouble):
(JSC::MacroAssemblerX86Common::andFloat):
(JSC::MacroAssemblerX86Common::xorDouble):
(JSC::MacroAssemblerX86Common::xorFloat):
If the destination is not aliased, the version taking an address
use LoadFloat/LoadDouble instead of direct addressing.
That is because this:
Move Tmp1, Tmp2
Op [Tmp3], Tmp2
is slower than
Move [Tmp3] Tmp2
Op Tmp1, Tmp2
(sometimes significantly).
I am not exactly sure why.
(JSC::MacroAssemblerX86Common::branchAdd32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::and64):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::and64):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::and32):
(JSC::MacroAssemblerX86Common::mul32):
(JSC::MacroAssemblerX86Common::or32):
(JSC::MacroAssemblerX86Common::xor32):
(JSC::MacroAssemblerX86Common::moveDouble):
(JSC::MacroAssemblerX86Common::addDouble):
(JSC::MacroAssemblerX86Common::addFloat):
(JSC::MacroAssemblerX86Common::mulDouble):
(JSC::MacroAssemblerX86Common::mulFloat):
(JSC::MacroAssemblerX86Common::andDouble):
(JSC::MacroAssemblerX86Common::andFloat):
(JSC::MacroAssemblerX86Common::xorDouble):
(JSC::MacroAssemblerX86Common::xorFloat):
(JSC::MacroAssemblerX86Common::branchAdd32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::and64):
(JSC::MacroAssemblerX86_64::mul64):
(JSC::MacroAssemblerX86_64::xor64):
(JSC::MacroAssemblerX86_64::branchAdd64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::movapd_rr):
(JSC::X86Assembler::movaps_rr):
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::shouldTryAliasingDef):
(JSC::B3::CheckSpecial::generate):
* b3/B3CheckSpecial.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirCustom.h:
(JSC::B3::Air::PatchCustom::shouldTryAliasingDef):
* b3/air/AirInst.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::shouldTryAliasingDef):
* b3/air/AirIteratedRegisterCoalescing.cpp:
Aliasing the operands is done the same way as any coalescing.
There were problem with considering all those coalescing
as equivalent for the result.
Moves are mostly generated for Upsilon-Phis. Getting rid of
those tends to give better loops.
Sometimes, blocks have only Phis and a Jump. Coalescing
those moves gets rids of the block entirely.
Where it go interesting was that something like:
Move Tmp1, Tmp2
Op Tmp3, Tmp2
was significantly better than:
Op Tmp1, Tmp3
Move Tmp1, Tmp4
even in the same basic block.
To get back to the same performance when, I had to prioritize
regular Moves operations over argument coalescing.
Another argument for doing this is that the alias has a shorter
life in the hardware because the operation itself gets a new
virtual register from the bank.
* b3/air/AirOpcode.opcodes:
* b3/air/AirSpecial.cpp:
(JSC::B3::Air::Special::shouldTryAliasingDef):
* b3/air/AirSpecial.h:
* b3/testb3.cpp:
(JSC::B3::testCheckAddArgumentAliasing64):
(JSC::B3::testCheckAddArgumentAliasing32):
(JSC::B3::testCheckAddSelfOverflow64):
(JSC::B3::testCheckAddSelfOverflow32):
(JSC::B3::testCheckMulArgumentAliasing64):
(JSC::B3::testCheckMulArgumentAliasing32):
(JSC::B3::run):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor):
This ruined my week.
When regenerating the frame of an inlined function that
was called through a tail call, we were ignoring r13 for some reason.
Since this patch makes it more likely to increase the degree
of each Tmp, the number of register used increased and r13 was more
commonly used.
When getting out of OSRExit, we would have that value trashed :(
The fix is simply to restore it like the other two Baseline callee saved
register.
2016-02-12 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement @@search
https://bugs.webkit.org/show_bug.cgi?id=143889
Reviewed by Darin Adler.
Implement RegExp.prototype[@@search].
In ES6, String.prototype.search delegates the actual matching to it
instead of executing RegExp matching inside String.prototype.search method itself.
By customizing @@search method, we can change the behavior of String.prototype.search for
derived / customized RegExp object.
* CMakeLists.txt:
* DerivedSources.make:
* builtins/BuiltinNames.h:
(JSC::BuiltinNames::BuiltinNames): Deleted.
* builtins/BuiltinUtils.h:
* builtins/StringPrototype.js:
(search):
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
* bytecode/BytecodeIntrinsicRegistry.h:
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
(JSC::regExpProtoFuncSearch):
* runtime/RegExpPrototype.h:
(JSC::RegExpPrototype::create):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::getOwnPropertySlot):
(JSC::StringPrototype::finishCreation): Deleted.
(JSC::stringProtoFuncSearch): Deleted.
* runtime/StringPrototype.h:
* tests/es6.yaml:
* tests/stress/regexp-search.js: Added.
(shouldBe):
(shouldThrow):
(errorKey.toString):
(primitive.of.primitives.shouldThrow):
(testRegExpSearch):
(testSearch):
(testBoth):
(alwaysUnmatch):
2016-02-12 Keith Miller <keith_miller@apple.com>
AdaptiveInferredPropertyValueWatchpoint can trigger a GC that frees its CodeBlock and thus itself
https://bugs.webkit.org/show_bug.cgi?id=154146
Reviewed by Filip Pizlo.
Consider the following: there is some CodeBlock, C, that is watching some object, O, with a
structure, S, for replacements. Also, suppose that C has no references anymore and is due to
be GCed. Now, when some new property is added to O, S will create a new structure S' and
fire its transition watchpoints. Since C is watching S for replacements it will attempt to
have its AdaptiveInferredPropertyValueWatchpoint relocate itself to S'. To do so, it needs
it allocate RareData on S'. This allocation may cause a GC, which frees C while still
executing its watchpoint handler. The solution to this is to defer GC while running
AdaptiveInferredPropertyValueWatchpointBase handlers.
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
(JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
2016-02-12 Gavin Barraclough <barraclough@apple.com>
Separate out !allowsAccess path in JSDOMWindowCustom getOwnPropertySlot
https://bugs.webkit.org/show_bug.cgi?id=154156
Reviewed by Chris Dumez.
* runtime/CommonIdentifiers.h:
- added new property names, needed by jsDOMWindowGetOwnPropertySlotDisallowAccess.
2016-02-12 Sukolsak Sakshuwong <sukolsak@gmail.com>
Update ICU header files to version 52
https://bugs.webkit.org/show_bug.cgi?id=154160
Reviewed by Alex Christensen.
Update ICU header files to version 52 to allow the use of newer APIs.
* icu/unicode/localpointer.h:
* icu/unicode/platform.h:
* icu/unicode/ptypes.h:
* icu/unicode/putil.h:
* icu/unicode/ucal.h:
* icu/unicode/uchar.h:
* icu/unicode/ucnv.h:
* icu/unicode/ucol.h:
* icu/unicode/uconfig.h:
* icu/unicode/udat.h:
* icu/unicode/udatpg.h:
* icu/unicode/udisplaycontext.h: Added.
* icu/unicode/uenum.h:
* icu/unicode/uformattable.h: Added.
* icu/unicode/uiter.h:
* icu/unicode/uloc.h:
* icu/unicode/umachine.h:
* icu/unicode/unorm2.h:
* icu/unicode/unum.h:
* icu/unicode/urename.h:
* icu/unicode/uscript.h:
* icu/unicode/uset.h:
* icu/unicode/ustring.h:
* icu/unicode/utf.h:
* icu/unicode/utf16.h:
* icu/unicode/utf8.h:
* icu/unicode/utf_old.h:
* icu/unicode/utypes.h:
* icu/unicode/uvernum.h:
* icu/unicode/uversion.h:
2016-02-12 Filip Pizlo <fpizlo@apple.com>
Fast path in JSObject::defineOwnIndexedProperty() forgets to check for the posibility of a descriptor that doesn't have a value
https://bugs.webkit.org/show_bug.cgi?id=154175
rdar://problem/24291497
Reviewed by Geoffrey Garen.
* runtime/JSObject.cpp:
(JSC::JSObject::defineOwnIndexedProperty): Fix the bug.
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry): Catch the bug sooner in debug.
(JSC::SparseArrayValueMap::putDirect):
* tests/stress/sparse-define-empty-descriptor.js: Added. This used to crash in release.
2016-02-11 Brian Burg <bburg@apple.com>
Web Inspector: RemoteInspector's listings should include whether an AutomationTarget is paired
https://bugs.webkit.org/show_bug.cgi?id=154077
<rdar://problem/24589133>
Reviewed by Joseph Pecoraro.
Instead of not generating a listing for the target when it is occupied,
generate the listing with a 'paired' flag. The old flag was redundant
because a _WKAutomationDelegate will not create a session if it doesn't
support automation or it already has an active session.
* inspector/remote/RemoteAutomationTarget.cpp:
(Inspector::RemoteAutomationTarget::setIsPaired):
(Inspector::RemoteAutomationTarget::setAutomationAllowed): Deleted.
* inspector/remote/RemoteAutomationTarget.h:
Return false for remoteControlAllowed() if the target is already paired.
This function is used by RemoteInspector to deny incoming connections.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::listingForAutomationTarget):
* inspector/remote/RemoteInspectorConstants.h:
2016-02-11 Filip Pizlo <fpizlo@apple.com>
DFG::ByteCodeParser needs to null check the result of presenceLike()
https://bugs.webkit.org/show_bug.cgi?id=154135
rdar://problem/24291586
Reviewed by Geoffrey Garen.
ByteCodeParser::presenceLike() could return a null object property condition if it detects a
contradiction. That could happen due to bogus profiling. It's totally OK - we just need to
bail from using a property condition when that happens.
* bytecode/ObjectPropertyCondition.h:
(JSC::ObjectPropertyCondition::equivalence):
(JSC::ObjectPropertyCondition::operator bool):
(JSC::ObjectPropertyCondition::object):
(JSC::ObjectPropertyCondition::condition):
(JSC::ObjectPropertyCondition::operator!): Deleted.
* bytecode/PropertyCondition.h:
(JSC::PropertyCondition::equivalence):
(JSC::PropertyCondition::operator bool):
(JSC::PropertyCondition::kind):
(JSC::PropertyCondition::uid):
(JSC::PropertyCondition::operator!): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::check):
(JSC::DFG::ByteCodeParser::load):
2016-02-11 Benjamin Poulain <benjamin@webkit.org>
[JSC] SqrtFloat and CeilFloat also suffer from partial register stalls
https://bugs.webkit.org/show_bug.cgi?id=154131
Reviewed by Filip Pizlo.
Looks like I forgot to update this when adding Float support.
Credit to Filip for finding this issue.
* b3/air/AirFixPartialRegisterStalls.cpp:
2016-02-11 Filip Pizlo <fpizlo@apple.com>
Cannot call initializeIndex() if we didn't create the array using tryCreateUninitialized()
https://bugs.webkit.org/show_bug.cgi?id=154126
Reviewed by Saam Barati.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
2016-02-11 Sukolsak Sakshuwong <sukolsak@gmail.com>
[INTL] Implement Intl.NumberFormat.prototype.resolvedOptions ()
https://bugs.webkit.org/show_bug.cgi?id=147602
Reviewed by Darin Adler.
This patch implements Intl.NumberFormat.prototype.resolvedOptions() according
to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.)
* runtime/IntlDateTimeFormat.cpp:
(JSC::localeData):
* runtime/IntlNumberFormat.cpp:
(JSC::localeData):
(JSC::computeCurrencySortKey):
(JSC::extractCurrencySortKey):
(JSC::computeCurrencyDigits):
(JSC::IntlNumberFormat::initializeNumberFormat):
(JSC::IntlNumberFormat::styleString):
(JSC::IntlNumberFormat::currencyDisplayString):
(JSC::IntlNumberFormat::resolvedOptions):
(JSC::IntlNumberFormat::setBoundFormat):
* runtime/IntlNumberFormat.h:
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::constructIntlNumberFormat):
(JSC::callIntlNumberFormat):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
* runtime/IntlObject.cpp:
(JSC::intlNumberOption):
(JSC::numberingSystemsForLocale):
(JSC::getNumberingSystemsForLocale): Deleted.
* runtime/IntlObject.h:
2016-02-11 Filip Pizlo <fpizlo@apple.com>
MacroAssemblerX86 should be happy with shift(cx, cx)
https://bugs.webkit.org/show_bug.cgi?id=154124
Reviewed by Saam Barati.
Prior to this change the assembler asserted that shift_amount and dest cannot be the same.
That's a good assertion for when shift_amount is not in cx. But if it's in cx already then
it's OK for them to be the same. Air will sometimes do shift(cx, cx) if you do "x << x" and
the coalescing got particularly clever.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::lshift32):
(JSC::MacroAssemblerX86Common::rshift32):
(JSC::MacroAssemblerX86Common::urshift32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::lshift64):
(JSC::MacroAssemblerX86_64::rshift64):
(JSC::MacroAssemblerX86_64::urshift64):
* b3/testb3.cpp:
(JSC::B3::testLShiftSelf32):
(JSC::B3::testRShiftSelf32):
(JSC::B3::testURShiftSelf32):
(JSC::B3::testLShiftSelf64):
(JSC::B3::testRShiftSelf64):
(JSC::B3::testURShiftSelf64):
(JSC::B3::run):
2016-02-11 Saam barati <sbarati@apple.com>
The sampling profiler's stack walker methods should be marked with SUPPRESS_ASAN
https://bugs.webkit.org/show_bug.cgi?id=154123
Reviewed by Mark Lam.
The entire premise of the sampling profiler is to load from
another thread's memory. We should SUPPRESS_ASAN on the
methods that do this.
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::FrameWalker):
(JSC::FrameWalker::walk):
(JSC::FrameWalker::advanceToParentFrame):
(JSC::FrameWalker::isAtTop):
(JSC::FrameWalker::resetAtMachineFrame):
2016-02-11 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed typo fix after r190063.
* dfg/DFGSpeculativeJIT.cpp: Removed property svn:executable.
* dfg/DFGSpeculativeJIT.h: Removed property svn:executable.
* jit/JIT.h: Removed property svn:executable.
* jit/JITInlines.h: Removed property svn:executable.
* jit/JITOpcodes.cpp: Removed property svn:executable.
2016-02-11 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed typo fix after r190063.
* dfg/DFGSpeculativeJIT.cpp: Removed property svn:executable.
* dfg/DFGSpeculativeJIT.h: Removed property svn:executable.
* jit/JIT.h: Removed property svn:executable.
* jit/JITInlines.h: Removed property svn:executable.
* jit/JITOpcodes.cpp: Removed property svn:executable.
2016-02-10 Keith Miller <keith_miller@apple.com>
Symbol.species accessors on builtin constructors should be configurable
https://bugs.webkit.org/show_bug.cgi?id=154097
Reviewed by Benjamin Poulain.
We did not have the Symbol.species accessors on our builtin constructors
marked as configurable. This does not accurately follow the ES6 spec as
the ES6 spec states that all default accessors on builtins should be
configurable. This means that we need an additional watchpoint on
ArrayConstructor to make sure that no users re-configures Symbol.species.
* runtime/ArrayConstructor.cpp:
(JSC::ArrayConstructor::finishCreation):
* runtime/ArrayPrototype.cpp:
(JSC::speciesConstructArray):
(JSC::ArrayPrototype::setConstructor):
(JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
* runtime/ArrayPrototype.h:
(JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties):
(JSC::ArrayPrototype::didChangeConstructorProperty): Deleted.
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSArrayBufferConstructor::finishCreation):
* runtime/JSPromiseConstructor.cpp:
(JSC::JSPromiseConstructor::finishCreation):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSTypedArrayViewConstructor::finishCreation):
* runtime/MapConstructor.cpp:
(JSC::MapConstructor::finishCreation):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::finishCreation):
* runtime/SetConstructor.cpp:
(JSC::SetConstructor::finishCreation):
* tests/stress/array-species-config-array-constructor.js: Added.
(A):
* tests/stress/symbol-species.js:
(testSymbolSpeciesOnConstructor):
2016-02-10 Benjamin Poulain <benjamin@webkit.org>
[JSC] The destination of Sqrt should be Def, not UseDef
https://bugs.webkit.org/show_bug.cgi?id=154086
Reviewed by Geoffrey Garen.
An unfortunate copy-paste: the destination of SqrtDouble and SqrtFloat
was defined as UseDef. As a result, the argument would be interfering
with everything defined prior.
* b3/air/AirOpcode.opcodes:
2016-02-10 Chris Dumez <cdumez@apple.com>
[Web IDL] interface objects should be Function objects
https://bugs.webkit.org/show_bug.cgi?id=154038
<rdar://problem/24569358>
Reviewed by Geoffrey Garen.
Update functionProtoFuncToString() to handle JSObjects that
have the TypeOfShouldCallGetCallData flag and are callable,
as these behave like functions and use ClassInfo::className()
as function name in this case.
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
2016-02-10 Chris Dumez <cdumez@apple.com>
Attributes on the Window instance should be configurable unless [Unforgeable]
https://bugs.webkit.org/show_bug.cgi?id=153920
<rdar://problem/24563211>
Reviewed by Darin Adler.
Marking the Window instance attributes as configurable but cause
getOwnPropertyDescriptor() to report them as configurable, as
expected. However, trying to delete them would actually lead to
unexpected behavior because:
- We did not reify custom accessor properties (most of the Window
properties are custom accessors) upon deletion.
- For non-reified static properties marked as configurable,
JSObject::deleteProperty() would attempt to call the property
setter with undefined. As a result, calling delete window.name
would cause window.name to become the string "undefined" instead
of the undefined value.
* runtime/JSObject.cpp:
(JSC::getClassPropertyNames):
Now that we reify ALL properties, we only need to check the property table
if we have not reified. As a result, I dropped the 'didReify' parameter for
this function and instead only call this function if we have not yet reified.
(JSC::JSObject::putInlineSlow):
Only call putEntry() if we have not reified: Drop the
'|| !(entry->attributes() & BuiltinOrFunctionOrAccessor)'
check as such properties now get reified as well.
(JSC::JSObject::deleteProperty):
- Call reifyAllStaticProperties() instead of reifyStaticFunctionsForDelete()
so that we now reify all properties upon deletion, including the custom
accessors. reifyStaticFunctionsForDelete() is now removed and the same
reification function is now used by: deletion, getOwnPropertyDescriptor()
and eager reification of the prototype objects in the bindings.
- Drop code that falls back to calling the static property setter with
undefined if we cannot find the property in the property storage. As
we now reify ALL properties, the code removing the property from the
property storage should succeed, provided that the property actually
exists.
(JSC::JSObject::getOwnNonIndexPropertyNames):
Only call getClassPropertyNames() if we have not reified. We should no longer
check the static property table after reifying now that we reify all
properties.
(JSC::JSObject::reifyAllStaticProperties):
Merge with reifyStaticFunctionsForDelete(). The only behavior change is the
flattening to an uncacheable dictionary, like reifyStaticFunctionsForDelete()
used to do.
* runtime/JSObject.h:
2016-02-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r196251.
https://bugs.webkit.org/show_bug.cgi?id=154078
Large regression on Dromaeo needs explanation (Requested by
kling on #webkit).
Reverted changeset:
"Visiting a WeakBlock should report bytes visited, since we
reported them allocated."
https://bugs.webkit.org/show_bug.cgi?id=153978
http://trac.webkit.org/changeset/196251
2016-02-10 Csaba Osztrogonác <ossy@webkit.org>
REGRESSION(r196331): It made ~180 JSC tests crash on ARMv7 Linux
https://bugs.webkit.org/show_bug.cgi?id=154064
Reviewed by Mark Lam.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate): Added EABI_32BIT_DUMMY_ARG where it is necessary.
* dfg/DFGSpeculativeJIT.h: Fixed the comment.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState): Added.
* wasm/WASMFunctionCompiler.h: Fixed the comment.
2016-02-09 Keith Miller <keith_miller@apple.com>
calling methods off super in a class constructor should check for TDZ
https://bugs.webkit.org/show_bug.cgi?id=154060
Reviewed by Ryosuke Niwa.
In a class constructor we need to check for TDZ when calling a method
off the super class. This is because, for super method calls, we use
the derived class's newly constructed object as the super method's
this value.
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionCallDotNode::emitBytecode):
* tests/stress/super-method-calls-check-tdz.js: Added.
(Base):
(Derived):
(test):
2016-02-09 Filip Pizlo <fpizlo@apple.com>
Don't crash if we fail to parse a builtin
https://bugs.webkit.org/show_bug.cgi?id=154047
rdar://problem/24300617
Reviewed by Mark Lam.
Crashing probably seemed like a good idea at the time, but we could get here in case of a
near stack overflow, so that the parser bails because of recursion.
* parser/Parser.h:
(JSC::parse):
2016-02-07 Gavin Barraclough <barraclough@apple.com>
GetValueFunc/PutValueFunc should not take both slotBase and thisValue
https://bugs.webkit.org/show_bug.cgi?id=154009
Reviewed by Geoff Garen.
In JavaScript there are two types of properties - regular value properties, and accessor properties.
One difference between these is how they are reflected by getOwnPropertyDescriptor, and another is
what object they operate on in the case of a prototype access. If you access a value property of a
prototype object it return a value pertinent to the prototype, but in the case of a prototype object
returning an accessor, then the accessor function is applied to the base object of the access.
JSC supports special 'custom' properties implemented as a c++ callback, and these custom properties
can be used to implement either value- or accessor-like behavior. getOwnPropertyDescriptor behavior
is selected via the CustomAccessor attribute. Value- or accessor-like object selection is current
supported by passing both the slotBase and the thisValue to the callback,and hoping it uses the
right one. This is probably inefficient, bug-prone, and leads to crazy like JSBoundSlotBaseFunction.
Instead, just pass one thisValue to the callback functions, consistent with CustomAccessor.
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getStaticValue):
(JSC::JSCallbackObject<Parent>::staticFunctionGetter):
(JSC::JSCallbackObject<Parent>::callbackGetter):
- Merged slotBase & thisValue to custom property callbacks.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate):
- Modified the call being JIT generated - GetValueFunc/PutValueFunc now only take 3,
rather than 4 arguments. Selects which one to keep/drop based on access type.
(WTF::printInternal):
* bytecode/PolymorphicAccess.h:
(JSC::AccessCase::isGet):
(JSC::AccessCase::isPut):
(JSC::AccessCase::isIn):
(JSC::AccessCase::doesCalls):
(JSC::AccessCase::isGetter):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
- Split the CustomGetter/Setter access types into Value/Accessor variants.
* jsc.cpp:
(WTF::CustomGetter::getOwnPropertySlot):
(WTF::CustomGetter::customGetter):
(WTF::RuntimeArray::RuntimeArray):
(WTF::RuntimeArray::lengthGetter):
- Merged slotBase & thisValue to custom property callbacks.
* runtime/CustomGetterSetter.cpp:
(JSC::callCustomSetter):
- Pass 3 arguments when calling PutValueFunc.
* runtime/CustomGetterSetter.h:
* runtime/JSBoundSlotBaseFunction.cpp:
(JSC::boundSlotBaseFunctionCall):
(JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
- callCustomSetter currently takes a flag to distinguish value/accessor calls.
* runtime/JSFunction.cpp:
(JSC::retrieveArguments):
(JSC::JSFunction::argumentsGetter):
(JSC::retrieveCallerFunction):
(JSC::JSFunction::callerGetter):
(JSC::JSFunction::lengthGetter):
(JSC::JSFunction::nameGetter):
* runtime/JSFunction.h:
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::visitChildren):
(JSC::callbackGetter):
- Merged slotBase & thisValue to custom property callbacks.
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):
- callCustomSetter currently takes a flag to distinguish value/accessor calls.
* runtime/Lookup.h:
(JSC::putEntry):
- split PutPropertySlot setCustom into Value/Accessor variants.
* runtime/PropertySlot.cpp:
(JSC::PropertySlot::functionGetter):
(JSC::PropertySlot::customGetter):
* runtime/PropertySlot.h:
(JSC::PropertySlot::PropertySlot):
(JSC::PropertySlot::getValue):
- added customGetter helper to call GetValueFunc.
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
(JSC::PutPropertySlot::setNewProperty):
(JSC::PutPropertySlot::setCustomValue):
(JSC::PutPropertySlot::setCustomAccessor):
(JSC::PutPropertySlot::setThisValue):
(JSC::PutPropertySlot::customSetter):
(JSC::PutPropertySlot::context):
(JSC::PutPropertySlot::isStrictMode):
(JSC::PutPropertySlot::isCacheablePut):
(JSC::PutPropertySlot::isCacheableSetter):
(JSC::PutPropertySlot::isCacheableCustom):
(JSC::PutPropertySlot::isCustomAccessor):
(JSC::PutPropertySlot::isInitialization):
(JSC::PutPropertySlot::cachedOffset):
(JSC::PutPropertySlot::setCustomProperty): Deleted.
- split PutPropertySlot setCustom into Value/Accessor variants.
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::getOwnPropertySlot):
(JSC::regExpConstructorDollar1):
(JSC::regExpConstructorDollar2):
(JSC::regExpConstructorDollar3):
(JSC::regExpConstructorDollar4):
(JSC::regExpConstructorDollar5):
(JSC::regExpConstructorDollar6):
(JSC::regExpConstructorDollar7):
(JSC::regExpConstructorDollar8):
(JSC::regExpConstructorDollar9):
(JSC::regExpConstructorInput):
(JSC::regExpConstructorMultiline):
(JSC::regExpConstructorLastMatch):
(JSC::regExpConstructorLastParen):
(JSC::regExpConstructorLeftContext):
(JSC::regExpConstructorRightContext):
(JSC::setRegExpConstructorInput):
(JSC::setRegExpConstructorMultiline):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
(JSC::regExpObjectSetLastIndexStrict):
(JSC::regExpObjectSetLastIndexNonStrict):
(JSC::RegExpObject::put):
- Merged slotBase & thisValue to custom property callbacks.
2016-02-09 Filip Pizlo <fpizlo@apple.com>
Spread expressions are not fair game for direct binding
https://bugs.webkit.org/show_bug.cgi?id=154042
rdar://problem/24291413
Reviewed by Saam Barati.
Prior to this change we crashed on this:
var [x] = [...y];
Because NodesCodegen thinks that this is a direct binding. It's not, because we cannot
directly generate bytecode for "...y". This is a unique property of spread expressions, so
its sufficient to just bail out of direct binding if we see a spread expression. That's what
this patch does.
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayPatternNode::emitDirectBinding):
* tests/stress/spread-in-tail.js: Added.
(foo):
(catch):
2016-02-09 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r196286.
https://bugs.webkit.org/show_bug.cgi?id=154026
Looks like 5% iOS PLT regression (Requested by kling on
#webkit).
Reverted changeset:
"[iOS] Throw away some unlinked code when navigating to a new
page."
https://bugs.webkit.org/show_bug.cgi?id=154014
http://trac.webkit.org/changeset/196286
2016-02-08 Keith Miller <keith_miller@apple.com>
Error construction for inlined operations should not use the inliner's CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=154021
Reviewed by Mark Lam.
Previously, if one function, A, was inlined into another function, B, in the DFG/FTL
we would use B's DFG/FTL CodeBlock to construct source information about the Error.
We would correctly compute the bytecodeOffset in A for the an expression but we would
not use one of A's CodeBlocks when looking up source. This caused crashes during
operationIn as we expected to be able to find the text "in" in the source.
* runtime/ErrorInstance.cpp:
(JSC::appendSourceToError):
* tests/stress/inlined-error-gets-correct-codeblock-for-bytecodeoffset.js: Added.
(map):
(n):
(one):
(catch):
2016-02-08 Saam Barati <sbarati@apple.com>
runtimeTypeForValue should protect against seeing TDZ value
https://bugs.webkit.org/show_bug.cgi?id=154023
rdar://problem/24291413
Reviewed by Michael Saboff.
There are a few back traces I've seen from crashes that bottom out
inside runtimeTypeForValue. I haven't been able to reproduce
any such crash, but it's likely that we're encountering the
empty JSValue. It's better to just have this function protect
against seeing the empty value instead of dereferencing a null
pointer when it thinks the value is a cell.
* runtime/RuntimeType.cpp:
(JSC::runtimeTypeForValue):
2016-02-08 Andreas Kling <akling@apple.com>
[iOS] Throw away some unlinked code when navigating to a new page.
<https://webkit.org/b/154014>
Reviewed by Gavin Barraclough.
* runtime/VM.cpp:
(JSC::VM::deleteAllCodeExceptCaches):
(JSC::VM::deleteAllLinkedCode): Deleted.
* runtime/VM.h:
2016-02-08 Filip Pizlo <fpizlo@apple.com>
B3::foldPathConstants() needs to execute its insertion set
https://bugs.webkit.org/show_bug.cgi?id=154020
Reviewed by Saam Barati.
* b3/B3FoldPathConstants.cpp:
* b3/testb3.cpp:
(JSC::B3::testFoldPathEqual): Added this. It used to crash in validation.
(JSC::B3::run):
2016-02-08 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Introduce @isObject bytecode intrinsic and use it instead of JS implemented one
https://bugs.webkit.org/show_bug.cgi?id=153976
Reviewed by Darin Adler.
Use bytecode op_is_object directly.
* builtins/GlobalObject.js:
(isObject): Deleted.
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_isObject):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Deleted.
2016-02-08 Yusuke Suzuki <utatane.tea@gmail.com>
{Map,Set}.prototype.forEach should be visible as own properties
https://bugs.webkit.org/show_bug.cgi?id=153974
Reviewed by Darin Adler.
Now, Map and Set uses builtin tables. We should inlude it in class info.
* runtime/MapPrototype.cpp:
* runtime/SetPrototype.cpp:
2016-02-08 Filip Pizlo <fpizlo@apple.com>
Baseline JIT should not require its input to be constant-propagated
https://bugs.webkit.org/show_bug.cgi?id=154011
rdar://problem/24290933
Reviewed by Mark Lam.
* jit/JITArithmetic.cpp:
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emitRightShiftFastPath):
(JSC::JIT::emit_op_add):
(JSC::JIT::emit_op_div):
(JSC::JIT::emit_op_mul):
2016-02-08 Filip Pizlo <fpizlo@apple.com>
CodeCache should give up on evals if there are variables under TDZ
https://bugs.webkit.org/show_bug.cgi?id=154002
rdar://problem/24300998
Reviewed by Mark Lam.
Disable the code cache optimization because our approach to TDZ for scoped variables - using
a separate check_tdz opcode when logically it's the get_from_scope's job to do it - makes
caching code impossible if there are any variables in TDZ.
We should do the right thing in the future, and fold the TDZ check into the get_from_scope.
This is better not only because it will restore caching, but because our bytecode for heap
accesses is usually at the highest practically doable level of abstraction, so that ICs,
compilers and caches can see the intended meaning of the bytecode more easily.
This doesn't appear to slow anything down, but that's just because we don't have enough ES6
benchmarks. I've filed: https://bugs.webkit.org/show_bug.cgi?id=154010
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
2016-02-08 Skachkov Oleksandr <gskachkov@gmail.com>
[ES6] Arrow function syntax. Using 'super' in arrow function that declared out of the class should lead to Syntax error
https://bugs.webkit.org/show_bug.cgi?id=150893
Reviewed by Saam Barati.
'super' and 'super()' inside of the arrow function should lead to syntax error if they are used
out of the class context or they wrapped by ordinary function. Now JSC returns ReferenceError but
should return SyntaxError according to the following specs:
http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors
and http://www.ecma-international.org/ecma-262/6.0/#sec-arrow-function-definitions-runtime-semantics-evaluation
Curren patch implemented only one case when super/super() are used inside of the arrow function
Case when super/super() are used within the eval:
class A {}
class B extends A {
costructor() { eval("super()");}
}
is not part of this patch and will be implemented in this issue https://bugs.webkit.org/show_bug.cgi?id=153864.
The same for case when eval with super/super() is invoked in arrow function will be
implemented in issue https://bugs.webkit.org/show_bug.cgi?id=153977.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::setExpectedSuperBinding):
(JSC::Scope::expectedSuperBinding):
(JSC::Scope::setConstructorKind):
(JSC::Scope::constructorKind):
(JSC::Parser::closestParentNonArrowFunctionNonLexicalScope):
* tests/stress/arrowfunction-lexical-bind-supercall-4.js:
* tests/stress/arrowfunction-lexical-bind-superproperty.js:
2016-02-08 Filip Pizlo <fpizlo@apple.com>
Parser should detect error before calls to parseAssignmentExpression()
https://bugs.webkit.org/show_bug.cgi?id=153975
rdar://problem/24291231
Reviewed by Saam Barati.
Fixes a very hard-to-create situation that an internal test picked up.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::parseAssignmentExpression):
2016-02-08 Andreas Kling <akling@apple.com>
Visiting a WeakBlock should report bytes visited, since we reported them allocated.
<https://webkit.org/b/153978>
Reviewed by Darin Adler.
When creating a WeakBlock, we tell Heap that we've allocated 1 KB (WeakBlock::blockSize)
of memory. Consequently, when visiting a WeakBlock, we should also report 1 KB of memory
visited. Otherwise Heap will think that those 1 KB already went away.
This was causing us to underestimate heap size, which affects collection scheduling.
* heap/SlotVisitor.h:
(JSC::SlotVisitor::reportMemoryVisited):
* heap/WeakBlock.cpp:
(JSC::WeakBlock::visit):
2016-02-07 Saam barati <sbarati@apple.com>
Follow up patch to: [ES6] bound functions .name property should be "bound " + the target function's name
https://bugs.webkit.org/show_bug.cgi?id=153796
Reviewed by Darin Adler.
This follow-up patch addresses some comments/suggestions by
Ryosuke, Darin, and Joe. It simplifies JSBoundFunction::toStringName
and adds some tests for bound names.
* runtime/JSBoundFunction.cpp:
(JSC::hasInstanceBoundFunction):
(JSC::JSBoundFunction::create):
(JSC::JSBoundFunction::toStringName):
2016-02-07 Filip Pizlo <fpizlo@apple.com>
String.match should defend against matches that would crash the VM
https://bugs.webkit.org/show_bug.cgi?id=153964
rdar://problem/24301119
Reviewed by Saam Barati.
This fixes a crash in an internal test case.
* runtime/ArgList.cpp:
(JSC::MarkedArgumentBuffer::slowAppend): Use best practices to ensure that the size we
compute makes sense. Crash if it stops making sense, since most users of this API assume
that they are creating something small enough to fit on the stack.
* runtime/ArgList.h:
(JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer):
(JSC::MarkedArgumentBuffer::size):
(JSC::MarkedArgumentBuffer::operator new): Deleted. These were ineffective. According to the
debugger, we were still calling system malloc. So, I changed the code to use fastMalloc()
directly.
(JSC::MarkedArgumentBuffer::operator delete): Deleted.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncMatch): Explicitly defend against absurd sizes. Of course, it's still
possible to crash the VM on OOME. That's sort of always been the philosophy of JSC - we
don't guarantee that you'll get a nice-looking error whenever you run out of memory,
since in a GC'd environment you can't really guarantee those things. But, if you have a
match that obvious won't fit in memory, then reporting an error is useful in case this is
a developer experimenting with a buggy regexp.
2016-02-07 Dan Bernstein <mitz@apple.com>
[Cocoa] Replace __has_include guards around inclusion of Apple-internal-SDK headers with USE(APPLE_INTERNAL_SDK)
https://bugs.webkit.org/show_bug.cgi?id=153963
Reviewed by Sam Weinig.
* inspector/remote/RemoteInspectorXPCConnection.mm:
2016-02-06 Filip Pizlo <fpizlo@apple.com>
FTL must store the call site index before runtime calls, even if it's the tail call slow path
https://bugs.webkit.org/show_bug.cgi?id=153955
rdar://problem/24290970
Reviewed by Saam Barati.
This is necessary because you could throw an exception in a host call on the tail call's slow
path. That'll route us to lookupExceptionHandler(), which unwinds starting with the call site
index of our frame. Bad things happen if it's not set. Prior to this patch it was possible
for the call site index field to be uninitialized, which meant that the throwing machinery
was making a wild guess about where we are.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
* tests/stress/tail-call-host-call-throw.js: Added.
2016-02-06 Darin Adler <darin@apple.com>
Finish auditing call sites of upper() and lower(), eliminate many, and rename the functions
https://bugs.webkit.org/show_bug.cgi?id=153905
Reviewed by Sam Weinig.
* runtime/IntlObject.cpp:
(JSC::canonicalLangTag): Use converToASCIIUppercase on the language tag.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncToLowerCase): Tweak style and update for name change.
(JSC::stringProtoFuncToUpperCase): Ditto.
2016-02-06 Chris Dumez <cdumez@apple.com>
Object.getOwnPropertyDescriptor() does not work on sub-frame's window
https://bugs.webkit.org/show_bug.cgi?id=153925
Reviewed by Darin Adler.
Calling Object.getOwnPropertyDescriptor() on a sub-frame's window was
returning undefined for that window's own properties. The reason was
that the check getOwnPropertySlot() is using to make sure the
PropertySlot is not for a property coming from the prototype was wrong.
The check was checking that 'this != slotBase' which works fine unless
this is a JSProxy (e.g. JSDOMWindowShell). To handle proxies, the code
was also checking that 'slotBase.toThis() != this', attempting to
get the slotBase/Window's proxy. However, due to the implementation of
toThis(), we were getting the lexical global object's proxy instead of
slotBase's proxy. To avoid this issue, the new code explicitly checks
if 'this' is a JSProxy and makes sure 'JSProxy::target() != slotBase',
instead of using toThis().
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyDescriptor):
2016-02-06 Andreas Kling <akling@apple.com>
[iOS] Throw away linked code when navigating to a new page.
<https://webkit.org/b/153851>
Reviewed by Gavin Barraclough.
Add a VM API for throwing away linked code only.
* runtime/VM.cpp:
(JSC::VM::deleteAllLinkedCode):
* runtime/VM.h:
2016-02-06 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r196104.
https://bugs.webkit.org/show_bug.cgi?id=153940
Regressed Speedometer on iOS (Requested by kling on #webkit).
Reverted changeset:
"[iOS] Throw away linked code when navigating to a new page."
https://bugs.webkit.org/show_bug.cgi?id=153851
http://trac.webkit.org/changeset/196104
2016-02-05 Alex Christensen <achristensen@webkit.org>
Fix internal Windows build
https://bugs.webkit.org/show_bug.cgi?id=153930
<rdar://problem/24534864>
Reviewed by Mark Lam.
* JavaScriptCore.vcxproj/JavaScriptCore.proj:
I made a typo in r196144.
2016-02-05 Saam barati <sbarati@apple.com>
Web Inspector: Include SamplingProfiler's expression-level data for stack frames in the protocol
https://bugs.webkit.org/show_bug.cgi?id=153455
<rdar://problem/24335884>
Reviewed by Joseph Pecoraro.
We now send the sampling profiler's expression-level
line/column info in the inspector protocol.
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::buildSamples):
* inspector/protocol/ScriptProfiler.json:
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::StackFrame::hasExpressionInfo):
2016-02-05 Saam barati <sbarati@apple.com>
follow-up to: JSC Sampling Profiler: (host) is confusing in cases where I would expect to see JS name
https://bugs.webkit.org/show_bug.cgi?id=153663
<rdar://problem/24415092>
Rubber stamped by Joseph Pecoraro.
We were performing operations that required us to
hold the VM lock even when we might not have been holding it.
We now ensure we're holding it.
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
2016-02-05 Filip Pizlo <fpizlo@apple.com>
Arrayify for a typed array shouldn't create a monster
https://bugs.webkit.org/show_bug.cgi?id=153908
rdar://problem/24290639
Reviewed by Mark Lam.
Previously if you convinced the DFG to emit an Arrayify to ArrayStorage and then gave it a
typed array, you'd corrupt the object.
* runtime/JSArrayBufferView.cpp:
(WTF::printInternal):
* runtime/JSArrayBufferView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
(JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
* runtime/JSObject.cpp:
(JSC::JSObject::copyButterfly):
(JSC::JSObject::enterDictionaryIndexingMode):
(JSC::JSObject::ensureInt32Slow):
(JSC::JSObject::ensureDoubleSlow):
(JSC::JSObject::ensureContiguousSlow):
(JSC::JSObject::ensureArrayStorageSlow):
(JSC::JSObject::growOutOfLineStorage):
(JSC::getBoundSlotBaseFunctionForGetterSetter):
* runtime/Structure.h:
* tests/stress/arrayify-array-storage-typed-array.js: Added. This test failed.
* tests/stress/arrayify-int32-typed-array.js: Added. This test case already had other protections, but we beefed them up.
2016-02-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: InspectorTimelineAgent doesn't need to recompile functions because it now uses the sampling profiler
https://bugs.webkit.org/show_bug.cgi?id=153500
<rdar://problem/24352458>
Reviewed by Timothy Hatcher.
Be more explicit about enabling legacy profiling.
* jsc.cpp:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::hasLegacyProfiler):
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
(JSC::JSGlobalObject::createModuleProgramCodeBlock):
(JSC::JSGlobalObject::hasProfiler): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::supportsLegacyProfiling):
(JSC::JSGlobalObject::supportsProfiling): Deleted.
2016-02-04 Keith Miller <keith_miller@apple.com>
ArrayPrototype should have a destroy function
https://bugs.webkit.org/show_bug.cgi?id=153847
Reviewed by Filip Pizlo.
ArrayPrototype should have an destroy function as it now has a unique_ptr member that
needs to be freed at the end of the object's life cycle. Also, this patch adds an
option, gcAtEnd, that will cause jsc.cpp to do a garbage collection before exiting.
* jsc.cpp:
(runJSC):
(jscmain):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::create):
(JSC::ArrayPrototype::destroy):
* runtime/ArrayPrototype.h:
* runtime/Options.h:
2016-02-04 Filip Pizlo <fpizlo@apple.com>
REGRESSION(192409): Cannot rely on add32() to zero-extend
https://bugs.webkit.org/show_bug.cgi?id=153897
Unreviewed rollout of r192409.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::add32):
(JSC::MacroAssemblerARM64::add64):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::add32):
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::add32):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::add32):
(JSC::MacroAssemblerX86Common::add8):
(JSC::MacroAssemblerX86Common::branchAdd32):
(JSC::MacroAssemblerX86Common::generateTest32):
(JSC::MacroAssemblerX86Common::clz32AfterBsr):
(JSC::MacroAssemblerX86Common::add32AndSetFlags): Deleted.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::add32):
(JSC::MacroAssemblerX86_64::add64):
(JSC::MacroAssemblerX86_64::branchAdd64):
(JSC::MacroAssemblerX86_64::repatchCall):
(JSC::MacroAssemblerX86_64::clz64AfterBsr):
(JSC::MacroAssemblerX86_64::add64AndSetFlags): Deleted.
2016-02-04 Andreas Kling <akling@apple.com>
Remove dead ENABLE(BYTECODE_COMMENTS) cruft.
<https://webkit.org/b/153888>
Reviewed by Antti Koivisto.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
2016-02-04 Saam barati <sbarati@apple.com>
JSC Sampling Profiler: (host) is confusing in cases where I would expect to see JS name
https://bugs.webkit.org/show_bug.cgi?id=153663
<rdar://problem/24415092>
Reviewed by Geoffrey Garen.
We now collect the Callee in the processed StackFrame
when the Callee is a valid GC object. We later ask
the Callee for it's .displayName or .name property.
When we don't have a valid callee, we will still
use the Executable for this information.
This helps us come up with good names for frames where
the Callee object is a bound function or an InternalFunction.
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::addEvent):
(Inspector::buildSamples):
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
* runtime/SamplingProfiler.cpp:
(JSC::reportStats):
(JSC::FrameWalker::walk):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::visit):
(JSC::SamplingProfiler::shutdown):
(JSC::SamplingProfiler::clearData):
(JSC::SamplingProfiler::StackFrame::nameFromCallee):
(JSC::SamplingProfiler::StackFrame::displayName):
(JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
(JSC::SamplingProfiler::stackTracesAsJSON):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
(JSC::SamplingProfiler::StackFrame::StackFrame):
* tests/stress/sampling-profiler-basic.js:
(platformSupportsSamplingProfiler.nothing):
(platformSupportsSamplingProfiler.top):
* tests/stress/sampling-profiler-bound-function-name.js: Added.
(platformSupportsSamplingProfiler.foo):
(platformSupportsSamplingProfiler.bar):
(platformSupportsSamplingProfiler.let.baz):
(platformSupportsSamplingProfiler):
* tests/stress/sampling-profiler-display-name.js: Added.
(platformSupportsSamplingProfiler.foo):
(platformSupportsSamplingProfiler.baz):
(platformSupportsSamplingProfiler.):
(platformSupportsSamplingProfiler.bar):
(platformSupportsSamplingProfiler.jaz):
(platformSupportsSamplingProfiler.makeFunction.let.result):
(platformSupportsSamplingProfiler.makeFunction):
* tests/stress/sampling-profiler-internal-function-name.js: Added.
(platformSupportsSamplingProfiler.foo):
(platformSupportsSamplingProfiler.bar):
(platformSupportsSamplingProfiler):
2016-02-04 Chris Dumez <cdumez@apple.com>
Object.getOwnPropertyDescriptor() returns incomplete descriptor for instance properties
https://bugs.webkit.org/show_bug.cgi?id=153817
Reviewed by Geoffrey Garen.
Extend support for Object.getOwnPropertyDescriptor() on native bindings
to instance properties (e.g. Unforgeable properties or Global object
properties) so that the returned descriptor has getter / setter
functions, as expected.
* runtime/JSObject.cpp:
(JSC::JSObject::reifyAllStaticProperties):
Add method that reifies all static properties, including the custom
accessors. This is similar to what is done eagerly on the prototype
objects in the bindings code.
(JSC::JSObject::getOwnPropertyDescriptor):
getOwnPropertyDescriptor() would previously fails for custom accessors
that are on the instance because getDirect() does not check the static
property table and those custom accessors were not reified (We only
reified all properties eagerly - including custom accessors - on
prototype objects. To address this issue, we now call
reifyAllStaticProperties() if the call to getDirect() fails and then
call getDirect() again. This fix is however insufficient for Window
properties because |this| is a JSDOMWindowShell / JSProxy in this case
and getDirect() / reifyAllStaticProperties() would fail as the proxy
does not actually have the properties. This issue was addressed by
checking if |this| is a JSProxy and then using JSProxy::target() instead
of |this| for the calls to getDirect() and for the reification.
* runtime/JSObject.h:
* runtime/Lookup.h:
(JSC::reifyStaticProperty):
(JSC::reifyStaticProperties):
Move most code in reifyStaticProperties() to a separate function so the
code can be shared with JSObject::reifyAllStaticProperties().
reifyStaticProperties() is currently called by the bindings on the
prototype objects.
2016-02-04 Alex Christensen <achristensen@webkit.org>
Fix internal Windows build
https://bugs.webkit.org/show_bug.cgi?id=153886
<rdar://problem/24499887>
Reviewed by Mark Lam.
* JavaScriptCore.vcxproj/JavaScriptCore.proj:
In r190253 I changed the directory of the headers from AppleInternal/include/JavaScriptCore
to AppleInternal/include/private/JavaScriptCore. This is ok for WebCore and WebKit, but not
other projects, such as CFNetwork, which expect the public API headers to be in the old location.
This used to be done by a combination of copy-files.cmd and the old JavaScriptCore.proj.
This change copies all the API headers, which copies everything in copy-files.cmd except APIShims.h
which does not exist any more. It copies additional headers that were not copied before, but
I think this is beneficial so we do not forget to add new public headers to a list of public headers
to be copied in the internal build. Having extra public headers in the internal Windows build is
not a problem because only internal clients use the internal Windows build.
2016-02-03 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Make some classes non JSDestructibleObject
https://bugs.webkit.org/show_bug.cgi?id=153838
Reviewed by Geoffrey Garen.
SymbolPrototype, JSMapIterator and JSSetIterator are trivially destructible.
So there is no need to inherit JSDestructibleObject.
* runtime/JSMapIterator.cpp:
(JSC::JSMapIterator::destroy): Deleted.
* runtime/JSMapIterator.h:
* runtime/JSSetIterator.cpp:
(JSC::JSSetIterator::destroy): Deleted.
* runtime/JSSetIterator.h:
* runtime/MapData.h:
* runtime/SymbolPrototype.h:
2016-02-03 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Symbol structure has unnecessary flags
https://bugs.webkit.org/show_bug.cgi?id=153840
Reviewed by Saam Barati.
* runtime/Symbol.h:
* tests/stress/symbol-get-own-property.js: Added.
(shouldBe):
2016-02-03 Andreas Kling <akling@apple.com>
[iOS] Throw away linked code when navigating to a new page.
<https://webkit.org/b/153851>
Reviewed by Gavin Barraclough.
Add a VM API for throwing away linked code only.
* runtime/VM.cpp:
(JSC::VM::deleteAllLinkedCode):
* runtime/VM.h:
2016-02-03 Michael Catanzaro <mcatanzaro@igalia.com>
[GTK][EFL] Switch FTL to B3
https://bugs.webkit.org/show_bug.cgi?id=153478
Reviewed by Csaba Osztrogonác.
Conditionalize code to make it possible to build FTL completely without LLVM.
* CMakeLists.txt:
* dfg/DFGCommon.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* ftl/FTLAbbreviatedTypes.h:
* ftl/FTLFail.cpp:
(JSC::FTL::fail):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
(JSC::FTL::State::~State):
2016-02-03 Carlos Garcia Campos <cgarcia@igalia.com>
Unreviewed. Fix JavaScriptCore build with B3 enabled.
Include <limits.h> for UINT_MAX.
* b3/B3StackSlot.h:
* b3/air/AirStackSlot.h:
2016-02-02 Caitlin Potter <caitp@igalia.com>
JSSymbolTableObject::deleteProperty() crashes deleting Symbols
https://bugs.webkit.org/show_bug.cgi?id=153816
Reviewed by Darin Adler.
Changes JSSymbolTableObject::deleteProperty() to check if its
symbolTable() contains the property's uid() rather than publicName().
This ensures that it will not crash in the case of Symbols.
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::deleteProperty):
* tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
(testGlobalProxy):
* tests/stress/regress-153816.js: Added.
(deleteSymbolFromJSSymbolTableObject):
2016-02-02 Benjamin Poulain <benjamin@webkit.org>
[JSC] Do not copy FP when lowering FramePointer
https://bugs.webkit.org/show_bug.cgi?id=153769
Reviewed by Michael Saboff.
That extra move is just wasted time. The fewer Moves we have,
the happier IRC is.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tmp):
(JSC::B3::Air::LowerToAir::lower):
2016-02-02 Keith Miller <keith_miller@apple.com>
DFG, FTL, B3, and Air should all have a unique option for printing their graphs
https://bugs.webkit.org/show_bug.cgi?id=153815
Reviewed by Benjamin Poulain.
This patch adds a new printing option for each of the DFG/FTL compilation phases.
* b3/B3Common.cpp:
(JSC::B3::shouldDumpIR):
(JSC::B3::shouldDumpIRAtEachPhase):
* b3/B3Common.h:
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3PhaseScope.cpp:
(JSC::B3::PhaseScope::PhaseScope):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* b3/air/AirPhaseScope.cpp:
(JSC::B3::Air::PhaseScope::PhaseScope):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::run):
* dfg/DFGCommon.h:
(JSC::DFG::shouldDumpGraphAtEachPhase):
* dfg/DFGPhase.cpp:
(JSC::DFG::Phase::beginPhase):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2016-02-02 Caitlin Potter <caitp@igalia.com>
[JSC] make Object.getOwnPropertyDescriptors() work with non-JSObject types
https://bugs.webkit.org/show_bug.cgi?id=153814
Reviewed by Yusuke Suzuki.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptors):
* tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
(testGlobalProxy):
2016-02-02 Aakash Jain <aakash_jain@apple.com>
Remove references to CallFrameInlines.h
https://bugs.webkit.org/show_bug.cgi?id=153810
Reviewed by Mark Lam.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2016-02-02 Caitlin Potter <caitp@igalia.com>
[JSC] Implement Object.getOwnPropertyDescriptors() proposal
https://bugs.webkit.org/show_bug.cgi?id=153799
Reviewed by Darin Adler.
Implements the Object.getOwnPropertyDescriptors() proposal, which
reached Stage 3 in the TC39 process in January 2016.
https://github.com/tc39/proposal-object-getownpropertydescriptors
The method extracts a set of property descriptor objects, which can
be safely used via `Object.create()`.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptors):
2016-02-02 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile trivial self-loops
https://bugs.webkit.org/show_bug.cgi?id=153802
rdar://problem/24465632
Reviewed by Michael Saboff.
Tail-duplicating a self-loop would mean doing a kind of loop unrolling. It wouldn't be
profitable even if it did work. It turns out that it doesn't work, because we edit the target
block before reading the source block, which breaks if the target and source block are the
same.
This disables tail duplication of self-loops, adds a test, and adds better validation for this
issue.
* b3/B3DuplicateTails.cpp:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::resetReachability):
* b3/testb3.cpp:
(JSC::B3::testComputeDivisionMagic):
(JSC::B3::testTrivialInfiniteLoop):
(JSC::B3::zero):
(JSC::B3::run):
2016-02-02 Saam barati <sbarati@apple.com>
[ES6] bound functions .name property should be "bound " + the target function's name
https://bugs.webkit.org/show_bug.cgi?id=153796
Reviewed by Mark Lam.
See http://tc39.github.io/ecma262/#sec-function.prototype.bind for details.
What the spec says:
```
function foo() { }
foo.bind(null).name === "bound foo"
(function bar() { }).bind(null).name === "bound bar"
```
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* runtime/JSBoundFunction.cpp:
(JSC::hasInstanceBoundFunction):
(JSC::JSBoundFunction::create):
(JSC::JSBoundFunction::visitChildren):
(JSC::JSBoundFunction::toStringName):
* runtime/JSBoundFunction.h:
(JSC::JSBoundFunction::boundThis):
(JSC::JSBoundFunction::boundArgs):
(JSC::JSBoundFunction::createStructure):
* tests/es6.yaml:
2016-02-02 Filip Pizlo <fpizlo@apple.com>
Get rid of anonymous stack slots
https://bugs.webkit.org/show_bug.cgi?id=151128
Reviewed by Mark Lam.
When I first designed stack slots, the idea was that an "anonymous" stack slot was one that
behaved exactly like a C variable: if it never escaped, it would not need to get stack space
for the entire lifetime of the function - it could get any slab of stack so long as it
didn't interfere with other stack slots that would be live at the same time. The reason I
called them "anonymous" is that external code could not get its address. This felt like it
gave the stack slot anonymity. But it was never a good name for this concept.
Then I had the register allocator lower temporaries to anonymous stack slots when it spilled
them. Spilling became the sole client of anonymous stack slots.
Then I realized that there was an aspect of how spill slots work that make them want
slightly different semantics than a normal C variable. A C variable is a proper memory
location - you could do a store to only some bytes in the variable, and it's reasonable to
expect that this will not destroy the other bytes in the variable. But that means that to
compute their liveness, you have to do something like a per-byte liveness. That's overkill
for spill slots. You want any store to the spill slot to kill the whole slot even if it
writes to just part of the slot. This matches how temporaries work. So rather than implement
per-byte liveness, I decided to change the semantics of anonymous stack slots to make them
work like how I wanted spill slots to work. This was quite dirty, and put B3 in the awkward
situation that B3's anonymous stack slots behaved like spill slots. But it was OK since
nobody used anonymous stack slots in B3.
Then I added tail duplication, which required having a mechanism for introducing non-SSA
variables in B3. I decided to use anonymous stack slots for this purpose. All of a sudden
this all felt like it made sense: anonymous stack slots were just like variables! Hooray for
the amazing foresight of anonymous stack slots!
But then I realized that this was all very bad. We want B3 to be able to optimize Store and
Load operations by reasoning about how they affect bytes in memory. For example, if you do
a Load of a 64-bit value, and then you modify just the low 32 bits of that value, and then
you do a 64-bit store back to the same location, then it would be better to transform this
into 32-bit operations. We don't do this optimization yet, but it's the kind of thing that
we want B3 to be able to do. To do it, we need Store to mean that it only affects N bytes
starting at the pointer, where N is the size of the thing being stored. But that's not what
Store means for anonymous stack slots. For anonymous slots, storing to any byte in the slot
clobbers all bytes in the slot. We were never clear if you need to store directly to an
anonymous slot to get this behavior, or if any pointer that points to an anoymous slot must
exhibit this behavior when stored to. Neither kinds of semantics make sense to me.
This change fixes the problem by eradicating anonymous stack slots. In B3, they are replaced
with Variables. In Air, they are replaced with a different stack slot kind, called Spill.
There is no such thing as stack slot kinds in B3 anymore, all B3 stack slots are locked. In
Air, there is still the concept of stack slot kind - Locked or Spill.
B3 Variables are awesome. They are exactly what they seem to be. They have a type. They are
declared at the top level in the Procedure. You can access them with new opcodes, Get and
Set. This greatly simplifies demoting SSA values to variables and promoting them back to
SSA. I even made the instruction selector do the right things for variables, which means
that introducing variables won't hurt instruction selection (there will be extra moves, but
IRC will kill them). It's great to have non-SSA variables as an explicit concept in IR
because it means that you don't have to do any magic to use them - they Just Work.
Air spill slots behave almost like anonymous stack slots, with one exception: you cannot
escape them. We validate this by making it illegal to UseAddr on a spill slot. This removes
the need to answer awkward questions like: does a 32-bit Def on a pointer that may point to
a 64-bit spill slot do anything to the 32 bits above the pointer? Does it write zero to it?
Does it write zero to it just when the pointer actually points to a spill slot or always?
These are silly questions, and we don't have to answer them because the only way to refer to
a spill slot is directly. No escaping means no aliasing.
This doesn't affect performance. It just makes the compiler more fun to work with by
removing some cognitive dissonance.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3ArgumentRegValue.h:
* b3/B3CCallValue.h:
* b3/B3CheckValue.cpp:
(JSC::B3::CheckValue::cloneImpl):
(JSC::B3::CheckValue::CheckValue):
* b3/B3CheckValue.h:
* b3/B3Const32Value.h:
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.h:
* b3/B3ConstPtrValue.h:
(JSC::B3::ConstPtrValue::ConstPtrValue):
* b3/B3ControlValue.cpp:
(JSC::B3::ControlValue::convertToJump):
(JSC::B3::ControlValue::convertToOops):
(JSC::B3::ControlValue::dumpMeta):
* b3/B3ControlValue.h:
* b3/B3Effects.cpp:
(JSC::B3::Effects::interferes):
(JSC::B3::Effects::dump):
* b3/B3Effects.h:
(JSC::B3::Effects::mustExecute):
* b3/B3EliminateCommonSubexpressions.cpp:
* b3/B3FixSSA.cpp:
(JSC::B3::demoteValues):
(JSC::B3::fixSSA):
* b3/B3FixSSA.h:
* b3/B3IndexMap.h:
(JSC::B3::IndexMap::resize):
(JSC::B3::IndexMap::clear):
(JSC::B3::IndexMap::size):
(JSC::B3::IndexMap::operator[]):
* b3/B3IndexSet.h:
(JSC::B3::IndexSet::contains):
(JSC::B3::IndexSet::size):
(JSC::B3::IndexSet::isEmpty):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3MemoryValue.h:
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3PatchpointValue.cpp:
(JSC::B3::PatchpointValue::cloneImpl):
(JSC::B3::PatchpointValue::PatchpointValue):
* b3/B3PatchpointValue.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::Procedure):
(JSC::B3::Procedure::addBlock):
(JSC::B3::Procedure::addStackSlot):
(JSC::B3::Procedure::addVariable):
(JSC::B3::Procedure::clone):
(JSC::B3::Procedure::addIntConstant):
(JSC::B3::Procedure::dump):
(JSC::B3::Procedure::deleteStackSlot):
(JSC::B3::Procedure::deleteVariable):
(JSC::B3::Procedure::deleteValue):
(JSC::B3::Procedure::deleteOrphans):
(JSC::B3::Procedure::calleeSaveRegisters):
(JSC::B3::Procedure::addValueImpl):
(JSC::B3::Procedure::setBlockOrderImpl):
(JSC::B3::Procedure::addAnonymousStackSlot): Deleted.
(JSC::B3::Procedure::addStackSlotIndex): Deleted.
(JSC::B3::Procedure::addValueIndex): Deleted.
* b3/B3Procedure.h:
(JSC::B3::Procedure::setBlockOrder):
(JSC::B3::Procedure::stackSlots):
(JSC::B3::Procedure::variables):
(JSC::B3::Procedure::values):
(JSC::B3::Procedure::StackSlotsCollection::StackSlotsCollection): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::size): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::at): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::operator[]): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::iterator::iterator): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::iterator::operator*): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::iterator::operator++): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::iterator::operator==): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::iterator::operator!=): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::iterator::findNext): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::begin): Deleted.
(JSC::B3::Procedure::StackSlotsCollection::end): Deleted.
(JSC::B3::Procedure::ValuesCollection::ValuesCollection): Deleted.
(JSC::B3::Procedure::ValuesCollection::iterator::iterator): Deleted.
(JSC::B3::Procedure::ValuesCollection::iterator::operator*): Deleted.
(JSC::B3::Procedure::ValuesCollection::iterator::operator++): Deleted.
(JSC::B3::Procedure::ValuesCollection::iterator::operator==): Deleted.
(JSC::B3::Procedure::ValuesCollection::iterator::operator!=): Deleted.
(JSC::B3::Procedure::ValuesCollection::iterator::findNext): Deleted.
(JSC::B3::Procedure::ValuesCollection::begin): Deleted.
(JSC::B3::Procedure::ValuesCollection::end): Deleted.
(JSC::B3::Procedure::ValuesCollection::size): Deleted.
(JSC::B3::Procedure::ValuesCollection::at): Deleted.
(JSC::B3::Procedure::ValuesCollection::operator[]): Deleted.
* b3/B3ProcedureInlines.h:
(JSC::B3::Procedure::add):
* b3/B3ReduceStrength.cpp:
* b3/B3SlotBaseValue.h:
* b3/B3SparseCollection.h: Added.
(JSC::B3::SparseCollection::SparseCollection):
(JSC::B3::SparseCollection::add):
(JSC::B3::SparseCollection::addNew):
(JSC::B3::SparseCollection::remove):
(JSC::B3::SparseCollection::size):
(JSC::B3::SparseCollection::isEmpty):
(JSC::B3::SparseCollection::at):
(JSC::B3::SparseCollection::operator[]):
(JSC::B3::SparseCollection::iterator::iterator):
(JSC::B3::SparseCollection::iterator::operator*):
(JSC::B3::SparseCollection::iterator::operator++):
(JSC::B3::SparseCollection::iterator::operator==):
(JSC::B3::SparseCollection::iterator::operator!=):
(JSC::B3::SparseCollection::iterator::findNext):
(JSC::B3::SparseCollection::begin):
(JSC::B3::SparseCollection::end):
* b3/B3StackSlot.cpp:
(JSC::B3::StackSlot::deepDump):
(JSC::B3::StackSlot::StackSlot):
* b3/B3StackSlot.h:
(JSC::B3::StackSlot::byteSize):
(JSC::B3::StackSlot::index):
(JSC::B3::StackSlot::setOffsetFromFP):
(JSC::B3::StackSlot::kind): Deleted.
(JSC::B3::StackSlot::isLocked): Deleted.
* b3/B3StackSlotKind.cpp: Removed.
* b3/B3StackSlotKind.h: Removed.
* b3/B3StackmapValue.cpp:
(JSC::B3::StackmapValue::dumpMeta):
(JSC::B3::StackmapValue::StackmapValue):
* b3/B3StackmapValue.h:
* b3/B3SwitchValue.cpp:
(JSC::B3::SwitchValue::cloneImpl):
(JSC::B3::SwitchValue::SwitchValue):
* b3/B3SwitchValue.h:
* b3/B3UpsilonValue.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::replaceWithIdentity):
(JSC::B3::Value::replaceWithNop):
(JSC::B3::Value::replaceWithPhi):
(JSC::B3::Value::dump):
(JSC::B3::Value::effects):
(JSC::B3::Value::checkOpcode):
* b3/B3Value.h:
* b3/B3Variable.cpp: Added.
(JSC::B3::Variable::~Variable):
(JSC::B3::Variable::dump):
(JSC::B3::Variable::deepDump):
(JSC::B3::Variable::Variable):
* b3/B3Variable.h: Added.
(JSC::B3::Variable::type):
(JSC::B3::Variable::index):
(JSC::B3::DeepVariableDump::DeepVariableDump):
(JSC::B3::DeepVariableDump::dump):
(JSC::B3::deepDump):
* b3/B3VariableValue.cpp: Added.
(JSC::B3::VariableValue::~VariableValue):
(JSC::B3::VariableValue::dumpMeta):
(JSC::B3::VariableValue::cloneImpl):
(JSC::B3::VariableValue::VariableValue):
* b3/B3VariableValue.h: Added.
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::addStackSlot):
(JSC::B3::Air::Code::addSpecial):
(JSC::B3::Air::Code::cCallSpecial):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::begin):
(JSC::B3::Air::Code::end):
(JSC::B3::Air::Code::stackSlots):
(JSC::B3::Air::Code::specials):
(JSC::B3::Air::Code::forAllTmps):
(JSC::B3::Air::Code::StackSlotsCollection::StackSlotsCollection): Deleted.
(JSC::B3::Air::Code::StackSlotsCollection::size): Deleted.
(JSC::B3::Air::Code::StackSlotsCollection::at): Deleted.
(JSC::B3::Air::Code::StackSlotsCollection::operator[]): Deleted.
(JSC::B3::Air::Code::StackSlotsCollection::iterator::iterator): Deleted.
(JSC::B3::Air::Code::StackSlotsCollection::iterator::operator*): Deleted.
(JSC::B3::Air::Code::StackSlotsCollection::iterator::operator++): Deleted.
(JSC::B3::Air::Code::StackSlotsCollection::iterator::operator==): Deleted.
(JSC::B3::Air::Code::StackSlotsCollection::iterator::operator!=): Deleted.
(JSC::B3::Air::Code::StackSlotsCollection::begin): Deleted.
(JSC::B3::Air::Code::StackSlotsCollection::end): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::SpecialsCollection): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::size): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::at): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::operator[]): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::iterator::iterator): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::iterator::operator*): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::iterator::operator++): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::iterator::operator==): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::iterator::operator!=): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::begin): Deleted.
(JSC::B3::Air::Code::SpecialsCollection::end): Deleted.
* b3/air/AirFixObviousSpills.cpp:
* b3/air/AirInstInlines.h:
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirLiveness.h:
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirSpecial.cpp:
(JSC::B3::Air::Special::Special):
* b3/air/AirSpecial.h:
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/AirStackSlot.cpp:
(JSC::B3::Air::StackSlot::dump):
(JSC::B3::Air::StackSlot::deepDump):
(JSC::B3::Air::StackSlot::StackSlot):
* b3/air/AirStackSlot.h:
(JSC::B3::Air::StackSlot::byteSize):
(JSC::B3::Air::StackSlot::kind):
(JSC::B3::Air::StackSlot::isLocked):
(JSC::B3::Air::StackSlot::isSpill):
(JSC::B3::Air::StackSlot::index):
(JSC::B3::Air::StackSlot::ensureSize):
* b3/air/AirStackSlotKind.cpp: Copied from Source/JavaScriptCore/b3/B3StackSlotKind.cpp.
(WTF::printInternal):
* b3/air/AirStackSlotKind.h: Copied from Source/JavaScriptCore/b3/B3StackSlotKind.h.
* b3/air/opcode_generator.rb:
* b3/air/testair.cpp:
(JSC::B3::Air::testShuffleBroadcastAllRegs):
(JSC::B3::Air::testShuffleShiftAllRegs):
(JSC::B3::Air::testShuffleRotateAllRegs):
* b3/testb3.cpp:
(JSC::B3::testStackSlot):
(JSC::B3::testStoreLoadStackSlot):
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::lockedStackSlot):
(JSC::FTL::Output::neg):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
2016-02-02 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Introduce BytecodeIntrinsic constant rep like @undefined
https://bugs.webkit.org/show_bug.cgi?id=153737
Reviewed by Darin Adler.
This patch enhances existing BytecodeIntrinsic mechanism to accept `@xxx` form,
that will be used to represent bytecode intrinsic constants.
After this change, we can use 2 forms for bytecode intrinsics. (1) Function form (like, @toString(value))
and (2) Constant form (like @undefined).
Bytecode intrinsic constants allow us to easily expose constant values from C++ world.
For example, we can expose ArrayIterationKind flags to JS world without using private global variables.
Exposed constant values are loaded from bytecodes directly through constant registers.
While previously we expose them through private global variables, bytecode intrinsic constants
can be loaded directly from CodeBlock. And later, it will become JSConstant in DFG.
And by using this mechanism, we implement several constants. @undefined, @arrayIterationKindKeyValue etc.
* builtins/ArrayConstructor.js:
(from):
* builtins/ArrayIteratorPrototype.js:
(next):
* builtins/ArrayPrototype.js:
(reduce):
(reduceRight):
(every):
(forEach):
(filter):
(map):
(some):
(fill):
(find):
(findIndex):
(includes):
(sort.compactSparse):
(sort.compactSlow):
(sort.compact):
(sort):
(copyWithin):
* builtins/DatePrototype.js:
(toLocaleString.toDateTimeOptionsAnyAll):
(toLocaleString):
(toLocaleDateString.toDateTimeOptionsDateDate):
(toLocaleDateString):
(toLocaleTimeString.toDateTimeOptionsTimeTime):
(toLocaleTimeString):
* builtins/GeneratorPrototype.js:
(generatorResume):
* builtins/GlobalObject.js:
(isDictionary):
* builtins/InternalPromiseConstructor.js:
(internalAll.newResolveElement):
(internalAll):
* builtins/IteratorPrototype.js:
(symbolIteratorGetter):
(symbolIterator): Deleted.
* builtins/MapPrototype.js:
(forEach):
* builtins/ModuleLoaderObject.js:
(newRegistryEntry):
(forceFulfillPromise):
(commitInstantiated):
(requestFetch):
(requestTranslate):
(requestInstantiate):
(requestLink):
(provide):
* builtins/PromiseConstructor.js:
(all.newResolveElement):
(all):
(race):
(reject):
(resolve):
* builtins/PromiseOperations.js:
(newPromiseCapability.executor):
(newPromiseCapability):
(rejectPromise):
(fulfillPromise):
(createResolvingFunctions.resolve):
(createResolvingFunctions.reject):
(createResolvingFunctions):
(promiseReactionJob):
(promiseResolveThenableJob):
(initializePromise):
* builtins/PromisePrototype.js:
(catch):
(then):
* builtins/SetPrototype.js:
(forEach):
* builtins/StringConstructor.js:
(raw):
* builtins/StringIteratorPrototype.js:
(next):
* builtins/StringPrototype.js:
(localeCompare):
* builtins/TypedArrayConstructor.js:
(of):
(from):
* builtins/TypedArrayPrototype.js:
(every):
(find):
(findIndex):
(forEach):
(some):
(reduce):
(reduceRight):
(map):
(filter):
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
(JSC::BytecodeIntrinsicRegistry::lookup):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecompiler/NodesCodegen.cpp:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createResolve):
(JSC::ASTBuilder::makeFunctionCallNode):
* parser/NodeConstructors.h:
(JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
* parser/Nodes.h:
(JSC::ExpressionNode::isBytecodeIntrinsicNode):
(JSC::BytecodeIntrinsicNode::type):
(JSC::BytecodeIntrinsicNode::emitter):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parsePrimaryExpression):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createResolve):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
* runtime/CommonIdentifiers.h:
(JSC::CommonIdentifiers::bytecodeIntrinsicRegistry): Deleted.
* runtime/IteratorPrototype.cpp:
(JSC::IteratorPrototype::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::bytecodeIntrinsicRegistry):
2016-02-02 Per Arne Vollan <peavo@outlook.com>
[B3][Win64] Compile fixes.
https://bugs.webkit.org/show_bug.cgi?id=153605
Reviewed by Filip Pizlo.
Fix remaining compile errors on Win64.
* CMakeLists.txt:
* b3/B3CFG.h:
(JSC::B3::CFG::newMap):
* ftl/FTLJITCode.h:
2016-02-01 Chris Dumez <cdumez@apple.com>
object.__lookupGetter__() / object.__lookupSetter__() does not work for native bindings
https://bugs.webkit.org/show_bug.cgi?id=153765
<rdar://problem/24439699>
Reviewed by Oliver Hunt.
Add support for CustomAccessor slots to objectProtoFuncLookupGetter() and
objectProtoFuncLookupSetter() by return getOwnPropertyDescriptor().get / set.
getOwnPropertyDescriptor() now correctly deals with CustomAccessors since
r196001.
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncLookupGetter):
(JSC::objectProtoFuncLookupSetter):
2016-02-01 Chris Dumez <cdumez@apple.com>
Native Bindings Descriptors are Incomplete
https://bugs.webkit.org/show_bug.cgi?id=140575
<rdar://problem/19506502>
Reviewed by Oliver Hunt.
This patch is based on initial work by Joe Pecoraro and Matthew Mirman.
This patch was initially rolled out for breaking chromeexperiments.com,
presumably because our IDL attributes were not marked as [configurable]
at the time. However, since r190104, our IDL attributes are now
configurable. Based on local testing, chromeexperiments.com seems to be
working fine now.
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/InjectedScriptSource.js:
(endsWith):
(InjectedScript.prototype.processProperties):
* runtime/JSBoundSlotBaseFunction.cpp: Added.
(JSC::boundSlotBaseFunctionCall):
(JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction):
(JSC::JSBoundSlotBaseFunction::create):
(JSC::JSBoundSlotBaseFunction::visitChildren):
(JSC::JSBoundSlotBaseFunction::finishCreation):
* runtime/JSBoundSlotBaseFunction.h: Added.
(JSC::JSBoundSlotBaseFunction::createStructure):
(JSC::JSBoundSlotBaseFunction::boundSlotBase):
(JSC::JSBoundSlotBaseFunction::customGetterSetter):
(JSC::JSBoundSlotBaseFunction::isSetter):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
* runtime/JSObject.cpp:
(JSC::getBoundSlotBaseFunctionForGetterSetter):
(JSC::JSObject::getOwnPropertyDescriptor):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2016-02-01 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: High Level Memory Overview Instrument
https://bugs.webkit.org/show_bug.cgi?id=153516
<rdar://problem/24356378>
Reviewed by Brian Burg.
* CMakeLists.txt:
* Configurations/FeatureDefines.xcconfig:
* DerivedSources.make:
* inspector/protocol/Memory.json: Added.
* inspector/scripts/codegen/generator.py:
New Memory domain guarded by ENABLE(RESOURCE_USAGE).
This feature flag was already used in WebCore.
2016-02-01 Benjamin Poulain <benjamin@webkit.org>
[JSC] IRC can coalesce the frame pointer with a Tmp that is modified
https://bugs.webkit.org/show_bug.cgi?id=153694
Reviewed by Filip Pizlo.
Let's say we have:
Move(FP, Tmp1)
Add64(#1, Tmp1)
If we were to coalesce the Move, we would modify the frame pointer.
Well, that's exactly what was happening with IRC.
Since the epilogue is not know to Air before IRC, the liveness analysis
never discovers that FP is live when Tmp1 is UseDef by Add64. Adding
FP would a be a problem anyway for a bunch of reasons.
I tried two ways to prevent IRC to override IRC:
1) Add an interference edge with FP for all non-duplication Defs.
2) Let coalesce() know about FP and constraint any coalescing with a re-Def.
The two are within margin of error for performance. The second one was considerably
more complicated. This patch implements the first one.
Some extra note:
-It is very important to not increment the degree of a Tmp when making it interfere
with FP. FP is not a valid color, it is not counted in the "K" colors considered
for coloring. Increasing the degree with the edge to FP would make every stage
pessimistic since there is an extra degree that can never be removed.
-I put "interferenceEdges" and "adjacencyList" in an inconsistent state.
This is intentional, "interferenceEdges" is used to test the existence of an edge,
"adjacencyList" is used to go over all the edges. In this case, we don't want
the edge with FP to be considered when pruning the graph.
* b3/air/AirIteratedRegisterCoalescing.cpp:
One branch could be transformed into an assertion: TmpLiveness is type specific now.
* b3/testb3.cpp:
(JSC::B3::testOverrideFramePointer):
(JSC::B3::run):
2016-02-01 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed speculative buildfix.
* dfg/DFGCommon.h: FTL_USES_B3 should be false if FTL JIT is disabled.
2016-01-31 Dan Bernstein <mitz@apple.com>
[Cocoa] Remove unused definition of HAVE_HEADER_DETECTION_H
https://bugs.webkit.org/show_bug.cgi?id=153729
Reviewed by Sam Weinig.
After r141700, HAVE_HEADER_DETECTION_H is no longer used.
* Configurations/Base.xcconfig:
2016-01-30 Filip Pizlo <fpizlo@apple.com>
B3->Air lowering should use MoveFloat more
https://bugs.webkit.org/show_bug.cgi?id=153714
Reviewed by Sam Weinig.
This is a very minor and benign bug. It just means that we will use the more canonical
MoveFloat instruction when moving floats, rather than using MoveDouble.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::relaxedMoveForType):
2016-01-31 Yusuke Suzuki <utatane.tea@gmail.com>
Should not predict OtherObj for ToThis with primitive types under strict mode
https://bugs.webkit.org/show_bug.cgi?id=153544
Reviewed by Filip Pizlo.
Currently, ToThis predicates OtherObj for primitive values.
But it's not true in strict mode.
In strict mode, ToThis does nothing on primitive values.
In this patch, we
1. fix prediction. Handles primitive types in strict mode. And we also handles StringObject.
2. convert it to Identity if the argument should be predicted as primitive types.
This optimization is important to implement Primitive.prototype.methods[1].
Otherwise, we always got BadType OSR exits.
[1]: https://bugs.webkit.org/show_bug.cgi?id=143889
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixupToThis):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* tests/stress/to-this-boolean.js: Added.
(Boolean.prototype.negate):
(Boolean.prototype.negate2):
* tests/stress/to-this-double.js: Added.
(Number.prototype.negate):
* tests/stress/to-this-int32.js: Added.
(Number.prototype.negate):
* tests/stress/to-this-int52.js: Added.
(Number.prototype.negate):
* tests/stress/to-this-number.js: Added.
(Number.prototype.negate):
* tests/stress/to-this-string.js: Added.
(String.prototype.prefix):
(String.prototype.first):
(String.prototype.second):
* tests/stress/to-this-symbol.js: Added.
(Symbol.prototype.identity):
(Symbol.prototype.identity2):
2016-01-31 Guillaume Emont <guijemont@igalia.com>
[mips] don't save to a callee saved register too early
https://bugs.webkit.org/show_bug.cgi?id=153463
If we save $gp to $s4 in pichdr, then in some cases, we were
overwriting $s4 before LLInt's pushCalleeSaves() is called (as pichdr
is at the very beginning of a function). Now we save $gp to $s4 at the
end of pushCalleeSaves().
Reviewed by Michael Saboff.
* offlineasm/mips.rb:
* llint/LowLevelInterpreter.asm:
Move the saving of $gp to $s4 from pichdr to pushCalleeSaves(). Take
the opportunity to only save $s4 as we never use the other callee
saved registers.
2016-01-30 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r195799 and r195828.
https://bugs.webkit.org/show_bug.cgi?id=153722
Caused assertion failures, severely affecting EWS (Requested
by ap on #webkit).
Reverted changesets:
"Web Inspector: InspectorTimelineAgent doesn't need to
recompile functions because it now uses the sampling profiler"
https://bugs.webkit.org/show_bug.cgi?id=153500
http://trac.webkit.org/changeset/195799
"Attempt to fix the Windows build after r195799"
http://trac.webkit.org/changeset/195828
2016-01-30 Yusuke Suzuki <utatane.tea@gmail.com>
[B3] JetStream/quicksort.c fails/hangs on Linux with GCC
https://bugs.webkit.org/show_bug.cgi?id=153647
Reviewed by Filip Pizlo.
In B3ComputeDivisionMagic, we accidentally perform sub, add operation onto signed integer. (In this case, int32_t)
But integer overflow is undefined behavior in C![1][2]
As a result, in GCC 4.9 release build, computeDivisionMagic(2) returns unexpected value.
`divisor = 2`
`d = 2`
`signedMin = INT32_MIN = -2147483647 (-0x7fffffff)`
`t = signedMin`
`anc = t - 1 - (t % ad)` Oops, we performed overflow operation!
So, `anc` value becomes undefined.
In this patch, we first cast all the operated values to unsigned one.
Reading the code, there are no operations that depends on signedness. (For example, we used aboveEqual like unsigned operations for comparison.)
[1]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
[2]: http://dl.acm.org/citation.cfm?id=2522728
* b3/B3ComputeDivisionMagic.h:
(JSC::B3::computeDivisionMagic):
* b3/testb3.cpp:
(JSC::B3::testComputeDivisionMagic):
(JSC::B3::run):
2016-01-30 Andreas Kling <akling@apple.com>
Shrink Heap::m_executables after cleaning it.
<https://webkit.org/b/153682>
Reviewed by Darin Adler.
The Heap::m_executables Vector was never shrunk down, despite sometimes
getting pretty huge (~500kB in my longest-running WebContent process.)
After GC has finished pruning unmarked Executables, shrink the Vector.
* heap/Heap.cpp:
(JSC::Heap::clearUnmarkedExecutables):
2016-01-29 Ada Chan <adachan@apple.com>
Enable VIDEO_PRESENTATION_MODE only in Debug and Release builds on Mac
https://bugs.webkit.org/show_bug.cgi?id=153665
Reviewed by Dan Bernstein.
* Configurations/FeatureDefines.xcconfig:
2016-01-30 Yusuke Suzuki <utatane.tea@gmail.com>
[B3] REGRESSION(r195882): Should break early after modConstant replaceWithNewValue succeeds
https://bugs.webkit.org/show_bug.cgi?id=153711
Reviewed by Filip Pizlo.
Should break after modConstant replaceWithNewValue succeeds. m_value is already replaced with Identity
if modConstant succeeds. So it does not have any children. m_value->child(1) breaks testb3.
* b3/B3ReduceStrength.cpp:
2016-01-30 Yusuke Suzuki <utatane.tea@gmail.com>
Enable SamplingProfiler on POSIX environment
https://bugs.webkit.org/show_bug.cgi?id=153584
Reviewed by Michael Saboff.
In this patch, we implement suspend and resume mechanizm for POSIX threads.
And with GLIBC, we can retrieve registers from it.
We take the following strategy.
Suspend side.
1. install sigaction to the threads.
2. in the profiler (suspend / resume callers), emit signal with pthread_kill and wait with POSIX semaphore.
3. in the signal handler, up the POSIX semaphore. Use sem_post because it is the async-signal-safe function in POSIX.
4. in the signal handler, perform sigsuspend to stop the thread until being resumed.
5. in the profiler, we can be waken up from the semaphore because (3) ups.
Resume side.
1. in the profiler, emit signal and wait on the semaphore.
2. in the signal handler, it is waken up from the sigsuspend.
3. in the signal handler, up the semaphore.
4. in the profiler, the profiler is waken up from the semaphore. It is ensured that the given thread is resumed by the signal.
* heap/MachineStackMarker.cpp:
(pthreadSignalHandlerSuspendResume):
(JSC::MachineThreads::Thread::Thread):
(JSC::MachineThreads::Thread::~Thread):
(JSC::MachineThreads::Thread::suspend):
(JSC::MachineThreads::Thread::resume):
(JSC::MachineThreads::Thread::getRegisters):
(JSC::MachineThreads::Thread::Registers::stackPointer):
(JSC::MachineThreads::Thread::Registers::framePointer):
(JSC::MachineThreads::Thread::Registers::instructionPointer):
(JSC::MachineThreads::Thread::Registers::llintPC):
(JSC::MachineThreads::Thread::freeRegisters):
* heap/MachineStackMarker.h:
* runtime/SamplingProfiler.cpp:
(JSC::reportStats):
* tests/stress/call-varargs-from-inlined-code-with-odd-number-of-arguments.js:
* tests/stress/call-varargs-from-inlined-code.js:
* tests/stress/v8-earley-boyer-strict.js:
2016-01-29 Filip Pizlo <fpizlo@apple.com>
B3 should reduce Mod(value, constant) to Div and Mul so that our Div optimizations can do things
https://bugs.webkit.org/show_bug.cgi?id=153693
Reviewed by Saam Barati.
The most efficient way to handle Mod(value, constant) is to reduce it to
Sub(value, Mul(Div(value, constant), constant)) and then let the Div optimizations do their
thing.
In the future we could add special handling of Mod(value, 1 << constant), but it's not
obvious that this would produce better code than reducing through Div, if we also make sure
that we have great optimizations for Mul and Div.
* b3/B3ReduceStrength.cpp:
2016-01-29 Keith Miller <keith_miller@apple.com>
Array.prototype native functions should use Symbol.species to construct the result
https://bugs.webkit.org/show_bug.cgi?id=153660
Reviewed by Saam Barati.
This patch adds support for Symbol.species in the Array.prototype native functions.
We make an optimization to avoid regressions on some benchmarks by using an
adaptive watchpoint to check if Array.prototype.constructor is ever changed.
* runtime/ArrayPrototype.cpp:
(JSC::putLength):
(JSC::setLength):
(JSC::speciesConstructArray):
(JSC::arrayProtoFuncConcat):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
(JSC::ArrayPrototype::setConstructor):
(JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint):
(JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
* runtime/ArrayPrototype.h:
(JSC::ArrayPrototype::didChangeConstructorProperty):
* runtime/ConstructData.cpp:
(JSC::construct):
* runtime/ConstructData.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* tests/es6.yaml:
* tests/stress/array-species-functions.js: Added.
(Symbol.species):
(funcThrows):
(test.species):
(test):
2016-01-29 Filip Pizlo <fpizlo@apple.com>
CallLinkStatus should trust BadCell exit sites whenever there is no stub
https://bugs.webkit.org/show_bug.cgi?id=153691
Reviewed by Benjamin Poulain.
This fixes a regression in our treatment of inlining failure exit sites when deciding if we
should inline a call.
A long time ago, a BadCell exit site would ensure that a CallLinkStatus returned
takesSlowPath.
But then we added closure calls. A BadCell exit site might just mean that we should do
closure call inlining. We added a BadExecutable exit site to indicate that even closure call
inlining had failed. BadCell would no longer force CallLinkStatus to return takesSlowPath,
but BadExecutable would stuff do so.
But then we unified the IR for checking functions and executables, and the DFG stopped using
the BadExecutable exit kind. Probably this change disabled our ability to use exit site
counting for deciding when to takesSlowPath. But this isn't necessarily a disaster, since
any time you exited in this way, you'd be taken to a baseline call inline cache, and that
inline cache would record the slow path.
But then we introduced polymorphic call inlining. Polymorphic call inlining means that call
unlinking, like when one of the callees is optimized, will reset the stub. We also made it
so that the stub is like a gate for the slow path count. A clear inline cache must first
cause the creation of a stub and then cause it to overflow before the slow path is counted.
So, if the DFG or FTL exits on a cell check associated with a particular callsite being
speculatively inlined, then it's possible that nobody will know about the exit because:
- The exit kind is BadCell but CallLinkStatus needs BadExecutable to disable inlining.
- Between when we tiered up to the DFG (or FTL) and when the exit happened, one of the
callees was tiered up, causing the baseline CallLinkInfo to be unlinked. Therefore, after
the exit, the inline cache is in a reset state and will not count the call as taking slow
path.
The challenge when dealing with this is that often, we will have an super early compilation
of a minimorphic call site before we have seen all of its small set of callees. For example
we may have seen only one of two possible callees. That early compilation will OSR exit, and
in trunk, will be recompiled with bimorphic speculative inlining. That's a pretty good
outcome. Basically, we are trusting that if during the time that the function has been
running prior to a given compilation, a callsite has only seen a small number of callees,
then it's safe to assume that it won't see another one anytime soon.
So, simply forcing the CallLinkStatus to set takesSlowPath any time there was a BadCell exit
would hurt our performance in some cases, because trunk prior to this change would have their
final compilation use speculative inlining, and this change would make guarded inlining
instead.
The compromise that I came up with relies on the fact that a CallLinkInfo must be reset quite
frequently for it to routinely happen in between tier-up to DFG (or FTL) and an exit. So,
most likely, such a CallLinkInfo will also show up as being clear when the CallLinkStatus
is built during DFG profiling. The CallLinkStatus will then fall back on the CallLinkInfo's
lastSeenCallee field, which is persistent across resets. This change just makes it so that
CallLinkStatus sets takesSlowPath if there is a BadCell exit and the status had to be
inferred from the lastSeenCallee.
This change reduces pointless recompilations in gbemu. It's an 11% speed-up on gbemu. It
doesn't seem to hurt any benchmarks.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
(JSC::CallLinkStatus::computeExitSiteData):
(JSC::CallLinkStatus::computeFromCallLinkInfo):
* bytecode/CallLinkStatus.h:
(JSC::CallLinkStatus::CallLinkStatus):
(JSC::CallLinkStatus::at):
(JSC::CallLinkStatus::operator[]):
(JSC::CallLinkStatus::isProved):
(JSC::CallLinkStatus::isBasedOnStub):
(JSC::CallLinkStatus::canOptimize):
(JSC::CallLinkStatus::maxNumArguments):
(JSC::CallLinkStatus::ExitSiteData::ExitSiteData): Deleted.
2016-01-29 Saam barati <sbarati@apple.com>
Pack FunctionExecutable and UnlinkedFunctionExecutable harder
https://bugs.webkit.org/show_bug.cgi?id=153687
Reviewed by Andreas Kling.
This patch reduces FunctionExecutable from 120 to 104 bytes.
This patch reduces UnlinkedFunctionExecutable from 144 to 136 bytes.
* bytecode/ExecutableInfo.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/ParserModes.h:
(JSC::functionNameScopeIsDynamic):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
* runtime/Executable.h:
(JSC::ScriptExecutable::needsActivation):
(JSC::ScriptExecutable::isArrowFunctionContext):
(JSC::ScriptExecutable::isStrictMode):
(JSC::ScriptExecutable::derivedContextType):
(JSC::ScriptExecutable::ecmaMode):
(JSC::ScriptExecutable::finishCreation):
2016-01-29 Saam barati <sbarati@apple.com>
JSC Sampling Profiler: Come up with a (program counter => CodeOrigin) mapping
https://bugs.webkit.org/show_bug.cgi?id=152629
Reviewed by Filip Pizlo.
This patch implements a mapping from PC to CodeOrigin
that lives off of JITed CodeBlocks. We build this mapping
while JITing code, and then we compress it and store
it on the CodeBlock. We only build the mapping if a debugger
has ever been attached to any global object.
CodeBlock consults this mapping when searching for a CodeOrigin
for a given PC, but it also consults other code ranges
off the main path that may own the PC. Specifically, it searches
through inline caches, OSRExits, and LazySlowPaths.
To find PC info for the LLInt, we also save the LLInt pc when
taking a stack trace where the top frame is in LLInt code.
This patch also cleans up code inside the SamplingProfier.
I realized a bug in the SamplingProfiler's implementation.
We used to walk the inline stack while gathering a stack
trace. This is wrong. It's super dangerous to do this because
we might pause the JSC process while it's modifying its
CodeOrigin table. We used to walk the inline stack while
taking a stack trace because doing so could save us from
having to verify a particular stack trace. This patch changes that.
We now have to verify all stack traces taken. This verification step
includes walking the inline stack.
Because we have a PC=>CodeOrigin map, we can now gather more
detailed information about the top-frame we pause. This allows
us to correctly observe inlining. It also allows us to observe
expression-level line/column information for the top frame.
The reason we don't consult this mapping for parent frames is
that all parent frames should set the CallSiteIndex on the call
frame header, which means we can consult that value to get inlining
and expression-level line/column information.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::Label::Label):
(JSC::AbstractMacroAssembler::Label::operator==):
(JSC::AbstractMacroAssembler::Label::isSet):
* assembler/AssemblerBuffer.h:
(JSC::AssemblerLabel::labelAtOffset):
(JSC::AssemblerLabel::operator==):
* b3/B3Generate.cpp:
* b3/B3Origin.h:
(JSC::B3::Origin::data):
(JSC::B3::Origin::operator==):
* b3/B3PCToOriginMap.h: Added.
(JSC::B3::PCToOriginMap::PCToOriginMap):
(JSC::B3::PCToOriginMap::appendItem):
(JSC::B3::PCToOriginMap::ranges):
* b3/B3Procedure.h:
(JSC::B3::Procedure::pcToOriginMap):
(JSC::B3::Procedure::releasePCToOriginMap):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
(JSC::CodeBlock::setPCToCodeOriginMap):
(JSC::CodeBlock::findPC):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::jitCodeMap):
(JSC::CodeBlock::bytecodeOffset):
* bytecode/CodeOrigin.h:
(JSC::CodeOrigin::operator==):
(JSC::CodeOriginHash::hash):
(JSC::CodeOriginHash::equal):
* bytecode/InlineCallFrame.h:
(JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
(JSC::CodeOrigin::walkUpInlineStack):
* bytecode/PolymorphicAccess.h:
(JSC::PolymorphicAccess::containsPC):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::visitWeakReferences):
(JSC::StructureStubInfo::containsPC):
* bytecode/StructureStubInfo.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::hasExpressionInfo):
(JSC::UnlinkedCodeBlock::expressionInfo):
(JSC::UnlinkedCodeBlock::setThisRegister):
* debugger/Debugger.cpp:
(JSC::Debugger::attach):
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::validateReferences):
(JSC::DFG::JITCode::findPC):
* dfg/DFGJITCode.h:
(JSC::DFG::JITCode::commonDataOffset):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
(JSC::DFG::JITCompiler::setEndOfMainPath):
(JSC::DFG::JITCompiler::setEndOfCode):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::setStartOfCode):
(JSC::DFG::JITCompiler::setForNode):
(JSC::DFG::JITCompiler::addCallSite):
(JSC::DFG::JITCompiler::pcToCodeOriginMapBuilder):
(JSC::DFG::JITCompiler::setEndOfMainPath): Deleted.
(JSC::DFG::JITCompiler::setEndOfCode): Deleted.
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::SlowPathGenerator::call):
(JSC::DFG::SlowPathGenerator::origin):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
(JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
* dfg/DFGSpeculativeJIT.h:
* ftl/FTLB3Compile.cpp:
(JSC::FTL::compile):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
(JSC::FTL::JITCode::findPC):
* ftl/FTLJITCode.h:
(JSC::FTL::JITCode::b3Code):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::Thread::Registers::instructionPointer):
(JSC::MachineThreads::Thread::Registers::llintPC):
(JSC::MachineThreads::Thread::freeRegisters):
* heap/MachineStackMarker.h:
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::addEvent):
(Inspector::buildSamples):
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::privateCompile):
* jit/JIT.h:
* jit/JITCode.h:
(JSC::JITCode::findPC):
* jit/PCToCodeOriginMap.cpp: Added.
(JSC::PCToCodeOriginMapBuilder::PCToCodeOriginMapBuilder):
(JSC::PCToCodeOriginMapBuilder::appendItem):
(JSC::PCToCodeOriginMap::PCToCodeOriginMap):
(JSC::PCToCodeOriginMap::~PCToCodeOriginMap):
(JSC::PCToCodeOriginMap::memorySize):
(JSC::PCToCodeOriginMap::findPC):
* jit/PCToCodeOriginMap.h: Added.
(JSC::PCToCodeOriginMapBuilder::defaultCodeOrigin):
(JSC::PCToCodeOriginMapBuilder::didBuildMapping):
* jsc.cpp:
(functionSamplingProfilerStackTraces):
* llint/LLIntPCRanges.h:
(JSC::LLInt::isLLIntPC):
* llint/LowLevelInterpreter.asm:
* runtime/Options.h:
* runtime/SamplingProfiler.cpp:
(JSC::reportStats):
(JSC::FrameWalker::FrameWalker):
(JSC::FrameWalker::walk):
(JSC::FrameWalker::resetAtMachineFrame):
(JSC::FrameWalker::isValidFramePointer):
(JSC::SamplingProfiler::SamplingProfiler):
(JSC::SamplingProfiler::~SamplingProfiler):
(JSC::tryGetBytecodeIndex):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::visit):
(JSC::SamplingProfiler::noticeVMEntry):
(JSC::SamplingProfiler::clearData):
(JSC::SamplingProfiler::StackFrame::displayName):
(JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
(JSC::SamplingProfiler::StackFrame::functionStartLine):
(JSC::SamplingProfiler::StackFrame::functionStartColumn):
(JSC::SamplingProfiler::StackFrame::sourceID):
(JSC::SamplingProfiler::StackFrame::url):
(JSC::SamplingProfiler::releaseStackTraces):
(JSC::SamplingProfiler::stackTracesAsJSON):
(WTF::printInternal):
(JSC::SamplingProfiler::StackFrame::startLine): Deleted.
(JSC::SamplingProfiler::StackFrame::startColumn): Deleted.
(JSC::SamplingProfiler::stackTraces): Deleted.
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
(JSC::SamplingProfiler::StackFrame::StackFrame):
(JSC::SamplingProfiler::StackTrace::StackTrace):
(JSC::SamplingProfiler::totalTime):
(JSC::SamplingProfiler::setStopWatch):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::setShouldBuildPCToCodeOriginMapping):
(JSC::VM::shouldBuilderPCToCodeOriginMapping):
* tests/stress/sampling-profiler-basic.js:
(platformSupportsSamplingProfiler.top):
(platformSupportsSamplingProfiler.jaz):
(platformSupportsSamplingProfiler.kaz):
2016-01-29 Saam barati <sbarati@apple.com>
Remove our notion of having a single activation register
https://bugs.webkit.org/show_bug.cgi?id=153673
Reviewed by Filip Pizlo.
We have many functions lurking around where we think a function
might only have one activation register. This is clearly wrong
now that ES6 has block scoping. This patch removes this false notion.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::scopeRegister):
(JSC::CodeBlock::codeType):
(JSC::CodeBlock::setActivationRegister): Deleted.
(JSC::CodeBlock::activationRegister): Deleted.
(JSC::CodeBlock::uncheckedActivationRegister): Deleted.
(JSC::CodeBlock::needsActivation): Deleted.
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::usesEval):
(JSC::ExecutableInfo::isStrictMode):
(JSC::ExecutableInfo::isConstructor):
(JSC::ExecutableInfo::isClassContext):
(JSC::ExecutableInfo::needsActivation): Deleted.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::isArrowFunctionContext):
(JSC::UnlinkedCodeBlock::isClassContext):
(JSC::UnlinkedCodeBlock::setThisRegister):
(JSC::UnlinkedCodeBlock::setScopeRegister):
(JSC::UnlinkedCodeBlock::usesGlobalObject):
(JSC::UnlinkedCodeBlock::setGlobalObjectRegister):
(JSC::UnlinkedCodeBlock::thisRegister):
(JSC::UnlinkedCodeBlock::scopeRegister):
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction):
(JSC::UnlinkedCodeBlock::needsFullScopeChain): Deleted.
(JSC::UnlinkedCodeBlock::setActivationRegister): Deleted.
(JSC::UnlinkedCodeBlock::activationRegister): Deleted.
(JSC::UnlinkedCodeBlock::hasActivationRegister): Deleted.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::destinationForAssignResult):
(JSC::BytecodeGenerator::leftHandSideNeedsCopy):
(JSC::BytecodeGenerator::emitNodeForLeftHandSide):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::hasExitSite):
(JSC::DFG::Graph::activationRegister): Deleted.
(JSC::DFG::Graph::uncheckedActivationRegister): Deleted.
(JSC::DFG::Graph::machineActivationRegister): Deleted.
(JSC::DFG::Graph::uncheckedMachineActivationRegister): Deleted.
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::callSiteIndex):
(JSC::CallFrame::stack):
(JSC::CallFrame::callerFrame):
(JSC::CallFrame::friendlyFunctionName):
(JSC::CallFrame::hasActivation): Deleted.
(JSC::CallFrame::uncheckedActivation): Deleted.
(JSC::CallFrame::lexicalEnvironment): Deleted.
(JSC::CallFrame::lexicalEnvironmentOrNullptr): Deleted.
(JSC::CallFrame::setActivation): Deleted.
* interpreter/CallFrame.h:
(JSC::ExecState::scope):
(JSC::ExecState::setCallerFrame):
(JSC::ExecState::setScope):
(JSC::ExecState::init):
* interpreter/Register.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Executable.h:
(JSC::ScriptExecutable::usesEval):
(JSC::ScriptExecutable::usesArguments):
(JSC::ScriptExecutable::isArrowFunctionContext):
(JSC::ScriptExecutable::isStrictMode):
(JSC::ScriptExecutable::derivedContextType):
(JSC::ScriptExecutable::needsActivation): Deleted.
* runtime/JSLexicalEnvironment.h:
(JSC::asActivation):
(JSC::Register::lexicalEnvironment): Deleted.
2016-01-29 Filip Pizlo <fpizlo@apple.com>
Air:fixObviousSpills should handle floats and doubles
https://bugs.webkit.org/show_bug.cgi?id=153197
Reviewed by Saam Barati.
This adds the most obvious handling of float spills, where we just enable load elimination on
float spill code.
* b3/air/AirFixObviousSpills.cpp:
2016-01-29 Andreas Kling <akling@apple.com>
Shrink CodeBlock!
<https://webkit.org/b/153640>
Reviewed by Saam Barati.
Shrink CodeBlock by 112 bytes (from 640 to 528) by employing
these sophisticated tricks:
- Remove members that are not used by anyone.
- Don't cache both VM* and Heap* in members.
- Reorder members to minimize struct padding.
- Use RefCountedArray instead of Vector for arrays that never resize.
- Put a not-always-present HashMap in a std::unique_ptr.
This increases CodeBlock space efficiency by 20%, as we can now
fit 30 of them in a MarkedBlock, up from 25.)
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setNumParameters):
(JSC::CodeBlock::jettison):
(JSC::CodeBlock::noticeIncomingCall):
(JSC::CodeBlock::resultProfileForBytecodeOffset):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::capabilityLevelState):
(JSC::CodeBlock::codeType):
(JSC::CodeBlock::ensureResultProfile):
(JSC::CodeBlock::heap):
2016-01-29 Saam barati <sbarati@apple.com>
Exits from exceptions shouldn't jettison code
https://bugs.webkit.org/show_bug.cgi?id=153564
Reviewed by Geoffrey Garen.
We create two new exit kinds for exception-handling
OSRExits:
- ExceptionCheck: an exception check after a C call.
- GenericUnwind: an OSR exit executes because it's jumped to from genericUnwind machinery.
Having these two new exit kinds allows us to remove fields from
various OSRExit variants that store booleans indicating
if the exit is an exception handler, and if so, what kind
of exception handler. Most of this patch is just removing
those old fields and adding new equivalent functions.
This patch also implements the policy that we should never consider jettisoning
code from exits that happen from an exception check to an op_catch (it might be worth
considering a similar policy for 'throw'). We're choosing this policy because
it will almost never be more expensive, in total, to execute the OSR exit than
to execute the baseline variant of the code. When an exception is thrown, we do
really expensive work, like call through to genericUnwind, and also create an error
object with a stack trace. The cost of OSR exiting here is small in comparison to
those other operations. And penalizing a CodeBlock for OSR exiting from an exception
is silly because the basis of our implementation of exception handling in the
upper tiers is to OSR exit on a caught exception. So we used to penalize
ourselves for having an implementation that is correct w.r.t our design goals.
I've verified this hypothesis with on v8-raytrace by adding a new
benchmark that throws with very high frequency. Implementing
this policy on that benchmark results in about a 4-5% speed up.
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
(JSC::exitKindMayJettison):
(JSC::exitKindIsCountable): Deleted.
* bytecode/ExitKind.h:
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::noticeOSREntry):
(JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
(JSC::DFG::JITCompiler::exceptionCheck):
(JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
* dfg/DFGJITCompiler.h:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
* dfg/DFGOSRExit.h:
(JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::OSRExitBase):
(JSC::DFG::OSRExitBase::isExceptionHandler):
(JSC::DFG::OSRExitBase::isGenericUnwindHandler):
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::handleExitCounts):
(JSC::DFG::osrWriteBarrier):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitCompilerCommon.h:
(JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExitThunkGenerator.cpp:
(JSC::FTL::ExitThunkGenerator::emitThunk):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::emitOSRExit):
(JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
(JSC::FTL::OSRExit::OSRExit):
(JSC::FTL::OSRExit::spillRegistersToSpillSlot):
(JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
(JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
(JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
(JSC::FTL::exceptionTypeWillArriveAtOSRExitFromGenericUnwind): Deleted.
(JSC::FTL::OSRExit::willArriveAtOSRExitFromGenericUnwind): Deleted.
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLPatchpointExceptionHandle.cpp:
(JSC::FTL::PatchpointExceptionHandle::scheduleExitCreation):
(JSC::FTL::PatchpointExceptionHandle::scheduleExitCreationForUnwind):
(JSC::FTL::PatchpointExceptionHandle::PatchpointExceptionHandle):
(JSC::FTL::PatchpointExceptionHandle::createHandle):
* ftl/FTLPatchpointExceptionHandle.h:
2016-01-28 Yusuke Suzuki <utatane.tea@gmail.com>
[B3] REGRESSION(r195395): testComplex(64, 128) asserts on Linux with GCC
https://bugs.webkit.org/show_bug.cgi?id=153422
Reviewed by Filip Pizlo.
Previously proc.values() returns ValuesCollection (Not reference!).
values.values takes const ValueCollection&.
And later it produces IndexSet<Value>::Iterable<Procedure::ValuesCollection>,
it holds const ValueCollection& as its member.
But IndexSet<Value>::Iterable<Procedure::ValuesCollection> is just an instance.
So after creating this, the lifetime of the ValueCollection const reference finished.
To fix that, we hold ValuesCollection as a member of Procedure.
And change the signature to const ValuesCollection& Procedure::values().
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::Procedure):
* b3/B3Procedure.h:
(JSC::B3::Procedure::values):
2016-01-28 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: InspectorTimelineAgent doesn't need to recompile functions because it now uses the sampling profiler
https://bugs.webkit.org/show_bug.cgi?id=153500
<rdar://problem/24352458>
Reviewed by Timothy Hatcher.
Be more explicit about enabling legacy profiling.
* jsc.cpp:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::hasLegacyProfiler):
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
(JSC::JSGlobalObject::createModuleProgramCodeBlock):
(JSC::JSGlobalObject::hasProfiler): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::supportsLegacyProfiling):
(JSC::JSGlobalObject::supportsProfiling): Deleted.
2016-01-28 Yusuke Suzuki <utatane.tea@gmail.com>
Fix the B3 build with GCC 4.9.3
https://bugs.webkit.org/show_bug.cgi?id=151624
Reviewed by Filip Pizlo.
Due to GCC 4.9's compiler issue[1], method calls inside (2 or so) nested lambdas need to use `this` to avoid internal compiler errors.
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272
* b3/air/AirIteratedRegisterCoalescing.cpp:
2016-01-28 Filip Pizlo <fpizlo@apple.com>
LowerToAir::preferRightForResult() should resolve use count ties by selecting the child that is closest in an idom walk
https://bugs.webkit.org/show_bug.cgi?id=153583
Reviewed by Benjamin Poulain.
This undoes the AsmBench/n-body regression in r195654 while preserving that revision's
Kraken progression.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::LowerToAir):
(JSC::B3::Air::LowerToAir::preferRightForResult):
2016-01-28 Benjamin Poulain <bpoulain@apple.com>
[JSC] B3 Tail Call with Varargs do not restore callee saved registers
https://bugs.webkit.org/show_bug.cgi?id=153579
Reviewed by Michael Saboff.
We were trashing the callee saved registers in Tail Calls.
I just copied the code from DFG to fix this :)
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
2016-01-27 Filip Pizlo <fpizlo@apple.com>
B3 IntRange analysis should know more about shifting
https://bugs.webkit.org/show_bug.cgi?id=153568
Reviewed by Benjamin Poulain.
This teaches the IntRange analysis that the result of a right shift is usually better than
the worst-case mask based on the shift amount. In fact, you can reach useful conclusions
from looking at the IntRange of the input. This helps because Octane/crypto does something
like:
CheckMul((@x & $268435455) >> 14, @y >> 14, ...)
If you consider just the shifts, then this may overflow. But if you consider that @x is
first masked, then the IntRange coming out of the first shift is tight enough to prove that
the CheckMul cannot overflow.
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
2016-01-27 Benjamin Poulain <bpoulain@apple.com>
[JSC] adjustFrameAndStackInOSRExitCompilerThunk() can trash values in FTL
https://bugs.webkit.org/show_bug.cgi?id=153536
Reviewed by Saam Barati.
Workaround to get B3 working on ARM.
* dfg/DFGOSRExitCompilerCommon.h:
(JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
The code was using the scratch registers in a few places.
I initially tried to make is not use scratch registers anywhere
but that looked super fragile.
Instead, I just preserve the scratch registers. That's easy and
it should be relatively cheap compared to everything done on OSR Exits.
2016-01-27 Konstantin Tokarev <annulen@yandex.ru>
[mips] Use reinterpret_cast_ptr to suppress alignment warnings.
https://bugs.webkit.org/show_bug.cgi?id=153424
Reviewed by Darin Adler.
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::sortFloat):
2016-01-27 Per Arne Vollan <peavo@outlook.com>
[FTL][Win64] Compile fix.
https://bugs.webkit.org/show_bug.cgi?id=153555
Reviewed by Alex Christensen.
MSVC does not accept preprocessor conditionals in macros.
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
2016-01-27 Filip Pizlo <fpizlo@apple.com>
Air::TmpWidth uses a stale pointer into its HashMap after it calls add()
https://bugs.webkit.org/show_bug.cgi?id=153546
Reviewed by Saam Barati.
* b3/air/AirTmpWidth.cpp:
(JSC::B3::Air::TmpWidth::recompute):
2016-01-27 Alexey Proskuryakov <ap@apple.com>
Remove ENABLE_CURRENTSRC
https://bugs.webkit.org/show_bug.cgi?id=153545
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2016-01-26 Benjamin Poulain <benjamin@webkit.org>
[JSC] When lowering B3 to Air, preferRightForResult() should prefer values from the same block
https://bugs.webkit.org/show_bug.cgi?id=153477
Reviewed by Filip Pizlo.
In cases like this:
Block #0
@1 = something
@2 = Jump #1
Block #1
@3 = something else
@4 = Add(@3, @1)
...
@42 = Branch(@x, #1, #2)
B3LowerToAir would pick @1 for the argument copied
for what goes into the UseDef side of Add.
This created a bunch of moves that could never be coalesced.
In Kraken's imaging-desaturate, there were enough Moves to slow
down the hot loop.
Ideally, we should not use UseCount for lowering. We should use
the real liveness for preferRightForResult(), and a loop-weighted
use-count for effective addresses. The problem is keeping the cost
low for those simple helpers.
In this patch, I went with a simple heuristic: prioritize the value
defined in the same block for UseDef.
There is one other way that would be cheap but a bit invasive:
-Get rid of UseDef.
-Make every ops, 3 operands.
-Tell the register allocator to attempt aliasing of the 2 uses
with the def.
-If the allocator fails, just add a move as needed.
For now, the simple heuristic seems okay for the cases have.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::preferRightForResult):
2016-01-26 Filip Pizlo <fpizlo@apple.com>
Tail duplication should break critical edges first
https://bugs.webkit.org/show_bug.cgi?id=153530
Reviewed by Benjamin Poulain.
This speeds up Octane/boyer.
* b3/B3DuplicateTails.cpp:
2016-01-26 Joseph Pecoraro <pecoraro@apple.com>
Generalize ResourceUsageData gathering to be used outside of ResourceUsageOverlay
https://bugs.webkit.org/show_bug.cgi?id=153509
<rdar://problem/24354291>
Reviewed by Andreas Kling.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::didAllocateBlock):
(JSC::Heap::didFreeBlock):
Rename the ENABLE flag.
2016-01-26 Csaba Osztrogonác <ossy@webkit.org>
[B3] Fix control reaches end of non-void function GCC warning after r195139
https://bugs.webkit.org/show_bug.cgi?id=153426
Reviewed by Michael Catanzaro.
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::cooled):
2016-01-26 Saam barati <sbarati@apple.com>
testb3 and testAir should be compiled under -O0
https://bugs.webkit.org/show_bug.cgi?id=153520
Reviewed by Benjamin Poulain.
* JavaScriptCore.xcodeproj/project.pbxproj:
2016-01-26 Filip Pizlo <fpizlo@apple.com>
B3's integer range analysis should know that Mul'ing two sufficiently small numbers will yield a number that still has a meaningful range
https://bugs.webkit.org/show_bug.cgi?id=153518
Reviewed by Benjamin Poulain.
Octane/encrypt had an addition overflow check that can be proved away by being sufficiently
sneaky about the analysis of adds, multiplies, and shifts.
I almost added these optimizations to the DFG integer range optimization phase. That phase is
very complicated. B3's integer range analysis is trivial. So I added it to B3. Eventually
we'll want this same machinery in the DFG also.
8% speed-up on Octane/encrypt.
* b3/B3ReduceStrength.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::dump): Dumping a constant value's name now dumps its value. This makes a huge difference for reading IR.
(JSC::B3::Value::cloneImpl):
(JSC::B3::Value::deepDump):
2016-01-26 Filip Pizlo <fpizlo@apple.com>
It should be possible to disable FTL for a range like we disable DFG for a range
https://bugs.webkit.org/show_bug.cgi?id=153511
Reviewed by Geoffrey Garen.
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* runtime/Options.h:
2016-01-26 Filip Pizlo <fpizlo@apple.com>
Shifts by an amount computed using BitAnd with a mask that subsumes the shift's own mask should be rewired around the BitAnd
https://bugs.webkit.org/show_bug.cgi?id=153505
Reviewed by Saam Barati.
Turn this: Shl(@x, BitAnd(@y, 63))
Into this: Shl(@x, @y)
It matters for Octane/crypto.
We should also stop FTL from generating such code, but even if we did that, we'd still want
this optimization in case user code did the BitAnd.
Also we can't stop the FTL from generating such code yet, because when targetting LLVM, you
must mask your shifts this way.
* b3/B3ReduceStrength.cpp:
2016-01-26 Filip Pizlo <fpizlo@apple.com>
The thing that B3 uses to describe a stack slot should not be a Value
https://bugs.webkit.org/show_bug.cgi?id=153491
rdar://problem/24349446
Reviewed by Geoffrey Garen and Saam Barati.
Prior to this change, B3 represented stack slots by having a StackSlotValue that carried
two meanings:
- It represented a stack slot.
- It was a kind of Value for getting the base of the stack slot.
This seems like a good idea until you consider the following issues.
1) A Value can be killed if it is on an unreachable path, or if it has no effects and
nobody refers to it. But the FTL uses StackSlotValue to allocate space on the stack.
When it does this, it doesn't want it to be killed. It will dereference the object, so
killing it is a bug.
2) A premise of B3 is that it should be always legal to perform the following
transformation on a value:
value->replaceWithIdentity(insertionSet.insertValue(index, proc.clone(value)));
This inserts a new value just before the old one. The new value is a clone of the old
one. Then the old one is essentially deleted (anything that becomes an identity dies
shortly thereafter). Problem (1) prevents this from being legal, which breaks a major
premise of B3 IR.
3) A premise of B3 is that it should be always legal to perform the following
transformation on a value:
Before:
@42 = Thing(...)
After:
Branch(@doesntMatter, #yes, #no)
BB#yes:
@42_one = Thing(...)
Upsilon(@42_one, ^42)
Jump(#done)
BB#no:
@42_two = Thing(...)
Upsilon(@42_two, ^42)
Jump(#done)
BB#done:
@42 = Phi()
But prior to this change, such a transformation makes absolutely no sense for
StackSlot. It will "work" in the sense that the compiler will proceed undaunted, but
it will disable SSA fix-up for the cloned stack slot and we will end up allocating two
stack slots instead of one, and then we will assume that they both escape, which will
disable efficient stack allocation. Note that the moral equivalent of this
transformation could already happen due to tail duplication, and the only reason why
it's not a bug right now is that we happen to hoist stack slots to the root block. But
the whole point of our stack slots was supposed to be that they do not have to be
hoisted.
This change fixes this issue by splitting StackSlotValue into two things: SlotBaseValue,
which is a pure operation for getting the base address of a StackSlot, and StackSlot,
which is a representation of the actual stack slot. StackSlot cannot get duplicated and
can only be killed if it's anonymous. SlotBaseValue can be killed, moved, cloned,
hoisted, etc. Since it has no effects and it has a ValueKey, it's one of the most
permissive Values in the IR, just as one would hope (after all, there is actually zero
code that needs to execute to evaluate SlotBaseValue).
This fixes a crash that we saw with GuardMalloc and ASan. It also makes the IR a lot more
easy to reason about.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3EliminateCommonSubexpressions.cpp:
* b3/B3FixSSA.cpp:
(JSC::B3::demoteValues):
(JSC::B3::fixSSA):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::setBlockOrderImpl):
(JSC::B3::Procedure::addStackSlot):
(JSC::B3::Procedure::addAnonymousStackSlot):
(JSC::B3::Procedure::clone):
(JSC::B3::Procedure::dump):
(JSC::B3::Procedure::blocksInPostOrder):
(JSC::B3::Procedure::deleteStackSlot):
(JSC::B3::Procedure::deleteValue):
(JSC::B3::Procedure::calleeSaveRegisters):
(JSC::B3::Procedure::addStackSlotIndex):
(JSC::B3::Procedure::addValueIndex):
* b3/B3Procedure.h:
(JSC::B3::Procedure::setBlockOrder):
(JSC::B3::Procedure::StackSlotsCollection::StackSlotsCollection):
(JSC::B3::Procedure::StackSlotsCollection::size):
(JSC::B3::Procedure::StackSlotsCollection::at):
(JSC::B3::Procedure::StackSlotsCollection::operator[]):
(JSC::B3::Procedure::StackSlotsCollection::iterator::iterator):
(JSC::B3::Procedure::StackSlotsCollection::iterator::operator*):
(JSC::B3::Procedure::StackSlotsCollection::iterator::operator++):
(JSC::B3::Procedure::StackSlotsCollection::iterator::operator==):
(JSC::B3::Procedure::StackSlotsCollection::iterator::operator!=):
(JSC::B3::Procedure::StackSlotsCollection::iterator::findNext):
(JSC::B3::Procedure::StackSlotsCollection::begin):
(JSC::B3::Procedure::StackSlotsCollection::end):
(JSC::B3::Procedure::stackSlots):
(JSC::B3::Procedure::ValuesCollection::ValuesCollection):
* b3/B3ReduceStrength.cpp:
* b3/B3SlotBaseValue.cpp: Copied from Source/JavaScriptCore/b3/B3StackSlotValue.cpp.
(JSC::B3::SlotBaseValue::~SlotBaseValue):
(JSC::B3::SlotBaseValue::dumpMeta):
(JSC::B3::SlotBaseValue::cloneImpl):
(JSC::B3::StackSlotValue::~StackSlotValue): Deleted.
(JSC::B3::StackSlotValue::dumpMeta): Deleted.
(JSC::B3::StackSlotValue::cloneImpl): Deleted.
* b3/B3SlotBaseValue.h: Copied from Source/JavaScriptCore/b3/B3StackSlotValue.h.
* b3/B3StackSlot.cpp: Added.
(JSC::B3::StackSlot::~StackSlot):
(JSC::B3::StackSlot::dump):
(JSC::B3::StackSlot::deepDump):
(JSC::B3::StackSlot::StackSlot):
* b3/B3StackSlot.h: Added.
(JSC::B3::StackSlot::byteSize):
(JSC::B3::StackSlot::kind):
(JSC::B3::StackSlot::isLocked):
(JSC::B3::StackSlot::index):
(JSC::B3::StackSlot::offsetFromFP):
(JSC::B3::StackSlot::setOffsetFromFP):
(JSC::B3::DeepStackSlotDump::DeepStackSlotDump):
(JSC::B3::DeepStackSlotDump::dump):
(JSC::B3::deepDump):
* b3/B3StackSlotValue.cpp: Removed.
* b3/B3StackSlotValue.h: Removed.
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::checkOpcode):
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::materialize):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::addBlock):
(JSC::B3::Air::Code::addStackSlot):
(JSC::B3::Air::Code::addSpecial):
* b3/air/AirCode.h:
* b3/air/AirStackSlot.cpp:
(JSC::B3::Air::StackSlot::setOffsetFromFP):
(JSC::B3::Air::StackSlot::dump):
(JSC::B3::Air::StackSlot::deepDump):
(JSC::B3::Air::StackSlot::StackSlot):
* b3/air/AirStackSlot.h:
(JSC::B3::Air::StackSlot::alignment):
(JSC::B3::Air::StackSlot::b3Slot):
(JSC::B3::Air::StackSlot::offsetFromFP):
(WTF::printInternal):
(JSC::B3::Air::StackSlot::value): Deleted.
* b3/testb3.cpp:
(JSC::B3::testStackSlot):
(JSC::B3::testStoreLoadStackSlot):
* ftl/FTLB3Compile.cpp:
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::appendTo):
(JSC::FTL::Output::lockedStackSlot):
(JSC::FTL::Output::neg):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::framePointer):
(JSC::FTL::Output::constBool):
(JSC::FTL::Output::constInt32):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
* ftl/FTLState.h:
2016-01-26 Benjamin Poulain <benjamin@webkit.org>
Remove a useless #include
https://bugs.webkit.org/show_bug.cgi?id=153474
Reviewed by Alexey Proskuryakov.
* b3/B3ReduceStrength.cpp:
2016-01-26 Alex Christensen <achristensen@webkit.org>
[Win] Fix clean build after r195545.
​https://bugs.webkit.org/show_bug.cgi?id=153434
* CMakeLists.txt:
* PlatformWin.cmake:
Derived sources need to be copied after the build, but everything else should be copied before.
This should fix ews issues like the one seen in bug 153473.
2016-01-25 Filip Pizlo <fpizlo@apple.com>
FTLB3Output should maintain good block order like the LLVM one does
https://bugs.webkit.org/show_bug.cgi?id=152222
Reviewed by Geoffrey Garen.
This fixes FTLB3Output to emit an ordered B3 IR. This makes inspecting IR *a lot* easier.
It will also be a performance win whenever we use range-based data structures for
liveness.
Also two small other changes:
- Added some more dumping in integer range optimization phase.
- Refined the disassembler's printing of instruction width suffixes so that "jzl" is not
a thing. It was using "l" as the suffix because jumps take a 32-bit immediate.
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addBlock):
(JSC::B3::Procedure::setBlockOrderImpl):
(JSC::B3::Procedure::clone):
* b3/B3Procedure.h:
(JSC::B3::Procedure::frontendData):
(JSC::B3::Procedure::setBlockOrder):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* disassembler/udis86/udis86_syn-att.c:
(ud_translate_att):
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::initialize):
(JSC::FTL::Output::newBlock):
(JSC::FTL::Output::applyBlockOrder):
(JSC::FTL::Output::appendTo):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::setFrequency):
(JSC::FTL::Output::insertNewBlocksBefore):
(JSC::FTL::Output::callWithoutSideEffects):
(JSC::FTL::Output::newBlock): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
2016-01-25 Skachkov Oleksandr <gskachkov@gmail.com>
[ES6] Arrow function syntax. Arrow function specific features. Lexical bind "arguments"
https://bugs.webkit.org/show_bug.cgi?id=145132
Reviewed by Saam Barati.
Added support of ES6 arrow function specific feature, lexical bind of arguments.
http://www.ecma-international.org/ecma-262/6.0/#sec-arrow-function-definitions-runtime-semantics-evaluation
'arguments' variable in arrow function must resolve to a binding in a lexically enclosing environment.
In srict mode it points to arguments object, and in non-stric mode it points to arguments object or varible
with name 'arguments' if it was declared.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::setSourceParseMode):
(JSC::Scope::isArrowFunction):
(JSC::Scope::collectFreeVariables):
(JSC::Scope::setIsArrowFunction):
* tests/es6.yaml:
* tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js: Added.
* tests/stress/arrowfunction-lexical-bind-arguments-non-strict-2.js: Added.
* tests/stress/arrowfunction-lexical-bind-arguments-strict.js: Added.
2016-01-25 Benjamin Poulain <bpoulain@apple.com>
[JSC] We should never use x18 on iOS ARM64
https://bugs.webkit.org/show_bug.cgi?id=153461
Reviewed by Filip Pizlo.
The register x18 is reserved in the iOS variant of the ARM64 ABI.
The weird thing is: if you use it, its value will change completely
randomly. It looks like it is changed by the system on interrupts.
This patch adds x18 to the reserved register and add assertions
to the assembler to prevent similar problems in the future.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::xOrSp):
(JSC::ARM64Assembler::xOrZr):
* assembler/AbstractMacroAssembler.h:
(JSC::isIOS): Deleted.
* assembler/AssemblerCommon.h:
(JSC::isIOS):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::reservedHardwareRegisters):
2016-01-25 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r195550.
https://bugs.webkit.org/show_bug.cgi?id=153471
broke animometer bot (and now we have crash logs!) (Requested
by kling on #webkit).
Reverted changeset:
"Restore CodeBlock jettison code Geoff accidentally removed"
https://bugs.webkit.org/show_bug.cgi?id=151241
http://trac.webkit.org/changeset/195550
2016-01-25 Andreas Kling <akling@apple.com>
MarkedSpace should have more precise allocators.
<https://webkit.org/b/153448>
<rdar://problem/23897477>
Reviewed by Geoffrey Garen.
The four classes responsible for the bulk of MarkedBlock allocations today are:
- FunctionCodeBlock (640 bytes)
- UnlinkedFunctionCodeBlock (304 bytes)
- FunctionExecutable (168 bytes)
- UnlinkedFunctionExecutable (144 bytes)
Due to the size class distribution in MarkedSpace, we've been wasting quite a lot
of heap space on these objects. Our "precise" allocators allowed allocation sizes
in 16-byte increments up to 128 bytes, but after that point, we'd only allocate
in 256-byte size increments.
Thus each instance of those classes would waste space as follows:
- FunctionCodeBlock (768-byte cell, 128 bytes wasted)
- UnlinkedFunctionCodeBlock (512-byte cell, 208 bytes wasted)
- FunctionExecutable(256-byte cell, 88 bytes wasted)
- UnlinkedFunctionExecutable(256-byte cell, 112 bytes wasted)
This patch raises the limit for precise allocations from 128 to 768, allowing us
to allocate these objects with far better space efficiency.
The cost of this is 7kB worth of MarkedAllocators and 70 (~2x) more allocators to
iterate whenever we iterate all the allocators.
* heap/MarkedSpace.h:
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::MarkedSpace):
(JSC::MarkedSpace::resetAllocators):
(JSC::MarkedSpace::forEachAllocator):
(JSC::MarkedSpace::isPagedOut):
2016-01-25 Filip Pizlo <fpizlo@apple.com>
Fix the comment about FTL_USES_B3.
* dfg/DFGCommon.h:
2016-01-25 Filip Pizlo <fpizlo@apple.com>
Switch FTL to B3 on X86_64/Mac
https://bugs.webkit.org/show_bug.cgi?id=153445
Rubber stamped by Geoffrey Garen.
This finally switches from LLVM to B3 in the FTL on X86_64 on the Mac. We recommend that other
X86_64 platforms make the switch as well. We will be focusing our performance work on B3 rather
than LLVM in the future. ARM64 support is also coming soon, so we will be able to remove FTL
LLVM code once that lands.
Right now this mostly appears as perf-neutral on the major tests. However, it does have the
following immediate benefits:
- Dramatic reduction in FTL compile times, on the order of 5x-10x. This means huge speed-ups in
shorter-running tests like V8Spider (21%) and JSRegress (8%).
- It makes the FTL simpler and more robust because we don't have to do stackmap section
parsing. This makes it easier to add new FTL features. We are already working on features,
like the sampling profiler, which will only have a FTL B3 implementation.
- Speed-ups on some throughput benchmarks like mandreel, richards, imaging-gaussian-blur. It's
still a slow down on other throughput benchmarks, though.
We started writing B3 in October, so it's pretty awesome that the throughput of the code it
generates is already on par with LLVM.
This does not fundamentally change how the FTL works. FTL was built to lower DFG IR to a C-like
SSA IR, and then rely on powerful SSA optimizations and comprehensive instruction selection and
register allocation to turn that code into something that runs fast. B3 also has a C-like SSA
IR, has an instruction selector that is in some ways more powerful than LLVM's (B3 does global
instruction selection rather than block-local like LLVM), and it has a register allocator that
is in some ways more powerful also (B3 uses IRC, a mature graph coloring allocator, while LLVM
does not do graph coloring). We expect FTL B3's performance to improve a lot after we turn it
on and can focus our efforts on tuning it.
I didn't find any test regressions after running both JSC tests and layout tests. Basic
browsing still works. JetStream performance difference is within the margin of error. EWS is
happy.
* dfg/DFGCommon.h:
2016-01-25 Andreas Kling <akling@apple.com>
Restore CodeBlock jettison code Geoff accidentally removed
https://bugs.webkit.org/show_bug.cgi?id=151241
Rubber-stamped by Geoffrey Garen.
Geoff meant to add this back in <http://trac.webkit.org/changeset/190827>
but missed.
Then he added it back in, but it was rolled out due to a crash on Animometer.
I can no longer produce a crash on Animometer, either with today's version of
the benchmark, or the one that existed at the time of the rollout.
Given this, let's roll it back in and see how it goes.
* bytecode/CodeBlock.cpp:
(JSC::timeToLive):
(JSC::CodeBlock::shouldJettisonDueToOldAge):
2016-01-22 Filip Pizlo <fpizlo@apple.com>
mandreel should run just as fast in FTL B3 as FTL LLVM
https://bugs.webkit.org/show_bug.cgi?id=153394
Reviewed by Gavin Barraclough.
This fixes two performance bugs and one disassembler bug.
- B3 now turns Branches into Jumps when they are dominated by a Check on the same
condition. This is like the opposite of foldPathConstants() was doing.
- Air now supports adding to 8-bit or 16-bit memory locations on x86. B3 now knows how to
lower Store8(Add(Load8Z(...))) and various other things to these new instructions.
- Disassembler now knows to print out the instruction's width, whenever it has one.
Previously, we'd print movb, movw, movl, and movq as "mov", which is unhelpful if
you're storing an immediate, for example.
This adds a bunch of tests for the new instruction forms. This is a big speed-up on
mandreel. It makes us just as fast as LLVM on that benchmark.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::add32):
(JSC::MacroAssemblerX86Common::add8):
(JSC::MacroAssemblerX86Common::add16):
(JSC::MacroAssemblerX86Common::add32AndSetFlags):
(JSC::MacroAssemblerX86Common::clz32AfterBsr):
* assembler/X86Assembler.h:
(JSC::X86Assembler::addl_rm):
(JSC::X86Assembler::addb_rm):
(JSC::X86Assembler::addw_rm):
(JSC::X86Assembler::addl_ir):
(JSC::X86Assembler::addl_im):
(JSC::X86Assembler::addb_im):
(JSC::X86Assembler::addw_im):
(JSC::X86Assembler::addq_rr):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::addr):
(JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode):
(JSC::B3::Air::LowerToAir::loadPromise):
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3PureCSE.cpp:
(JSC::B3::PureCSE::clear):
(JSC::B3::PureCSE::findMatch):
(JSC::B3::PureCSE::process):
* b3/B3PureCSE.h:
* b3/B3ReduceStrength.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testNegPtr):
(JSC::B3::testStoreAddLoad32):
(JSC::B3::testStoreAddLoadImm32):
(JSC::B3::testStoreAddLoad8):
(JSC::B3::testStoreAddLoadImm8):
(JSC::B3::testStoreAddLoad16):
(JSC::B3::testStoreAddLoadImm16):
(JSC::B3::testStoreAddLoad64):
(JSC::B3::testStoreAddLoadImm64):
(JSC::B3::testStoreAddLoad32Index):
(JSC::B3::testStoreAddLoadImm32Index):
(JSC::B3::testStoreAddLoad8Index):
(JSC::B3::testStoreAddLoadImm8Index):
(JSC::B3::testStoreAddLoad16Index):
(JSC::B3::testStoreAddLoadImm16Index):
(JSC::B3::testStoreAddLoad64Index):
(JSC::B3::testStoreAddLoadImm64Index):
(JSC::B3::testStoreSubLoad):
(JSC::B3::run):
(JSC::B3::testStoreAddLoad): Deleted.
* disassembler/udis86/udis86_syn-att.c:
(ud_translate_att):
2016-01-25 Alex Christensen <achristensen@webkit.org>
[Win] Copy forwarding headers before building a project
https://bugs.webkit.org/show_bug.cgi?id=153434
Reviewed by Brent Fulgham.
* CMakeLists.txt:
* PlatformWin.cmake:
2016-01-25 Andreas Kling <akling@apple.com>
Reduce number of Structures created at startup.
<https://webkit.org/b/153399>
Reviewed by Darin Adler.
For *Constructor and *Prototype objects that are only created once per JSGlobalObject,
build up the Structures using addPropertyWithoutTransition() helpers to avoid creating
tons of transitions that would just end up floating around and never getting used.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
* inspector/JSJavaScriptCallFramePrototype.cpp:
(Inspector::JSJavaScriptCallFramePrototype::finishCreation):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* runtime/ConsolePrototype.cpp:
(JSC::ConsolePrototype::finishCreation):
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSArrayBufferConstructor::finishCreation):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation):
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectNativeFunctionWithoutTransition):
(JSC::JSObject::putDirectBuiltinFunctionWithoutTransition): Deleted.
* runtime/JSObject.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::JSPromiseConstructor::addOwnInternalSlots):
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::addOwnInternalSlots):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSTypedArrayViewConstructor::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototype::finishCreation):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
* runtime/SetIteratorPrototype.cpp:
(JSC::SetIteratorPrototype::finishCreation):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
* runtime/WeakMapPrototype.cpp:
(JSC::WeakMapPrototype::finishCreation):
* runtime/WeakSetPrototype.cpp:
(JSC::WeakSetPrototype::finishCreation):
2016-01-22 Filip Pizlo <fpizlo@apple.com>
B3 should strength-reduce division by a constant
https://bugs.webkit.org/show_bug.cgi?id=153386
Reviewed by Benjamin Poulain.
You can turn a 32-bit division by a constant into a 64-bit multiplication by a constant
plus some shifts. A book called "Hacker's Delight" has a bunch of math about this. The
hard part is finding the constant by which to multiply, and the amount by which to shift.
The book tells you some theroems, but you still have to turn that into code by thinking
deep thoughts. Luckily I was able to avoid that because it turns out that LLVM already
has code for this. It's called APInt::magic(), where APInt is their class for reasoning
about integers.
The code has a compatible license to ours and we have already in the past taken code from
LLVM. So, that's what this patch does. The LLVM code is localized in
B3ComputeDivisionMagic.h. Then reduceStrength() uses that to construct the multiply+shift
sequence.
This is an enormous speed-up on AsmBench-0.9/bigfib.cpp.js. It makes us as fast on that
test as LLVM. It reduces our deficit on AsmBench to 1.5%. Previously it was 4.5%.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3ComputeDivisionMagic.h: Added.
(JSC::B3::computeDivisionMagic):
* b3/B3ReduceStrength.cpp:
2016-01-22 Saam barati <sbarati@apple.com>
genericUnwind might overflow the instructions() vector when catching an FTL exception
https://bugs.webkit.org/show_bug.cgi?id=153383
Reviewed by Benjamin Poulain.
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
2016-01-22 Mark Lam <mark.lam@apple.com>
We should OSR exit with Int52Overflow when we fail to make an Int52 where we expect one.
https://bugs.webkit.org/show_bug.cgi?id=153379
Reviewed by Filip Pizlo.
In DFG::Graph::addShouldSpeculateMachineInt(), we check
!hasExitSite(add, Int52Overflow) when determining whether it's ok to speculate
that an operand is of type Int52 or not. However, the Int52Rep code that
converts a double to Int52 will OSR exit with exit kind BadType instead.
This renders the hasExitSite() check in addShouldSpeculateMachineInt() useless.
This patch fixes this by changing Int52Rep to OSR exit with exit kind
Int52Overflow instead when it fails to convert a double to an Int52.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
(JSC::DFG::SpeculativeJIT::typeCheck):
(JSC::DFG::SpeculativeJIT::usedRegisters):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::needsTypeCheck):
(JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::typeCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::appendTypeCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::doubleToStrictInt52):
2016-01-22 Saam barati <sbarati@apple.com>
Current implementation of Parser::createSavePoint is a foot gun
https://bugs.webkit.org/show_bug.cgi?id=153293
Reviewed by Oliver Hunt.
The previous use of SavePoint (up until this patch)
really meant that we're saving the LexerState. This
was so poorly named that it was being misused all over
our parser. For example, anything that parsed an
AssignmentExpression between saving/restoring really
wanted to save both Lexer state and Parser state.
This patch changes SavePoint to mean save all the
state. The old SavePoint is renamed to LexerState with
corresponding internal<Save/Restore>LexerState functions.
The old <save/restore>State() function is renamed to
internal<Save/Restore>ParserState().
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::isArrowFunctionParameters):
(JSC::Parser<LexerType>::parseSourceElements):
(JSC::Parser<LexerType>::declareRestOrNormalParameter):
(JSC::Parser<LexerType>::parseAssignmentElement):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseExpression):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseYieldExpression):
(JSC::Parser<LexerType>::parseConditionalExpression):
(JSC::Parser<LexerType>::parseBinaryExpression):
(JSC::Parser<LexerType>::parseObjectLiteral):
(JSC::Parser<LexerType>::parseStrictObjectLiteral):
(JSC::Parser<LexerType>::parseArrayLiteral):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
(JSC::Parser<LexerType>::parseUnaryExpression):
* parser/Parser.h:
(JSC::Parser::hasError):
(JSC::Parser::internalSaveParserState):
(JSC::Parser::restoreParserState):
(JSC::Parser::internalSaveLexerState):
(JSC::Parser::restoreLexerState):
(JSC::Parser::createSavePointForError):
(JSC::Parser::createSavePoint):
(JSC::Parser::restoreSavePointWithError):
(JSC::Parser::restoreSavePoint):
(JSC::Parser::saveState): Deleted.
(JSC::Parser::restoreState): Deleted.
2016-01-22 Keith Miller <keith_miller@apple.com>
Unreviewed. fnormal => normal.
* tests/es6.yaml:
2016-01-22 Keith Miller <keith_miller@apple.com>
Unreviewed. Forgot to git stash pop some of the changes.
This should mark the rest of the es6 tests as passing.
* tests/es6.yaml:
2016-01-22 Keith Miller <keith_miller@apple.com>
Unreviewed. Mark es6 tests as passing.
* tests/es6.yaml:
2016-01-22 Saam barati <sbarati@apple.com>
op_profile_type 32-bit LLInt implementation has a bug
https://bugs.webkit.org/show_bug.cgi?id=153368
Reviewed by Michael Saboff.
r189293 changed which registers were used, specifically
using t5 instead of t4. That change forgot to replace
t4 with t5 in one specific instance.
* llint/LowLevelInterpreter32_64.asm:
2016-01-22 Filip Pizlo <fpizlo@apple.com>
B3 should reduce obvious forms of Shl(SShr)
https://bugs.webkit.org/show_bug.cgi?id=153362
Reviewed by Mark Lam and Saam Barati.
This is a 40% speed-up in AsmBench-0.9/dry.c.js.
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testStore16Load16Z):
(JSC::B3::testSShrShl32):
(JSC::B3::testSShrShl64):
(JSC::B3::zero):
(JSC::B3::run):
2016-01-22 Alex Christensen <achristensen@webkit.org>
Fix internal Windows build
https://bugs.webkit.org/show_bug.cgi?id=153364
<rdar://problem/24296328>
Reviewed by Brent Fulgham.
* PlatformWin.cmake:
The internal build does not build JavaScriptCore with WTF, so it does not automatically link to winmm.lib
like it does when everything is built together.
2016-01-22 Keith Miller <keith_miller@apple.com>
Equivalence PropertyCondition needs to check the offset it uses to load the value from is not invalidOffset
https://bugs.webkit.org/show_bug.cgi?id=152912
Reviewed by Mark Lam.
When checking the validity of an Equivalence PropertyCondition we do not check that the offset returned by
the structure of the object in the equivalence condition is valid. The offset might be wrong for many reasons.
The one we now test for is when the GlobalObject has a property that becomes a variable the property is deleted
thus the offset is now invalid.
* bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint):
* tests/stress/global-property-into-variable-get-from-scope.js: Added.
2016-01-22 Keith Miller <keith_miller@apple.com>
[ES6] Add Symbol.species properties to the relevant constructors
https://bugs.webkit.org/show_bug.cgi?id=153339
Reviewed by Michael Saboff.
This patch adds Symbol.species to the RegExp, Array, TypedArray, Map, Set, ArrayBuffer, and
Promise constructors. The functions that use these properties will be added in a later
patch.
* builtins/GlobalObject.js:
(speciesGetter):
* runtime/ArrayConstructor.cpp:
(JSC::ArrayConstructor::finishCreation):
* runtime/ArrayConstructor.h:
(JSC::ArrayConstructor::create):
* runtime/BooleanConstructor.h:
(JSC::BooleanConstructor::create):
* runtime/CommonIdentifiers.h:
* runtime/DateConstructor.h:
(JSC::DateConstructor::create):
* runtime/ErrorConstructor.h:
(JSC::ErrorConstructor::create):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSArrayBufferConstructor::finishCreation):
(JSC::JSArrayBufferConstructor::create):
* runtime/JSArrayBufferConstructor.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSInternalPromiseConstructor.cpp:
(JSC::JSInternalPromiseConstructor::create):
* runtime/JSInternalPromiseConstructor.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::JSPromiseConstructor::create):
(JSC::JSPromiseConstructor::finishCreation):
* runtime/JSPromiseConstructor.h:
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSTypedArrayViewConstructor::finishCreation):
(JSC::JSTypedArrayViewConstructor::create): Deleted.
* runtime/JSTypedArrayViewConstructor.h:
(JSC::JSTypedArrayViewConstructor::create):
* runtime/MapConstructor.cpp:
(JSC::MapConstructor::finishCreation):
* runtime/MapConstructor.h:
(JSC::MapConstructor::create):
* runtime/NumberConstructor.h:
(JSC::NumberConstructor::create):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::finishCreation):
* runtime/RegExpConstructor.h:
(JSC::RegExpConstructor::create):
* runtime/SetConstructor.cpp:
(JSC::SetConstructor::finishCreation):
* runtime/SetConstructor.h:
(JSC::SetConstructor::create):
* runtime/StringConstructor.h:
(JSC::StringConstructor::create):
* runtime/SymbolConstructor.h:
(JSC::SymbolConstructor::create):
* runtime/WeakMapConstructor.h:
(JSC::WeakMapConstructor::create):
* runtime/WeakSetConstructor.h:
(JSC::WeakSetConstructor::create):
* tests/stress/symbol-species.js: Added.
(testSymbolSpeciesOnConstructor):
2016-01-21 Benjamin Poulain <benjamin@webkit.org>
[JSC] The IRC allocator can mess up the degree of Tmps interfering with move-related Tmps
https://bugs.webkit.org/show_bug.cgi?id=153340
Reviewed by Filip Pizlo.
The JavaScriptCore tests uncovered an interested bug in the iterated register
coalescing allocator. When coalescing a move under the right conditions, it is
possible to mess-up the graph for the Tmps interfering with the coalesced Tmps.
Some context first:
-When coalescing a move, we alias one Tmp to another. Let say that we had
Move X, Y
the coalescing may alias Y to X: Y->X.
-Since X and Y are equivalent after coalescing, any interference
edge with Y is "moved" to X.
The way this was done was to add an edge to X for every edge there was with Y.
Say we had an edge R--Y, we add an edge R--X.
Adding an edge increases the degree of R and Y. The degree of R was then
fixed by calling decrementDegree() on it.
-decrementDegree() is non trivial. It will move the Tmp to the right list
for further processing if the Tmp's degree becomes lower than the number
of available registers.
The bug appear in a particular case. Say we have 3 Tmp, A, B, and C.
-A and B are move related, they can be coalesced.
-A has an interference edge with C.
-B does not have and interfence edge with C.
-C's degree is exactly the number of avaialble registers/colors minus one (k - 1).
-> This implies C is already in its list.
We coalesce A and B into B (A->B).
-The first step, addEdgeDistinct() adds an edge between B and C. The degrees of
B and C are increased by one. The degree of C becomes k.
-Next, decrementDegree() is called on C. Its degree decreases to k-1.
Because of the change from k to k-1, decrementDegree() adds C to a list again.
We have two kinds of bugs depending on the test:
-A Tmp can be added to the simplifyWorklist several time.
-A Tmp can be in both simplifyWorklist and freezeWorklist (because its move-related
status changed since the last decrementDegree()).
In both cases, the Tmps interfering with the duplicated Tmp will end up with
a degree lower than their real value.
* b3/air/AirIteratedRegisterCoalescing.cpp:
2016-01-21 Andreas Kling <akling@apple.com>
Add some missing WTF_MAKE_FAST_ALLOCATED in JavaScriptCore.
<https://webkit.org/b/153335>
Reviewed by Alex Christensen.
Saw these things getting system malloc()'ed in an Instruments trace.
* inspector/InspectorAgentBase.h:
* jit/CallFrameShuffleData.h:
* jit/CallFrameShuffler.h:
* jit/RegisterAtOffsetList.h:
* runtime/GenericOffset.h:
2016-01-21 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Catch parameter should accept BindingPattern
https://bugs.webkit.org/show_bug.cgi?id=152385
Reviewed by Saam Barati.
This patch implements destructuring in catch parameter.
Catch parameter accepts binding pattern and binding identifier.
It creates lexical bindings. And "yield" and "let" are specially
handled as is the same to function parameters.
In addition to that, we make destructuring parsing errors more descriptive.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitPushCatchScope):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::TryNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createTryStatement):
* parser/NodeConstructors.h:
(JSC::TryNode::TryNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
(JSC::Parser<LexerType>::parseBindingOrAssignmentElement):
(JSC::destructuringKindToVariableKindName):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseTryStatement):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::Parser<LexerType>::parseFunctionParameters):
* parser/Parser.h:
(JSC::Parser::destructuringKindFromDeclarationType):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createTryStatement):
* tests/es6.yaml:
* tests/es6/destructuring_in_catch_heads.js: Added.
(test):
* tests/stress/catch-parameter-destructuring.js: Added.
(shouldBe):
(shouldThrow):
(prototype.call):
(catch):
(shouldThrow.try.throw.get error):
(initialize):
(array):
(generator.gen):
(generator):
* tests/stress/catch-parameter-syntax.js: Added.
(testSyntax):
(testSyntaxError):
* tests/stress/reserved-word-with-escape.js:
(testSyntaxError.String.raw.a):
(String.raw.SyntaxError.Cannot.use.the.keyword.string_appeared_here.as.a.name):
* tests/stress/yield-named-variable.js:
2016-01-21 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix build.
* b3/B3EliminateCommonSubexpressions.cpp:
2016-01-21 Filip Pizlo <fpizlo@apple.com>
B3 CSE should be able to match a full redundancy even if none of the matches dominate the value in question
https://bugs.webkit.org/show_bug.cgi?id=153321
Reviewed by Benjamin Poulain.
I once learned that LLVM's GVN can manufacture Phi functions. I don't know the details
but I'm presuming that it involves:
if (p)
tmp1 = *ptr
else
tmp2 = *ptr
tmp3 = *ptr // Replace this with Phi(tmp1, tmp2).
This adds such an optimization to our CSE. The idea is that we search through basic
blocks until we find the value we want, a side effect, or the start of the procedure. If
we find a value that matches our search criteria, we record it and ignore the
predecessors. If we find a side effect or the start of the procedure, we give up the
whole search. This ensures that if we come out of the search without giving up, we'll
have a set of matches that are fully redundant.
CSE could then create a Phi graph by using SSACalculator. But the recent work on FixSSA
revealed a much more exciting option: create a stack slot! In case there is more than one
match, CSE now creates a stack slot that each match stores to, and replaces the redundant
instruction with a loadfrom the stack slot. The stack slot is anonymous, which ensures
that FixSSA will turn it into an optimal Phi graph or whatever.
This is a significant speed-up on Octane/richards.
* b3/B3DuplicateTails.cpp:
* b3/B3EliminateCommonSubexpressions.cpp:
* b3/B3FixSSA.cpp:
(JSC::B3::fixSSA):
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3Procedure.h:
(JSC::B3::Procedure::setFrontendData):
(JSC::B3::Procedure::frontendData):
* b3/testb3.cpp:
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
2016-01-21 Filip Pizlo <fpizlo@apple.com>
Air should know that CeilDouble has the partial register stall issue
https://bugs.webkit.org/show_bug.cgi?id=153338
Rubber stamped by Benjamin Poulain.
This is a 8% speed-up on Kraken with B3 enabled, mostly because of a 2.4x speed-up on
audio-oscillator.
* b3/air/AirFixPartialRegisterStalls.cpp:
2016-01-21 Andy VanWagoner <andy@instructure.com>
[INTL] Implement Array.prototype.toLocaleString in ECMA-402
https://bugs.webkit.org/show_bug.cgi?id=147614
Reviewed by Benjamin Poulain.
The primary changes in the ECMA-402 version, and the existing implementation
are passing the arguments on to each element's toLocaleString call, and
missing/undefined/null elements become empty string instead of being skipped.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncToLocaleString):
2016-01-21 Per Arne Vollan <peavo@outlook.com>
[B3][Win64] Compile fixes.
https://bugs.webkit.org/show_bug.cgi?id=153312
Reviewed by Alex Christensen.
Since MSVC has several overloads of sin, cos, pow, and log, we need to specify
which one we want to use.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doubleSin):
(JSC::FTL::Output::doubleCos):
(JSC::FTL::Output::doublePow):
(JSC::FTL::Output::doubleLog):
2016-01-21 Benjamin Poulain <benjamin@webkit.org>
[JSC] foldPathConstants() makes invalid assumptions with Switch
https://bugs.webkit.org/show_bug.cgi?id=153324
Reviewed by Filip Pizlo.
If a Switch() has two cases pointing to the same basic block, foldPathConstants()
was adding two override for that block with two different constants.
If the block with the Switch dominates the target, both override were equally valid
and we were assuming any of the constants as the value in the target block.
See testSwitchTargettingSameBlockFoldPathConstant() for an example that breaks.
This patch adds checks to ignore any block that is reached more than
once by the control value.
* b3/B3FoldPathConstants.cpp:
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/testb3.cpp:
(JSC::B3::testSwitchTargettingSameBlock):
(JSC::B3::testSwitchTargettingSameBlockFoldPathConstant):
(JSC::B3::run):
2016-01-21 Filip Pizlo <fpizlo@apple.com>
Unreviewed, undo DFGCommon.h change that accidentally enabled the B3 JIT.
* dfg/DFGCommon.h:
2016-01-21 Filip Pizlo <fpizlo@apple.com>
Move32 should have an Imm, Tmp form
https://bugs.webkit.org/show_bug.cgi?id=153313
Reviewed by Mark Lam.
This enables some useful optimizations, like constant propagation in fixObviousSpills().
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::zeroExtend32ToPtr):
(JSC::MacroAssemblerX86Common::move):
* b3/air/AirOpcode.opcodes:
2016-01-21 Filip Pizlo <fpizlo@apple.com>
B3 should have load elimination
https://bugs.webkit.org/show_bug.cgi?id=153288
Reviewed by Geoffrey Garen.
This adds a complete GCSE pass that includes load elimination. It would have been super hard
to make this work as part of the reduceStrength() fixpoint, since GCSE needs to analyze
control flow and reduceStrength() is messing with control flow. So, I did a compromise: I
factored out the pure CSE that reduceStrength() was already doing, and now we have:
- reduceStrength() still does pure CSE using the new PureCSE helper.
- eliminateCommonSubexpressions() is a separate phase that does general CSE. It uses the
PureCSE helper for pure values and does its own special thing for memory values.
Unfortunately, this doesn't help any benchmark right now. It doesn't hurt anything, either,
and it's likely to become a bigger pay-off once we implement other features, like mapping
FTL's abstract heaps onto B3's heap ranges.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3EliminateCommonSubexpressions.cpp: Added.
(JSC::B3::eliminateCommonSubexpressions):
* b3/B3EliminateCommonSubexpressions.h: Added.
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3HeapRange.h:
(JSC::B3::HeapRange::HeapRange):
* b3/B3InsertionSet.h:
(JSC::B3::InsertionSet::InsertionSet):
(JSC::B3::InsertionSet::isEmpty):
(JSC::B3::InsertionSet::code):
(JSC::B3::InsertionSet::appendInsertion):
* b3/B3MemoryValue.h:
* b3/B3PureCSE.cpp: Added.
(JSC::B3::PureCSE::PureCSE):
(JSC::B3::PureCSE::~PureCSE):
(JSC::B3::PureCSE::clear):
(JSC::B3::PureCSE::process):
* b3/B3PureCSE.h: Added.
* b3/B3ReduceStrength.cpp:
* b3/B3ReduceStrength.h:
* b3/B3Validate.cpp:
2016-01-21 Keith Miller <keith_miller@apple.com>
Fix bug in TypedArray.prototype.set and add tests
https://bugs.webkit.org/show_bug.cgi?id=153309
Reviewed by Michael Saboff.
This patch fixes an issue with TypedArray.prototype.set where we would
assign a double to an unsigned without checking that the double was
in the range of the unsigned. Additionally, the patch also adds
tests for set for cases that were not covered before.
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncSet):
* tests/stress/typedarray-set.js: Added.
2016-01-19 Ada Chan <adachan@apple.com>
Make it possible to enable VIDEO_PRESENTATION_MODE on other Cocoa platforms.
https://bugs.webkit.org/show_bug.cgi?id=153218
Reviewed by Eric Carlson.
* Configurations/FeatureDefines.xcconfig:
2016-01-21 Per Arne Vollan <peavo@outlook.com>
[B3][CMake] Add missing source file.
https://bugs.webkit.org/show_bug.cgi?id=153303
Reviewed by Csaba Osztrogonác.
* CMakeLists.txt:
2016-01-20 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r195375.
https://bugs.webkit.org/show_bug.cgi?id=153300
Caused crashes on GuardMalloc (Requested by ap on #webkit).
Reverted changeset:
"TypedArray's .buffer does not return the JSArrayBuffer that
was passed to it on creation."
https://bugs.webkit.org/show_bug.cgi?id=153281
http://trac.webkit.org/changeset/195375
2016-01-19 Filip Pizlo <fpizlo@apple.com>
B3 should have basic path specialization
https://bugs.webkit.org/show_bug.cgi?id=153200
Reviewed by Benjamin Poulain.
This adds two different kind of path specializations:
- Check(Select) where the Select results are constants is specialized into a Branch
instead of a Select and duplicated paths where the results of the Select are folded.
- Tail duplication. A jump to a small block causes the block's contents to be copied over
the Jump.
Both optimizations required being able to clone Values. We can now do that using
proc.clone(value).
Check(Select) specialization needed some utilities for walking graphs of Values.
Tail duplication needed SSA fixup, so I added a way to demote values to anonymous stack
slots (B3's equivalent of non-SSA variables) and a way to "fix SSA", i.e. to allocate
anonymous stack slots to SSA values along with an optimal Phi graph.
This is a big speed-up on Octane/deltablue. It's a 2.2% speed-up on Octane overall.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3ArgumentRegValue.cpp:
(JSC::B3::ArgumentRegValue::dumpMeta):
(JSC::B3::ArgumentRegValue::cloneImpl):
* b3/B3ArgumentRegValue.h:
* b3/B3BasicBlock.cpp:
(JSC::B3::BasicBlock::append):
(JSC::B3::BasicBlock::appendNonTerminal):
(JSC::B3::BasicBlock::removeLast):
* b3/B3BasicBlock.h:
(JSC::B3::BasicBlock::values):
* b3/B3BasicBlockInlines.h:
(JSC::B3::BasicBlock::appendNew):
(JSC::B3::BasicBlock::appendNewNonTerminal):
(JSC::B3::BasicBlock::replaceLastWithNew):
* b3/B3BlockInsertionSet.h:
* b3/B3BreakCriticalEdges.cpp: Added.
(JSC::B3::breakCriticalEdges):
* b3/B3BreakCriticalEdges.h: Added.
* b3/B3CCallValue.cpp:
(JSC::B3::CCallValue::~CCallValue):
(JSC::B3::CCallValue::cloneImpl):
* b3/B3CCallValue.h:
* b3/B3CheckValue.cpp:
(JSC::B3::CheckValue::convertToAdd):
(JSC::B3::CheckValue::cloneImpl):
(JSC::B3::CheckValue::CheckValue):
* b3/B3CheckValue.h:
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::dumpMeta):
(JSC::B3::Const32Value::cloneImpl):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::dumpMeta):
(JSC::B3::Const64Value::cloneImpl):
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::dumpMeta):
(JSC::B3::ConstDoubleValue::cloneImpl):
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.cpp:
(JSC::B3::ConstFloatValue::dumpMeta):
(JSC::B3::ConstFloatValue::cloneImpl):
* b3/B3ConstFloatValue.h:
* b3/B3ControlValue.cpp:
(JSC::B3::ControlValue::dumpMeta):
(JSC::B3::ControlValue::cloneImpl):
* b3/B3ControlValue.h:
* b3/B3DuplicateTails.cpp: Added.
(JSC::B3::duplicateTails):
* b3/B3DuplicateTails.h: Added.
* b3/B3FixSSA.cpp: Added.
(JSC::B3::demoteValues):
(JSC::B3::fixSSA):
* b3/B3FixSSA.h: Added.
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3IndexSet.h:
(JSC::B3::IndexSet::Iterable::Iterable):
(JSC::B3::IndexSet::values):
(JSC::B3::IndexSet::indices):
* b3/B3InsertionSet.cpp:
(JSC::B3::InsertionSet::insertIntConstant):
(JSC::B3::InsertionSet::insertBottom):
(JSC::B3::InsertionSet::execute):
* b3/B3InsertionSet.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::tmp):
* b3/B3MemoryValue.cpp:
(JSC::B3::MemoryValue::dumpMeta):
(JSC::B3::MemoryValue::cloneImpl):
* b3/B3MemoryValue.h:
* b3/B3OriginDump.cpp: Added.
(JSC::B3::OriginDump::dump):
* b3/B3OriginDump.h:
(JSC::B3::OriginDump::OriginDump):
(JSC::B3::OriginDump::dump): Deleted.
* b3/B3PatchpointValue.cpp:
(JSC::B3::PatchpointValue::dumpMeta):
(JSC::B3::PatchpointValue::cloneImpl):
(JSC::B3::PatchpointValue::PatchpointValue):
* b3/B3PatchpointValue.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addBlock):
(JSC::B3::Procedure::clone):
(JSC::B3::Procedure::addIntConstant):
(JSC::B3::Procedure::addBottom):
(JSC::B3::Procedure::addBoolConstant):
(JSC::B3::Procedure::deleteValue):
* b3/B3Procedure.h:
* b3/B3ReduceStrength.cpp:
* b3/B3SSACalculator.cpp: Added.
(JSC::B3::SSACalculator::Variable::dump):
(JSC::B3::SSACalculator::Variable::dumpVerbose):
(JSC::B3::SSACalculator::Def::dump):
(JSC::B3::SSACalculator::SSACalculator):
(JSC::B3::SSACalculator::~SSACalculator):
(JSC::B3::SSACalculator::reset):
(JSC::B3::SSACalculator::newVariable):
(JSC::B3::SSACalculator::newDef):
(JSC::B3::SSACalculator::nonLocalReachingDef):
(JSC::B3::SSACalculator::reachingDefAtTail):
(JSC::B3::SSACalculator::dump):
* b3/B3SSACalculator.h: Added.
(JSC::B3::SSACalculator::Variable::index):
(JSC::B3::SSACalculator::Variable::Variable):
(JSC::B3::SSACalculator::Def::variable):
(JSC::B3::SSACalculator::Def::block):
(JSC::B3::SSACalculator::Def::value):
(JSC::B3::SSACalculator::Def::Def):
(JSC::B3::SSACalculator::variable):
(JSC::B3::SSACalculator::computePhis):
(JSC::B3::SSACalculator::phisForBlock):
(JSC::B3::SSACalculator::reachingDefAtHead):
* b3/B3StackSlotKind.h:
* b3/B3StackSlotValue.cpp:
(JSC::B3::StackSlotValue::dumpMeta):
(JSC::B3::StackSlotValue::cloneImpl):
* b3/B3StackSlotValue.h:
* b3/B3SwitchValue.cpp:
(JSC::B3::SwitchValue::dumpMeta):
(JSC::B3::SwitchValue::cloneImpl):
(JSC::B3::SwitchValue::SwitchValue):
* b3/B3SwitchValue.h:
* b3/B3UpsilonValue.cpp:
(JSC::B3::UpsilonValue::dumpMeta):
(JSC::B3::UpsilonValue::cloneImpl):
* b3/B3UpsilonValue.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::replaceWithNop):
(JSC::B3::Value::replaceWithPhi):
(JSC::B3::Value::dump):
(JSC::B3::Value::cloneImpl):
(JSC::B3::Value::dumpChildren):
(JSC::B3::Value::deepDump):
* b3/B3Value.h:
(JSC::B3::DeepValueDump::DeepValueDump):
(JSC::B3::DeepValueDump::dump):
(JSC::B3::deepDump):
* b3/B3ValueInlines.h:
(JSC::B3::Value::asNumber):
(JSC::B3::Value::walk):
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::intConstant):
(JSC::B3::ValueKey::dump):
* b3/B3ValueKey.h:
(JSC::B3::ValueKey::ValueKey):
(JSC::B3::ValueKey::opcode):
(JSC::B3::ValueKey::type):
(JSC::B3::ValueKey::childIndex):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::forAllTmps):
(JSC::B3::Air::Code::isFastTmp):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirUseCounts.h:
(JSC::B3::Air::UseCounts::UseCounts):
(JSC::B3::Air::UseCounts::operator[]):
(JSC::B3::Air::UseCounts::dump):
* b3/testb3.cpp:
(JSC::B3::testSelectInvert):
(JSC::B3::testCheckSelect):
(JSC::B3::testCheckSelectCheckSelect):
(JSC::B3::testPowDoubleByIntegerLoop):
(JSC::B3::run):
* runtime/Options.h:
2016-01-20 Benjamin Poulain <bpoulain@apple.com>
[JSC] Fix a typo in the Air definition of CeilDouble/CeilFloat
https://bugs.webkit.org/show_bug.cgi?id=153286
Reviewed by Mark Lam.
* b3/air/AirOpcode.opcodes:
The second argument should a Def. The previous definition was
adding useless constraints on the allocation of the second argument.
2016-01-20 Benjamin Poulain <benjamin@webkit.org>
[JSC] The register allocator can use a dangling pointer when selecting a spill candidate
https://bugs.webkit.org/show_bug.cgi?id=153287
Reviewed by Mark Lam.
A tricky bug I discovered while experimenting with live range breaking.
We have the following initial conditions:
-UseCounts is slow, so we only compute it once for all the iterations
of the allocator.
-The only new Tmps we create are for spills and refills. They are unspillable
by definition so it is fine to not update UseCounts accordingly.
But, in selectSpill(), we go over all the spill candidates and select the best
one based on its score. The score() lambda uses useCounts, it cannot be used
with a new Tmps created for something we already spilled.
The first time we use score is correct, we started by skipping all the unspillable
Tmps from the candidate. The next use was incorrect: we were checking unspillableTmps
*after* calling score().
The existing tests did not catch this due to back luck. I added an assertion
to find similar problems in the future.
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirUseCounts.h:
2016-01-20 Saam barati <sbarati@apple.com>
Fix CLoop build after bug https://bugs.webkit.org/show_bug.cgi?id=152766
Unreviewed build fix.
* inspector/agents/InspectorScriptProfilerAgent.h:
2016-01-20 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement Date.prototype.toLocaleTimeString in ECMA-402
https://bugs.webkit.org/show_bug.cgi?id=147613
Reviewed by Darin Adler.
Implement toLocaleTimeString in builtin JavaScript.
* builtins/DatePrototype.js:
(toLocaleTimeString.toDateTimeOptionsTimeTime):
(toLocaleTimeString):
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
2016-01-20 Saam barati <sbarati@apple.com>
Web Inspector: Hook the sampling profiler into the Timelines UI
https://bugs.webkit.org/show_bug.cgi?id=152766
<rdar://problem/24066360>
Reviewed by Joseph Pecoraro.
This patch adds some necessary functions to SamplingProfiler::StackFrame
to allow it to give data to the Inspector for the timelines UI. i.e, the
sourceID of the executable of a stack frame.
This patch also swaps in the SamplingProfiler in place of the
LegacyProfiler inside InspectorScriptProfilerAgent. It adds
the necessary protocol data to allow the SamplingProfiler's
data to hook into the timelines UI.
* debugger/Debugger.cpp:
(JSC::Debugger::setProfilingClient):
(JSC::Debugger::willEvaluateScript):
(JSC::Debugger::didEvaluateScript):
(JSC::Debugger::toggleBreakpoint):
* debugger/Debugger.h:
* debugger/ScriptProfilingScope.h:
(JSC::ScriptProfilingScope::ScriptProfilingScope):
(JSC::ScriptProfilingScope::~ScriptProfilingScope):
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorScriptProfilerAgent::startTracking):
(Inspector::InspectorScriptProfilerAgent::stopTracking):
(Inspector::InspectorScriptProfilerAgent::isAlreadyProfiling):
(Inspector::InspectorScriptProfilerAgent::willEvaluateScript):
(Inspector::InspectorScriptProfilerAgent::didEvaluateScript):
(Inspector::InspectorScriptProfilerAgent::addEvent):
(Inspector::buildSamples):
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
(Inspector::buildAggregateCallInfoInspectorObject): Deleted.
(Inspector::buildInspectorObject): Deleted.
(Inspector::buildProfileInspectorObject): Deleted.
* inspector/agents/InspectorScriptProfilerAgent.h:
* inspector/protocol/ScriptProfiler.json:
* jsc.cpp:
(functionSamplingProfilerStackTraces):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::start):
(JSC::SamplingProfiler::stop):
(JSC::SamplingProfiler::clearData):
(JSC::SamplingProfiler::StackFrame::displayName):
(JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
(JSC::SamplingProfiler::StackFrame::startLine):
(JSC::SamplingProfiler::StackFrame::startColumn):
(JSC::SamplingProfiler::StackFrame::sourceID):
(JSC::SamplingProfiler::StackFrame::url):
(JSC::SamplingProfiler::stackTraces):
(JSC::SamplingProfiler::stackTracesAsJSON):
(JSC::displayName): Deleted.
(JSC::SamplingProfiler::stacktracesAsJSON): Deleted.
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::StackFrame::StackFrame):
(JSC::SamplingProfiler::getLock):
(JSC::SamplingProfiler::setTimingInterval):
(JSC::SamplingProfiler::totalTime):
(JSC::SamplingProfiler::setStopWatch):
(JSC::SamplingProfiler::stackTraces): Deleted.
* tests/stress/sampling-profiler-anonymous-function.js:
(platformSupportsSamplingProfiler.baz):
(platformSupportsSamplingProfiler):
* tests/stress/sampling-profiler-basic.js:
(platformSupportsSamplingProfiler.nothing):
(platformSupportsSamplingProfiler.top):
* tests/stress/sampling-profiler/samplingProfiler.js:
(doesTreeHaveStackTrace):
2016-01-20 Keith Miller <keith_miller@apple.com>
TypedArray's .buffer does not return the JSArrayBuffer that was passed to it on creation.
https://bugs.webkit.org/show_bug.cgi?id=153281
Reviewed by Geoffrey Garen.
When creating an JSArrayBuffer we should make sure that the backing ArrayBuffer uses the
new JSArrayBuffer as its wrapper. This causes issues when we get the buffer of a Typed Array
created by passing a JSArrayBuffer as the backing ArrayBuffer does not have a reference to
the original JSArrayBuffer and a new object is created.
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::finishCreation):
* tests/stress/typedarray-buffer-neutered.js: Added.
(arrays.typedArrays.map):
2016-01-20 Andreas Kling <akling@apple.com>
Pack RegisterAtOffset harder.
<https://webkit.org/b/152501>
Reviewed by Michael Saboff.
Pack the register index and the offset into a single pointer-sized word instead of two.
This reduces memory consumption by 620 kB on mobile theverge.com.
The packing doesn't succeed on MSVC for some reason, so I've left out the static
assertion about class size in those builds.
* jit/RegisterAtOffset.cpp:
* jit/RegisterAtOffset.h:
2016-01-20 Per Arne Vollan <peavo@outlook.com>
[B3][Win64] Compile fix.
https://bugs.webkit.org/show_bug.cgi?id=153278
Reviewed by Filip Pizlo.
MSVC does not accept that a class declared as exported also have members declared as exported.
* b3/B3Const32Value.h:
* b3/B3ControlValue.h:
2016-01-19 Keith Miller <keith_miller@apple.com>
[ES6] Fix various issues with TypedArrays.
https://bugs.webkit.org/show_bug.cgi?id=153245
Reviewed by Geoffrey Garen.
This patch fixes a couple of issues with TypedArrays:
1) We were not checking if a view had been neutered and throwing an error
if it had in the our TypedArray.prototype functions.
2) The TypedArray.prototype.set function had a couple of minor issues with
checking for the offset being negative.
3) The JSArrayBufferView class did not check if the backing store had
been neutered when computing the offset even though the view's vector
pointer had been set to NULL. This meant that under some conditions we
could, occasionally, return a garbage number as the offset. Now, we only
neuter views if the backing ArrayBuffer's view is actually transfered.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionNeuterTypedArray):
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::isNeutered):
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::byteOffset):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncEntries):
(JSC::genericTypedArrayViewProtoFuncCopyWithin):
(JSC::genericTypedArrayViewProtoFuncFill):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncKeys):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
(JSC::genericTypedArrayViewProtoFuncReverse):
(JSC::genericTypedArrayViewPrivateFuncSort):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewProtoFuncSubarray):
(JSC::typedArrayViewProtoFuncValues):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::typedArrayViewPrivateFuncLength):
(JSC::typedArrayViewPrivateFuncSort): Deleted.
* tests/stress/typedarray-functions-with-neutered.js: Added.
(getGetter):
(unit):
(args.new.Int32Array):
(arrays.typedArrays.map):
(checkProtoFunc.throwsCorrectError):
(checkProtoFunc):
(test):
2016-01-19 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement Date.prototype.toLocaleDateString in ECMA-402
https://bugs.webkit.org/show_bug.cgi?id=147612
Reviewed by Benjamin Poulain.
Implement toLocaleDateString in builtin JavaScript. Remove comments with
spec steps, and instead link to the new HTML version of the spec.
Avoids creating an extra empty object in the prototype chain of the options
object in ToDateTimeOptions. The version used in toLocaleString was updated
to match as well.
* builtins/DatePrototype.js:
(toLocaleString.toDateTimeOptionsAnyAll):
(toLocaleString):
(toLocaleDateString.toDateTimeOptionsDateDate):
(toLocaleDateString):
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
2016-01-19 Benjamin Poulain <bpoulain@apple.com>
[JSC] fixSpillSlotZDef() crashes on ARM64
https://bugs.webkit.org/show_bug.cgi?id=153246
Reviewed by Geoffrey Garen.
Moving an immediate to memory is not a valid instruction on ARM64.
This patch adds a small workaround for this specific case: an instruction
to zero a chunk of memory.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::storeZero32):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::storeZero32):
* b3/air/AirFixSpillSlotZDef.h:
(JSC::B3::Air::fixSpillSlotZDef):
* b3/air/AirOpcode.opcodes:
2016-01-19 Enrica Casucci <enrica@apple.com>
Add support for DataDetectors in WK (iOS).
https://bugs.webkit.org/show_bug.cgi?id=152989
rdar://problem/22855960
Reviewed by Tim Horton.
Adding feature definition for data detection.
* Configurations/FeatureDefines.xcconfig:
2016-01-19 Per Arne Vollan <peavo@outlook.com>
[B3][Win64] Compile and warning fixes.
https://bugs.webkit.org/show_bug.cgi?id=153234
Reviewed by Alex Christensen.
The size of 'long' is 4 bytes on Win64. We can use 'long long' instead,
when we want the size to be 8 bytes.
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3ReduceStrength.cpp:
2016-01-19 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Fix the B3 build after r195159
https://bugs.webkit.org/show_bug.cgi?id=153232
Reviewed by Yusuke Suzuki.
* CMakeLists.txt:
2016-01-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r195300.
https://bugs.webkit.org/show_bug.cgi?id=153244
enrica wants more time to fix Windows (Requested by thorton on
#webkit).
Reverted changeset:
"Add support for DataDetectors in WK (iOS)."
https://bugs.webkit.org/show_bug.cgi?id=152989
http://trac.webkit.org/changeset/195300
2016-01-19 Filip Pizlo <fpizlo@apple.com>
Reconsider B3's constant motion policy
https://bugs.webkit.org/show_bug.cgi?id=152202
Reviewed by Geoffrey Garen.
This changes moveConstants() to hoist constants. This is a speed-up on things like mandreel.
It has a generally positive impact on the Octane score, but it's within margin of error.
This also changes IRC to make it a bit more likely to spill constants. We don't want it to
spill them too much, because we can't rely on fixObviousSpills() to always replace a load of
a constant from the stack with the constant itself, especially in case of instructions that
need an extra register to materialize the immediate.
Also fixed DFG graph dumping to print a bit less things. It was trying to print the results of
constant property inference, and this sometimes caused crashes when you dumped the graph at an
inopportune time.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3MoveConstants.cpp:
* b3/air/AirArg.h:
* b3/air/AirArgInlines.h: Added.
(JSC::B3::Air::ArgThingHelper<Tmp>::is):
(JSC::B3::Air::ArgThingHelper<Tmp>::as):
(JSC::B3::Air::ArgThingHelper<Tmp>::forEachFast):
(JSC::B3::Air::ArgThingHelper<Tmp>::forEach):
(JSC::B3::Air::ArgThingHelper<Arg>::is):
(JSC::B3::Air::ArgThingHelper<Arg>::as):
(JSC::B3::Air::ArgThingHelper<Arg>::forEachFast):
(JSC::B3::Air::ArgThingHelper<Arg>::forEach):
(JSC::B3::Air::Arg::is):
(JSC::B3::Air::Arg::as):
(JSC::B3::Air::Arg::forEachFast):
(JSC::B3::Air::Arg::forEach):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirUseCounts.h:
(JSC::B3::Air::UseCounts::UseCounts):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
2016-01-19 Enrica Casucci <enrica@apple.com>
Add support for DataDetectors in WK (iOS).
https://bugs.webkit.org/show_bug.cgi?id=152989
rdar://problem/22855960
Reviewed by Tim Horton.
Adding feature definition.
* Configurations/FeatureDefines.xcconfig:
2016-01-17 Filip Pizlo <fpizlo@apple.com>
FTL B3 should be just as fast as FTL LLVM on Octane/crypto
https://bugs.webkit.org/show_bug.cgi?id=153113
Reviewed by Saam Barati.
This is the result of a hacking rampage to close the gap between FTL B3 and FTL LLVM on
Octane/crypto. It was a very successful rampage.
The biggest change in this patch is the introduction of a phase called fixObviousSpills()
that fixes patterns like:
Store register to stack slot and then use stack slot:
Move %rcx, (stack42)
Foo use:(stack42) // replace (stack42) with %rcx here.
Load stack slot into register and then use stack slot:
Move (stack42), %rcx
Foo use:(stack42) // replace (stack42) with %rcx here.
Store constant into stack slot and then use stack slot:
Move $42, %rcx
Move %rcx, (stack42)
Bar def:%rcx // %rcx isn't available anymore, but we still know that (stack42) is $42
Foo use:(stack42) // replace (stack42) with $42 here.
This phases does these fixups by doing a global forward flow that propagates sets of
must-aliases.
Also added a phase to report register pressure. It pretty-prints code alongside the set of
in-use registers above each instruction. Using this phase, I found that our register
allocator is actually doing a pretty awesome job. I had previously feared that we'd have to
make substantial changes to register allocation. I don't have such a fear anymore, at least
for Octane/crypto. In the future, we can check how the regalloc is performing just by
enabling logAirRegisterPressure.
Also fixed some FTL codegen pathologies. We were using bitOr where we meant to use a
conditional or. LLVM likes to canonicalize boolean expressions this way. B3, on the other
hand, doesn't do this canonicalization and doesn't have logic to decompose it into sequences
of branches.
Also added strength reductions for checked arithmetic. It turns out that LLVM learned how to
reduce checked multiply to unchecked multiply in some obvious cases that our existing DFG
optimizations lacked. Ideally, our DFG integer range optimization phase would cover this. But
the cases of interest were dead simple - the incoming values to the CheckMul were obviously
too small to cause overflow. I added such reasoning to B3's strength reduction.
Finally, this fixes some bugs with how we were handling subwidth spill slots. The register
allocator was making two mistakes. First, it might cause a Width64 def or use of a 4-byte
spill slot. In that case, it would extend the size of the spill slot to ensure that the use
or def is safe. Second, it emulates ZDef on Tmp behavior by emitting a Move32 to initialize
the high bits of a spill slot. But this is unsound because of the liveness semantics of spill
slots. They cannot have more than one def to initialize their value. I fixed that by making
allocateStack() be the thing that fixes ZDefs. That's a change to ZDef semantics: now, ZDef
on an anonymous stack slot means that the high bits are zero-filled. I wasn't able to
construct a test for this. It might be a hypothetical bug, but still, I like how this
simplifies the register allocator.
This is a ~0.7% speed-up on Octane.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::hiddenBranch):
(JSC::B3::CheckSpecial::forEachArg):
(JSC::B3::CheckSpecial::commitHiddenBranch): Deleted.
* b3/B3CheckSpecial.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::fillStackmap):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3StackmapValue.h:
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirAllocateStack.h:
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::callArg):
(JSC::B3::Air::Arg::stackAddr):
(JSC::B3::Air::Arg::isValidScale):
* b3/air/AirBasicBlock.cpp:
(JSC::B3::Air::BasicBlock::deepDump):
(JSC::B3::Air::BasicBlock::dumpHeader):
(JSC::B3::Air::BasicBlock::dumpFooter):
* b3/air/AirBasicBlock.h:
* b3/air/AirCCallSpecial.cpp:
(JSC::B3::Air::CCallSpecial::CCallSpecial):
(JSC::B3::Air::CCallSpecial::~CCallSpecial):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::lastPhaseName):
(JSC::B3::Air::Code::setEnableRCRS):
(JSC::B3::Air::Code::enableRCRS):
* b3/air/AirCustom.cpp:
(JSC::B3::Air::PatchCustom::isValidForm):
(JSC::B3::Air::CCallCustom::isValidForm):
* b3/air/AirCustom.h:
(JSC::B3::Air::PatchCustom::isValidFormStatic):
(JSC::B3::Air::PatchCustom::admitsStack):
(JSC::B3::Air::PatchCustom::isValidForm): Deleted.
* b3/air/AirEmitShuffle.cpp:
(JSC::B3::Air::ShufflePair::dump):
(JSC::B3::Air::createShuffle):
(JSC::B3::Air::emitShuffle):
* b3/air/AirEmitShuffle.h:
* b3/air/AirFixObviousSpills.cpp: Added.
(JSC::B3::Air::fixObviousSpills):
* b3/air/AirFixObviousSpills.h: Added.
* b3/air/AirFixSpillSlotZDef.h: Removed.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
(JSC::B3::Air::generate):
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirInst.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::reportUsedRegisters):
(JSC::B3::Air::Inst::admitsStack):
(JSC::B3::Air::isShiftValid):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirLiveness.h:
(JSC::B3::Air::AbstractLiveness::AbstractLiveness):
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::begin):
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::end):
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::contains):
(JSC::B3::Air::AbstractLiveness::LocalCalc::live):
(JSC::B3::Air::AbstractLiveness::LocalCalc::isLive):
(JSC::B3::Air::AbstractLiveness::LocalCalc::execute):
(JSC::B3::Air::AbstractLiveness::rawLiveAtHead):
(JSC::B3::Air::AbstractLiveness::Iterable::begin):
(JSC::B3::Air::AbstractLiveness::Iterable::end):
(JSC::B3::Air::AbstractLiveness::Iterable::contains):
(JSC::B3::Air::AbstractLiveness::liveAtTail):
(JSC::B3::Air::AbstractLiveness::workset):
* b3/air/AirLogRegisterPressure.cpp: Added.
(JSC::B3::Air::logRegisterPressure):
* b3/air/AirLogRegisterPressure.h: Added.
* b3/air/AirOptimizeBlockOrder.cpp:
(JSC::B3::Air::blocksInOptimizedOrder):
(JSC::B3::Air::optimizeBlockOrder):
* b3/air/AirOptimizeBlockOrder.h:
* b3/air/AirReportUsedRegisters.cpp:
(JSC::B3::Air::reportUsedRegisters):
* b3/air/AirReportUsedRegisters.h:
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/AirStackSlot.h:
(JSC::B3::Air::StackSlot::isLocked):
(JSC::B3::Air::StackSlot::index):
(JSC::B3::Air::StackSlot::ensureSize):
(JSC::B3::Air::StackSlot::alignment):
* b3/air/AirValidate.cpp:
* ftl/FTLB3Compile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMod):
* jit/RegisterSet.h:
(JSC::RegisterSet::get):
(JSC::RegisterSet::setAll):
(JSC::RegisterSet::merge):
(JSC::RegisterSet::filter):
* runtime/Options.h:
2016-01-19 Filip Pizlo <fpizlo@apple.com>
Unreviewed, undo unintended commit.
* dfg/DFGCommon.h:
2016-01-18 Filip Pizlo <fpizlo@apple.com>
Fix Air shuffling assertions
https://bugs.webkit.org/show_bug.cgi?id=153213
Reviewed by Saam Barati.
Fixes some assertions that I was seeing running JSC tests. Adds a new Air test.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::store8):
(JSC::MacroAssemblerX86Common::getUnusedRegister):
* b3/air/AirEmitShuffle.cpp:
(JSC::B3::Air::emitShuffle):
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/testair.cpp:
(JSC::B3::Air::testShuffleRotateWithFringe):
(JSC::B3::Air::testShuffleRotateWithFringeInWeirdOrder):
(JSC::B3::Air::testShuffleRotateWithLongFringe):
(JSC::B3::Air::run):
2016-01-19 Konstantin Tokarev <annulen@yandex.ru>
[mips] Logical instructions allow immediates in range 0..0xffff, not 0x7fff
https://bugs.webkit.org/show_bug.cgi?id=152693
Reviewed by Michael Saboff.
* offlineasm/mips.rb:
2016-01-18 Saam barati <sbarati@apple.com>
assertions in BytecodeUseDef.h about opcode length are off by one
https://bugs.webkit.org/show_bug.cgi?id=153215
Reviewed by Dan Bernstein.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
2016-01-18 Saam barati <sbarati@apple.com>
FTL doesn't do proper spilling for exception handling when GetById/Snippets go to slow path
https://bugs.webkit.org/show_bug.cgi?id=153186
Reviewed by Michael Saboff.
Michael was investigating a bug he found while doing the new JSC calling
convention work and it turns out to be a latent bug in FTL try/catch machinery.
After I looked at the code again, I realized that what I had previously
written is wrong in a subtle way. The FTL callOperation machinery will remove
its result register from the set of registers it needs to spill. This is not
correct when we have try/catch. We may want to do value recovery on
the value that the result register is prior to the call after the call
throws an exception. The case that we were solving before was when the
resultRegister == baseRegister in a GetById, or left/rightRegister == resultRegister in a Snippet.
This code is correct in wanting to spill in that case, even though it might spill
when we don't need it to (i.e the result is not needed for value recovery). Once I
investigated this bug further, I realized that the previous rule is just a
partial subset of the rule that says we should spill anytime the result is
a register we might do value recovery on. This patch implements the rule that
says we always want to spill the result when we will do value recovery on it
if an exception is thrown.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* tests/stress/ftl-try-catch-getter-throw-interesting-value-recovery.js: Added.
(assert):
(random):
(identity):
(let.o2.get f):
(let.o3.get f):
(foo):
(i.else):
2016-01-18 Konstantin Tokarev <annulen@yandex.ru>
[MIPS] LLInt: fix calculation of Global Offset Table
https://bugs.webkit.org/show_bug.cgi?id=150381
Offlineasm adds a .cpload $t9 when we create a label in MIPS, which
computes address of GOT. However, this instruction requires $t9 to
contain address of current function. So we need to set $t9 to pcBase,
otherwise GOT-related calculations will be invalid.
Since offlineasm does not allow direct move to $t9 on MIPS, added new
instruction setcallreg which does exactly that.
Reviewed by Michael Saboff.
* llint/LowLevelInterpreter.asm:
* offlineasm/instructions.rb:
* offlineasm/mips.rb:
2016-01-18 Csaba Osztrogonác <ossy@webkit.org>
REGRESSION(r194601): Fix the jsc timeout option of jsc.cpp
https://bugs.webkit.org/show_bug.cgi?id=153204
Reviewed by Michael Catanzaro.
* jsc.cpp:
(main):
2016-01-18 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Add testair to the build system
https://bugs.webkit.org/show_bug.cgi?id=153126
Reviewed by Michael Catanzaro.
* shell/CMakeLists.txt:
2016-01-17 Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Ensure that CF_AVAILABLE is undefined when building webkit-gtk
https://bugs.webkit.org/show_bug.cgi?id=152720
This change ensures that CF_AVAILABLE is correctly a no-op to
address build failure that was observed when building on older
versions of OSX. Previously, CF_AVAILABLE may have been unexpectedly
re-defined to the system header value based on include-order.
Reviewed by Michael Catanzaro.
* API/WebKitAvailability.h:
2016-01-17 Julien Brianceau <jbriance@cisco.com>
[mips] Fix regT2 and regT3 trampling in MacroAssembler
https://bugs.webkit.org/show_bug.cgi?id=153131
Mips $t2 and $t3 registers were used as temporary registers
in MacroAssemblerMIPS.h, whereas they are mapped to regT2
and regT3 in LLInt and GPRInfo.
This patch rearranges register mapping for the mips architecture:
- use $t0 and $t1 as temp registers in LLInt (as in MacroAssembler)
- use $t7 and $t8 as temp registers in MacroAssembler (as in LLInt)
- remove $t6 from temp registers list in LLInt
- update GPRInfo.h accordingly
- add mips macroScratchRegisters() list in RegisterSet.cpp
Reviewed by Michael Saboff.
* assembler/MacroAssemblerMIPS.h:
* jit/GPRInfo.h:
(JSC::GPRInfo::toRegister):
(JSC::GPRInfo::toIndex):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::macroScratchRegisters):
(JSC::RegisterSet::calleeSaveRegisters):
* offlineasm/mips.rb:
2016-01-16 Skachkov Oleksandr <gskachkov@gmail.com>
[ES6] Arrow function syntax. Arrow function should support the destructuring parameters.
https://bugs.webkit.org/show_bug.cgi?id=146934
Reviewed by Saam Barati.
Added support of destructuring parameters, before arrow function expect only simple parameters,
e.g. (), (x), (x, y) or x in assigment expressio. To support destructuring parameters added
additional check that check for destructuring paramters if check does not pass for simple parameters.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::isArrowFunctionParameters):
(JSC::Parser<LexerType>::parseAssignmentExpression):
* parser/Parser.h:
2016-01-15 Benjamin Poulain <bpoulain@apple.com>
[JSC] Legalize Memory Offsets for ARM64 before lowering to Air
https://bugs.webkit.org/show_bug.cgi?id=153065
Reviewed by Mark Lam.
Reviewed by Filip Pizlo.
On ARM64, we cannot use signed 32bits offset for memory addressing.
There are two available addressing: signed 9bits and unsigned scaled 12bits.
Air already knows about it.
In this patch, the offsets are changed to something valid for ARM64
prior to lowering. When an offset is invalid, it is just computed
before the instruction and used as the base for addressing.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3LegalizeMemoryOffsets.cpp: Added.
(JSC::B3::legalizeMemoryOffsets):
* b3/B3LegalizeMemoryOffsets.h: Added.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::effectiveAddr): Deleted.
* b3/testb3.cpp:
(JSC::B3::testLoadWithOffsetImpl):
(JSC::B3::testLoadOffsetImm9Max):
(JSC::B3::testLoadOffsetImm9MaxPlusOne):
(JSC::B3::testLoadOffsetImm9MaxPlusTwo):
(JSC::B3::testLoadOffsetImm9Min):
(JSC::B3::testLoadOffsetImm9MinMinusOne):
(JSC::B3::testLoadOffsetScaledUnsignedImm12Max):
(JSC::B3::testLoadOffsetScaledUnsignedOverImm12Max):
(JSC::B3::run):
2016-01-15 Alex Christensen <achristensen@webkit.org>
Fix internal Windows build
https://bugs.webkit.org/show_bug.cgi?id=153142
Reviewed by Brent Fulgham.
The internal Windows build builds JavaScriptCore from a directory that is not called JavaScriptCore.
Searching for JavaScriptCore/API/APICast.h fails because it is in SomethingElse/API/APICast.h.
Since we are including the JavaScriptCore directory, it is not necessary to have JavaScriptCore in
the forwarding headers, but removing it allows builds form directories that are not named JavaScriptCore.
* ForwardingHeaders/JavaScriptCore/APICast.h:
* ForwardingHeaders/JavaScriptCore/JSBase.h:
* ForwardingHeaders/JavaScriptCore/JSCTestRunnerUtils.h:
* ForwardingHeaders/JavaScriptCore/JSContextRef.h:
* ForwardingHeaders/JavaScriptCore/JSObjectRef.h:
* ForwardingHeaders/JavaScriptCore/JSRetainPtr.h:
* ForwardingHeaders/JavaScriptCore/JSStringRef.h:
* ForwardingHeaders/JavaScriptCore/JSStringRefCF.h:
* ForwardingHeaders/JavaScriptCore/JSValueRef.h:
* ForwardingHeaders/JavaScriptCore/JavaScript.h:
* ForwardingHeaders/JavaScriptCore/JavaScriptCore.h:
* ForwardingHeaders/JavaScriptCore/OpaqueJSString.h:
* ForwardingHeaders/JavaScriptCore/WebKitAvailability.h:
2016-01-15 Per Arne Vollan <peavo@outlook.com>
[B3][Win64] Compile fixes.
https://bugs.webkit.org/show_bug.cgi?id=153127
Reviewed by Alex Christensen.
MSVC have several overloads of fmod, pow, and ceil. We need to suggest to MSVC
which one we want to use.
* b3/B3LowerMacros.cpp:
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3MathExtras.cpp:
(JSC::B3::powDoubleInt32):
* b3/B3ReduceStrength.cpp:
2016-01-15 Filip Pizlo <fpizlo@apple.com>
Air needs a Shuffle instruction
https://bugs.webkit.org/show_bug.cgi?id=152952
Reviewed by Saam Barati.
This adds an instruction called Shuffle. Shuffle allows you to simultaneously perform
multiple moves to perform arbitrary permutations over registers and memory. We call these
rotations. It also allows you to perform "shifts", like (a => b, b => c): after the shift,
c will have b's old value, b will have a's old value, and a will be unchanged. Shifts can
use immediates as their source.
Shuffle is added as a custom instruction, since it has a variable number of arguments. It
takes any number of triplets of arguments, where each triplet describes one mapping of the
shuffle. For example, to represent (a => b, b => c), we might say:
Shuffle %a, %b, 64, %b, %c, 64
Note the "64"s, those are width arguments that describe how many bits of the register are
being moved. Each triplet is referred to as a "shuffle pair". We call it a pair because the
most relevant part of it is the pair of registers or memroy locations (i.e. %a, %b form one
of the pairs in the example). For GP arguments, the width follows ZDef semantics.
In the future, we will be able to use Shuffle for a lot of things. This patch is modest about
how to use it:
- C calling convention argument marshalling. Previously we used move instructions. But that's
problematic since it introduces artificial interference between the argument registers and
the inputs. Using Shuffle removes that interference. This helps a bit.
- Cold C calls. This is what really motivated me to write this patch. If we have a C call on
a cold path, then we want it to appear to the register allocator like it doesn't clobber
any registers. Only after register allocation should we handle the clobbering by simply
saving all of the live volatile registers to the stack. If you imagine the saving and the
argument marshalling, you can see how before the call, we want to have a Shuffle that does
both of those things. This is important. If argument marshalling was separate from the
saving, then we'd still appear to clobber argument registers. Doing them together as one
Shuffle means that the cold call doesn't appear to even clobber the argument registers.
Unfortunately, I was wrong about cold C calls being the dominant problem with our register
allocator right now. Fixing this revealed other problems in my current tuning benchmark,
Octane/encrypt. Nonetheless, this is a small speed-up across the board, and gives us some
functionality we will need to implement other optimizations.
Relanding after fixing production build.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::isX86_64):
(JSC::isIOS):
(JSC::optimizeForARMv7IDIVSupported):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::zeroExtend32ToPtr):
(JSC::MacroAssemblerX86Common::swap32):
(JSC::MacroAssemblerX86Common::moveConditionally32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch):
(JSC::MacroAssemblerX86_64::swap64):
(JSC::MacroAssemblerX86_64::move64ToDouble):
* assembler/X86Assembler.h:
(JSC::X86Assembler::xchgl_rr):
(JSC::X86Assembler::xchgl_rm):
(JSC::X86Assembler::xchgq_rr):
(JSC::X86Assembler::xchgq_rm):
(JSC::X86Assembler::movl_rr):
* b3/B3CCallValue.h:
* b3/B3Compilation.cpp:
(JSC::B3::Compilation::Compilation):
(JSC::B3::Compilation::~Compilation):
* b3/B3Compilation.h:
(JSC::B3::Compilation::code):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::createSelect):
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::marshallCCallArgument): Deleted.
* b3/B3OpaqueByproducts.h:
(JSC::B3::OpaqueByproducts::count):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::isArgValidForValue):
(JSC::B3::StackmapSpecial::isArgValidForRep):
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::isStackMemory):
(JSC::B3::Air::Arg::isRepresentableAs):
(JSC::B3::Air::Arg::usesTmp):
(JSC::B3::Air::Arg::canRepresent):
(JSC::B3::Air::Arg::isCompatibleType):
(JSC::B3::Air::Arg::dump):
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::forEachType):
(JSC::B3::Air::Arg::isWarmUse):
(JSC::B3::Air::Arg::cooled):
(JSC::B3::Air::Arg::isEarlyUse):
(JSC::B3::Air::Arg::imm64):
(JSC::B3::Air::Arg::immPtr):
(JSC::B3::Air::Arg::addr):
(JSC::B3::Air::Arg::special):
(JSC::B3::Air::Arg::widthArg):
(JSC::B3::Air::Arg::operator==):
(JSC::B3::Air::Arg::isImm64):
(JSC::B3::Air::Arg::isSomeImm):
(JSC::B3::Air::Arg::isAddr):
(JSC::B3::Air::Arg::isIndex):
(JSC::B3::Air::Arg::isMemory):
(JSC::B3::Air::Arg::isRelCond):
(JSC::B3::Air::Arg::isSpecial):
(JSC::B3::Air::Arg::isWidthArg):
(JSC::B3::Air::Arg::isAlive):
(JSC::B3::Air::Arg::base):
(JSC::B3::Air::Arg::hasOffset):
(JSC::B3::Air::Arg::offset):
(JSC::B3::Air::Arg::width):
(JSC::B3::Air::Arg::isGPTmp):
(JSC::B3::Air::Arg::isGP):
(JSC::B3::Air::Arg::isFP):
(JSC::B3::Air::Arg::isType):
(JSC::B3::Air::Arg::isGPR):
(JSC::B3::Air::Arg::isValidForm):
(JSC::B3::Air::Arg::forEachTmpFast):
* b3/air/AirBasicBlock.h:
(JSC::B3::Air::BasicBlock::insts):
(JSC::B3::Air::BasicBlock::appendInst):
(JSC::B3::Air::BasicBlock::append):
* b3/air/AirCCallingConvention.cpp: Added.
(JSC::B3::Air::computeCCallingConvention):
(JSC::B3::Air::cCallResult):
(JSC::B3::Air::buildCCall):
* b3/air/AirCCallingConvention.h: Added.
* b3/air/AirCode.h:
(JSC::B3::Air::Code::proc):
* b3/air/AirCustom.cpp: Added.
(JSC::B3::Air::CCallCustom::isValidForm):
(JSC::B3::Air::CCallCustom::generate):
(JSC::B3::Air::ShuffleCustom::isValidForm):
(JSC::B3::Air::ShuffleCustom::generate):
* b3/air/AirCustom.h:
(JSC::B3::Air::PatchCustom::forEachArg):
(JSC::B3::Air::PatchCustom::generate):
(JSC::B3::Air::CCallCustom::forEachArg):
(JSC::B3::Air::CCallCustom::isValidFormStatic):
(JSC::B3::Air::CCallCustom::admitsStack):
(JSC::B3::Air::CCallCustom::hasNonArgNonControlEffects):
(JSC::B3::Air::ColdCCallCustom::forEachArg):
(JSC::B3::Air::ShuffleCustom::forEachArg):
(JSC::B3::Air::ShuffleCustom::isValidFormStatic):
(JSC::B3::Air::ShuffleCustom::admitsStack):
(JSC::B3::Air::ShuffleCustom::hasNonArgNonControlEffects):
* b3/air/AirEmitShuffle.cpp: Added.
(JSC::B3::Air::ShufflePair::dump):
(JSC::B3::Air::emitShuffle):
* b3/air/AirEmitShuffle.h: Added.
(JSC::B3::Air::ShufflePair::ShufflePair):
(JSC::B3::Air::ShufflePair::src):
(JSC::B3::Air::ShufflePair::dst):
(JSC::B3::Air::ShufflePair::width):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* b3/air/AirGenerate.h:
* b3/air/AirInsertionSet.cpp:
(JSC::B3::Air::InsertionSet::insertInsts):
(JSC::B3::Air::InsertionSet::execute):
* b3/air/AirInsertionSet.h:
(JSC::B3::Air::InsertionSet::insertInst):
(JSC::B3::Air::InsertionSet::insert):
* b3/air/AirInst.h:
(JSC::B3::Air::Inst::operator bool):
(JSC::B3::Air::Inst::append):
* b3/air/AirLowerAfterRegAlloc.cpp: Added.
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirLowerAfterRegAlloc.h: Added.
* b3/air/AirLowerMacros.cpp: Added.
(JSC::B3::Air::lowerMacros):
* b3/air/AirLowerMacros.h: Added.
* b3/air/AirOpcode.opcodes:
* b3/air/AirRegisterPriority.h:
(JSC::B3::Air::regsInPriorityOrder):
* b3/air/testair.cpp: Added.
(hiddenTruthBecauseNoReturnIsStupid):
(usage):
(JSC::B3::Air::compile):
(JSC::B3::Air::invoke):
(JSC::B3::Air::compileAndRun):
(JSC::B3::Air::testSimple):
(JSC::B3::Air::loadConstantImpl):
(JSC::B3::Air::loadConstant):
(JSC::B3::Air::loadDoubleConstant):
(JSC::B3::Air::testShuffleSimpleSwap):
(JSC::B3::Air::testShuffleSimpleShift):
(JSC::B3::Air::testShuffleLongShift):
(JSC::B3::Air::testShuffleLongShiftBackwards):
(JSC::B3::Air::testShuffleSimpleRotate):
(JSC::B3::Air::testShuffleSimpleBroadcast):
(JSC::B3::Air::testShuffleBroadcastAllRegs):
(JSC::B3::Air::testShuffleTreeShift):
(JSC::B3::Air::testShuffleTreeShiftBackward):
(JSC::B3::Air::testShuffleTreeShiftOtherBackward):
(JSC::B3::Air::testShuffleMultipleShifts):
(JSC::B3::Air::testShuffleRotateWithFringe):
(JSC::B3::Air::testShuffleRotateWithLongFringe):
(JSC::B3::Air::testShuffleMultipleRotates):
(JSC::B3::Air::testShuffleShiftAndRotate):
(JSC::B3::Air::testShuffleShiftAllRegs):
(JSC::B3::Air::testShuffleRotateAllRegs):
(JSC::B3::Air::testShuffleSimpleSwap64):
(JSC::B3::Air::testShuffleSimpleShift64):
(JSC::B3::Air::testShuffleSwapMixedWidth):
(JSC::B3::Air::testShuffleShiftMixedWidth):
(JSC::B3::Air::testShuffleShiftMemory):
(JSC::B3::Air::testShuffleShiftMemoryLong):
(JSC::B3::Air::testShuffleShiftMemoryAllRegs):
(JSC::B3::Air::testShuffleShiftMemoryAllRegs64):
(JSC::B3::Air::combineHiLo):
(JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth):
(JSC::B3::Air::testShuffleRotateMemory):
(JSC::B3::Air::testShuffleRotateMemory64):
(JSC::B3::Air::testShuffleRotateMemoryMixedWidth):
(JSC::B3::Air::testShuffleRotateMemoryAllRegs64):
(JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth):
(JSC::B3::Air::testShuffleSwapDouble):
(JSC::B3::Air::testShuffleShiftDouble):
(JSC::B3::Air::run):
(run):
(main):
* b3/testb3.cpp:
(JSC::B3::testCallSimple):
(JSC::B3::testCallRare):
(JSC::B3::testCallRareLive):
(JSC::B3::testCallSimplePure):
(JSC::B3::run):
2016-01-15 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement Date.prototype.toLocaleString in ECMA-402
https://bugs.webkit.org/show_bug.cgi?id=147611
Reviewed by Benjamin Poulain.
Expose dateProtoFuncGetTime as thisTimeValue for builtins.
Remove unused code in DateTimeFormat toDateTimeOptions, and make the
function specific to the call in initializeDateTimeFormat. Properly
throw when the options parameter is null.
Add toLocaleString in builtin JavaScript, with it's own specific branch
of toDateTimeOptions.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/DatePrototype.js: Added.
(toLocaleString.toDateTimeOptionsAnyAll):
(toLocaleString):
* runtime/CommonIdentifiers.h:
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
* runtime/DatePrototype.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::toDateTimeOptionsAnyDate):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::toDateTimeOptions): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2016-01-15 Konstantin Tokarev <annulen@yandex.ru>
[mips] Implemented emitFunctionPrologue/Epilogue
https://bugs.webkit.org/show_bug.cgi?id=152947
Reviewed by Michael Saboff.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::popPair):
(JSC::MacroAssemblerMIPS::pushPair):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitFunctionPrologue):
(JSC::AssemblyHelpers::emitFunctionEpilogueWithEmptyFrame):
(JSC::AssemblyHelpers::emitFunctionEpilogue):
2016-01-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r195084.
https://bugs.webkit.org/show_bug.cgi?id=153132
Broke Production build (Requested by ap on #webkit).
Reverted changeset:
"Air needs a Shuffle instruction"
https://bugs.webkit.org/show_bug.cgi?id=152952
http://trac.webkit.org/changeset/195084
2016-01-15 Julien Brianceau <jbriance@cisco.com>
[mips] Add countLeadingZeros32 implementation in macro assembler
https://bugs.webkit.org/show_bug.cgi?id=152886
Reviewed by Michael Saboff.
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::lui):
(JSC::MIPSAssembler::clz):
(JSC::MIPSAssembler::addiu):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::and32):
(JSC::MacroAssemblerMIPS::countLeadingZeros32):
(JSC::MacroAssemblerMIPS::lshift32):
2016-01-14 Filip Pizlo <fpizlo@apple.com>
Air needs a Shuffle instruction
https://bugs.webkit.org/show_bug.cgi?id=152952
Reviewed by Saam Barati.
This adds an instruction called Shuffle. Shuffle allows you to simultaneously perform
multiple moves to perform arbitrary permutations over registers and memory. We call these
rotations. It also allows you to perform "shifts", like (a => b, b => c): after the shift,
c will have b's old value, b will have a's old value, and a will be unchanged. Shifts can
use immediates as their source.
Shuffle is added as a custom instruction, since it has a variable number of arguments. It
takes any number of triplets of arguments, where each triplet describes one mapping of the
shuffle. For example, to represent (a => b, b => c), we might say:
Shuffle %a, %b, 64, %b, %c, 64
Note the "64"s, those are width arguments that describe how many bits of the register are
being moved. Each triplet is referred to as a "shuffle pair". We call it a pair because the
most relevant part of it is the pair of registers or memroy locations (i.e. %a, %b form one
of the pairs in the example). For GP arguments, the width follows ZDef semantics.
In the future, we will be able to use Shuffle for a lot of things. This patch is modest about
how to use it:
- C calling convention argument marshalling. Previously we used move instructions. But that's
problematic since it introduces artificial interference between the argument registers and
the inputs. Using Shuffle removes that interference. This helps a bit.
- Cold C calls. This is what really motivated me to write this patch. If we have a C call on
a cold path, then we want it to appear to the register allocator like it doesn't clobber
any registers. Only after register allocation should we handle the clobbering by simply
saving all of the live volatile registers to the stack. If you imagine the saving and the
argument marshalling, you can see how before the call, we want to have a Shuffle that does
both of those things. This is important. If argument marshalling was separate from the
saving, then we'd still appear to clobber argument registers. Doing them together as one
Shuffle means that the cold call doesn't appear to even clobber the argument registers.
Unfortunately, I was wrong about cold C calls being the dominant problem with our register
allocator right now. Fixing this revealed other problems in my current tuning benchmark,
Octane/encrypt. Nonetheless, this is a small speed-up across the board, and gives us some
functionality we will need to implement other optimizations.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::isX86_64):
(JSC::isIOS):
(JSC::optimizeForARMv7IDIVSupported):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::zeroExtend32ToPtr):
(JSC::MacroAssemblerX86Common::swap32):
(JSC::MacroAssemblerX86Common::moveConditionally32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch):
(JSC::MacroAssemblerX86_64::swap64):
(JSC::MacroAssemblerX86_64::move64ToDouble):
* assembler/X86Assembler.h:
(JSC::X86Assembler::xchgl_rr):
(JSC::X86Assembler::xchgl_rm):
(JSC::X86Assembler::xchgq_rr):
(JSC::X86Assembler::xchgq_rm):
(JSC::X86Assembler::movl_rr):
* b3/B3CCallValue.h:
* b3/B3Compilation.cpp:
(JSC::B3::Compilation::Compilation):
(JSC::B3::Compilation::~Compilation):
* b3/B3Compilation.h:
(JSC::B3::Compilation::code):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::createSelect):
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::marshallCCallArgument): Deleted.
* b3/B3OpaqueByproducts.h:
(JSC::B3::OpaqueByproducts::count):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::isArgValidForValue):
(JSC::B3::StackmapSpecial::isArgValidForRep):
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::isStackMemory):
(JSC::B3::Air::Arg::isRepresentableAs):
(JSC::B3::Air::Arg::usesTmp):
(JSC::B3::Air::Arg::canRepresent):
(JSC::B3::Air::Arg::isCompatibleType):
(JSC::B3::Air::Arg::dump):
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::forEachType):
(JSC::B3::Air::Arg::isWarmUse):
(JSC::B3::Air::Arg::cooled):
(JSC::B3::Air::Arg::isEarlyUse):
(JSC::B3::Air::Arg::imm64):
(JSC::B3::Air::Arg::immPtr):
(JSC::B3::Air::Arg::addr):
(JSC::B3::Air::Arg::special):
(JSC::B3::Air::Arg::widthArg):
(JSC::B3::Air::Arg::operator==):
(JSC::B3::Air::Arg::isImm64):
(JSC::B3::Air::Arg::isSomeImm):
(JSC::B3::Air::Arg::isAddr):
(JSC::B3::Air::Arg::isIndex):
(JSC::B3::Air::Arg::isMemory):
(JSC::B3::Air::Arg::isRelCond):
(JSC::B3::Air::Arg::isSpecial):
(JSC::B3::Air::Arg::isWidthArg):
(JSC::B3::Air::Arg::isAlive):
(JSC::B3::Air::Arg::base):
(JSC::B3::Air::Arg::hasOffset):
(JSC::B3::Air::Arg::offset):
(JSC::B3::Air::Arg::width):
(JSC::B3::Air::Arg::isGPTmp):
(JSC::B3::Air::Arg::isGP):
(JSC::B3::Air::Arg::isFP):
(JSC::B3::Air::Arg::isType):
(JSC::B3::Air::Arg::isGPR):
(JSC::B3::Air::Arg::isValidForm):
(JSC::B3::Air::Arg::forEachTmpFast):
* b3/air/AirBasicBlock.h:
(JSC::B3::Air::BasicBlock::insts):
(JSC::B3::Air::BasicBlock::appendInst):
(JSC::B3::Air::BasicBlock::append):
* b3/air/AirCCallingConvention.cpp: Added.
(JSC::B3::Air::computeCCallingConvention):
(JSC::B3::Air::cCallResult):
(JSC::B3::Air::buildCCall):
* b3/air/AirCCallingConvention.h: Added.
* b3/air/AirCode.h:
(JSC::B3::Air::Code::proc):
* b3/air/AirCustom.cpp: Added.
(JSC::B3::Air::CCallCustom::isValidForm):
(JSC::B3::Air::CCallCustom::generate):
(JSC::B3::Air::ShuffleCustom::isValidForm):
(JSC::B3::Air::ShuffleCustom::generate):
* b3/air/AirCustom.h:
(JSC::B3::Air::PatchCustom::forEachArg):
(JSC::B3::Air::PatchCustom::generate):
(JSC::B3::Air::CCallCustom::forEachArg):
(JSC::B3::Air::CCallCustom::isValidFormStatic):
(JSC::B3::Air::CCallCustom::admitsStack):
(JSC::B3::Air::CCallCustom::hasNonArgNonControlEffects):
(JSC::B3::Air::ColdCCallCustom::forEachArg):
(JSC::B3::Air::ShuffleCustom::forEachArg):
(JSC::B3::Air::ShuffleCustom::isValidFormStatic):
(JSC::B3::Air::ShuffleCustom::admitsStack):
(JSC::B3::Air::ShuffleCustom::hasNonArgNonControlEffects):
* b3/air/AirEmitShuffle.cpp: Added.
(JSC::B3::Air::ShufflePair::dump):
(JSC::B3::Air::emitShuffle):
* b3/air/AirEmitShuffle.h: Added.
(JSC::B3::Air::ShufflePair::ShufflePair):
(JSC::B3::Air::ShufflePair::src):
(JSC::B3::Air::ShufflePair::dst):
(JSC::B3::Air::ShufflePair::width):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* b3/air/AirGenerate.h:
* b3/air/AirInsertionSet.cpp:
(JSC::B3::Air::InsertionSet::insertInsts):
(JSC::B3::Air::InsertionSet::execute):
* b3/air/AirInsertionSet.h:
(JSC::B3::Air::InsertionSet::insertInst):
(JSC::B3::Air::InsertionSet::insert):
* b3/air/AirInst.h:
(JSC::B3::Air::Inst::operator bool):
(JSC::B3::Air::Inst::append):
* b3/air/AirLowerAfterRegAlloc.cpp: Added.
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirLowerAfterRegAlloc.h: Added.
* b3/air/AirLowerMacros.cpp: Added.
(JSC::B3::Air::lowerMacros):
* b3/air/AirLowerMacros.h: Added.
* b3/air/AirOpcode.opcodes:
* b3/air/AirRegisterPriority.h:
(JSC::B3::Air::regsInPriorityOrder):
* b3/air/testair.cpp: Added.
(hiddenTruthBecauseNoReturnIsStupid):
(usage):
(JSC::B3::Air::compile):
(JSC::B3::Air::invoke):
(JSC::B3::Air::compileAndRun):
(JSC::B3::Air::testSimple):
(JSC::B3::Air::loadConstantImpl):
(JSC::B3::Air::loadConstant):
(JSC::B3::Air::loadDoubleConstant):
(JSC::B3::Air::testShuffleSimpleSwap):
(JSC::B3::Air::testShuffleSimpleShift):
(JSC::B3::Air::testShuffleLongShift):
(JSC::B3::Air::testShuffleLongShiftBackwards):
(JSC::B3::Air::testShuffleSimpleRotate):
(JSC::B3::Air::testShuffleSimpleBroadcast):
(JSC::B3::Air::testShuffleBroadcastAllRegs):
(JSC::B3::Air::testShuffleTreeShift):
(JSC::B3::Air::testShuffleTreeShiftBackward):
(JSC::B3::Air::testShuffleTreeShiftOtherBackward):
(JSC::B3::Air::testShuffleMultipleShifts):
(JSC::B3::Air::testShuffleRotateWithFringe):
(JSC::B3::Air::testShuffleRotateWithLongFringe):
(JSC::B3::Air::testShuffleMultipleRotates):
(JSC::B3::Air::testShuffleShiftAndRotate):
(JSC::B3::Air::testShuffleShiftAllRegs):
(JSC::B3::Air::testShuffleRotateAllRegs):
(JSC::B3::Air::testShuffleSimpleSwap64):
(JSC::B3::Air::testShuffleSimpleShift64):
(JSC::B3::Air::testShuffleSwapMixedWidth):
(JSC::B3::Air::testShuffleShiftMixedWidth):
(JSC::B3::Air::testShuffleShiftMemory):
(JSC::B3::Air::testShuffleShiftMemoryLong):
(JSC::B3::Air::testShuffleShiftMemoryAllRegs):
(JSC::B3::Air::testShuffleShiftMemoryAllRegs64):
(JSC::B3::Air::combineHiLo):
(JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth):
(JSC::B3::Air::testShuffleRotateMemory):
(JSC::B3::Air::testShuffleRotateMemory64):
(JSC::B3::Air::testShuffleRotateMemoryMixedWidth):
(JSC::B3::Air::testShuffleRotateMemoryAllRegs64):
(JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth):
(JSC::B3::Air::testShuffleSwapDouble):
(JSC::B3::Air::testShuffleShiftDouble):
(JSC::B3::Air::run):
(run):
(main):
* b3/testb3.cpp:
(JSC::B3::testCallSimple):
(JSC::B3::testCallRare):
(JSC::B3::testCallRareLive):
(JSC::B3::testCallSimplePure):
(JSC::B3::run):
2016-01-14 Keith Miller <keith_miller@apple.com>
Unreviewed mark passing es6 tests as no longer failing.
* tests/es6.yaml:
2016-01-14 Keith Miller <keith_miller@apple.com>
[ES6] Support subclassing Function.
https://bugs.webkit.org/show_bug.cgi?id=153081
Reviewed by Geoffrey Garen.
This patch enables subclassing the Function object. It also fixes an existing
bug that prevented users from subclassing functions that have a function in
the superclass's prototype property.
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
* runtime/FunctionConstructor.cpp:
(JSC::constructWithFunctionConstructor):
(JSC::constructFunction):
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionConstructor.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
* runtime/JSFunction.h:
(JSC::JSFunction::createImpl):
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
(JSC::JSFunction::JSFunction): Deleted.
* tests/stress/class-subclassing-function.js: Added.
2016-01-13 Carlos Garcia Campos <cgarcia@igalia.com>
[CMake] Do not use LLVM static libraries for FTL JIT
https://bugs.webkit.org/show_bug.cgi?id=151559
Reviewed by Michael Catanzaro.
Allow ports decide whether to prefer linking to llvm static or
dynamic libraries. This patch only changes the behavior of the GTK
port, other ports can change the default behavior by setting
llvmForJSC_LIBRARIES in their platform specific cmake files.
* CMakeLists.txt: Move llvmForJSC library definition after the
WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS, to allow platform specific
files to set their own llvmForJSC_LIBRARIES. When not set, it
defaults to LLVM_STATIC_LIBRARIES. The command to create
WebKitLLVMLibraryToken.h no longer depends on the static
libraries, since we are going to make the build fail anyway when
not found in case of linking to the static libraries. If platform
specific file defined llvmForJSC_INSTALL_DIR llvmForJSC is also
installed to the given destination.
* PlatformGTK.cmake: Set llvmForJSC_LIBRARIES and
llvmForJSC_INSTALL_DIR.
2016-01-13 Saam barati <sbarati@apple.com>
NativeExecutable should have a name field
https://bugs.webkit.org/show_bug.cgi?id=153083
Reviewed by Geoffrey Garen.
This is going to help the SamplingProfiler come up
with names for NativeExecutable objects it encounters.
* jit/JITThunks.cpp:
(JSC::JITThunks::finalize):
(JSC::JITThunks::hostFunctionStub):
* jit/JITThunks.h:
* runtime/Executable.h:
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::create):
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
(JSC::JSFunction::lookUpOrCreateNativeExecutable):
* runtime/JSFunction.h:
(JSC::JSFunction::createImpl):
* runtime/JSNativeStdFunction.cpp:
(JSC::JSNativeStdFunction::create):
* runtime/VM.cpp:
(JSC::thunkGeneratorForIntrinsic):
(JSC::VM::getHostFunction):
* runtime/VM.h:
(JSC::VM::getCTIStub):
(JSC::VM::exceptionOffset):
2016-01-13 Keith Miller <keith_miller@apple.com>
[ES6] Support subclassing the String builtin object
https://bugs.webkit.org/show_bug.cgi?id=153068
Reviewed by Michael Saboff.
This patch adds subclassing of strings. Also, this patch fixes a bug where we could have
the wrong indexing type for builtins constructed without storage.
* runtime/PrototypeMap.cpp:
(JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
* runtime/StringConstructor.cpp:
(JSC::constructWithStringConstructor):
* tests/stress/class-subclassing-string.js: Added.
(test):
2016-01-13 Mark Lam <mark.lam@apple.com>
The StringFromCharCode DFG intrinsic should support untyped operands.
https://bugs.webkit.org/show_bug.cgi?id=153046
Reviewed by Geoffrey Garen.
The current StringFromCharCode DFG intrinsic assumes that its operand charCode
must be an Int32. This results in 26000+ BadType OSR exits in the LongSpider
crypto-aes benchmark. With support for Untyped operands, the number of OSR
exits drops to 202.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileFromCharCode):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toUInt32):
2016-01-13 Mark Lam <mark.lam@apple.com>
Use DFG Graph::binary/unaryArithShouldSpeculateInt32/MachineInt() functions consistently.
https://bugs.webkit.org/show_bug.cgi?id=153080
Reviewed by Geoffrey Garen.
We currently have Graph::mulShouldSpeculateInt32/machineInt() and
Graph::negateShouldSpeculateInt32/MachineInt() functions which are only used by
the ArithMul and ArithNegate nodes. However, the same tests need to be done for
many other arith nodes in the DFG. This patch renames these functions as
Graph::binaryArithShouldSpeculateInt32/machineInt() and
Graph::unaryArithShouldSpeculateInt32/MachineInt(), and uses them consistently
in the DFG.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addShouldSpeculateMachineInt):
(JSC::DFG::Graph::binaryArithShouldSpeculateInt32):
(JSC::DFG::Graph::binaryArithShouldSpeculateMachineInt):
(JSC::DFG::Graph::unaryArithShouldSpeculateInt32):
(JSC::DFG::Graph::unaryArithShouldSpeculateMachineInt):
(JSC::DFG::Graph::mulShouldSpeculateInt32): Deleted.
(JSC::DFG::Graph::mulShouldSpeculateMachineInt): Deleted.
(JSC::DFG::Graph::negateShouldSpeculateInt32): Deleted.
(JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
(JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
2016-01-13 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Inspector should use the last sourceURL / sourceMappingURL directive
https://bugs.webkit.org/show_bug.cgi?id=153072
<rdar://problem/24168312>
Reviewed by Timothy Hatcher.
* parser/Lexer.cpp:
(JSC::Lexer<T>::parseCommentDirective):
Just keep overwriting the member variable so we end up with
the last directive value.
2016-01-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r194969.
https://bugs.webkit.org/show_bug.cgi?id=153075
This change broke the iOS build (Requested by ryanhaddad on
#webkit).
Reverted changeset:
"[JSC] Legalize Memory Offsets for ARM64 before lowering to
Air"
https://bugs.webkit.org/show_bug.cgi?id=153065
http://trac.webkit.org/changeset/194969
2016-01-13 Benjamin Poulain <bpoulain@apple.com>
[JSC] Legalize Memory Offsets for ARM64 before lowering to Air
https://bugs.webkit.org/show_bug.cgi?id=153065
Reviewed by Mark Lam.
Reviewed by Filip Pizlo.
On ARM64, we cannot use signed 32bits offset for memory addressing.
There are two available addressing: signed 9bits and unsigned scaled 12bits.
Air already knows about it.
In this patch, the offsets are changed to something valid for ARM64
prior to lowering. When an offset is invalid, it is just computed
before the instruction and used as the base for addressing.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3LegalizeMemoryOffsets.cpp: Added.
(JSC::B3::legalizeMemoryOffsets):
* b3/B3LegalizeMemoryOffsets.h: Added.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::effectiveAddr): Deleted.
* b3/testb3.cpp:
(JSC::B3::testLoadWithOffsetImpl):
(JSC::B3::testLoadOffsetImm9Max):
(JSC::B3::testLoadOffsetImm9MaxPlusOne):
(JSC::B3::testLoadOffsetImm9MaxPlusTwo):
(JSC::B3::testLoadOffsetImm9Min):
(JSC::B3::testLoadOffsetImm9MinMinusOne):
(JSC::B3::testLoadOffsetScaledUnsignedImm12Max):
(JSC::B3::testLoadOffsetScaledUnsignedOverImm12Max):
(JSC::B3::run):
2016-01-12 Per Arne Vollan <peavo@outlook.com>
[FTL][Win64] Compile error.
https://bugs.webkit.org/show_bug.cgi?id=153031
Reviewed by Brent Fulgham.
The header file dlfcn.h does not exist on Windows.
* ftl/FTLLowerDFGToLLVM.cpp:
2016-01-12 Ryosuke Niwa <rniwa@webkit.org>
Add a build flag for custom element
https://bugs.webkit.org/show_bug.cgi?id=153005
Reviewed by Alex Christensen.
* Configurations/FeatureDefines.xcconfig:
2016-01-12 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove some invalid immediate instruction forms from ARM64 Air
https://bugs.webkit.org/show_bug.cgi?id=153024
Reviewed by Michael Saboff.
* b3/B3BasicBlock.h:
Export the symbols for testb3.
* b3/air/AirOpcode.opcodes:
We had 2 invalid opcodes:
-Compare with immediate just does not exist.
-Test64 with immediate exists but Air does not recognize
the valid form of bit-immediates.
* b3/testb3.cpp:
(JSC::B3::genericTestCompare):
(JSC::B3::testCompareImpl):
Extend the tests to cover what was invalid.
2016-01-12 Benjamin Poulain <bpoulain@apple.com>
[JSC] JSC does not build with FTL_USES_B3 on ARM64
https://bugs.webkit.org/show_bug.cgi?id=153011
Reviewed by Saam Barati.
Apparently the static const member can only be used for constexpr.
C++ is weird.
* jit/GPRInfo.cpp:
* jit/GPRInfo.h:
2016-01-11 Johan K. Jensen <jj@johanjensen.dk>
Web Inspector: console.count() shouldn't show a colon in front of a number
https://bugs.webkit.org/show_bug.cgi?id=152038
Reviewed by Brian Burg.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::count):
Do not include title and colon if the title is empty.
2016-01-11 Dan Bernstein <mitz@apple.com>
Reverted r194317.
Reviewed by Joseph Pecoraro.
r194317 did not contain a change log entry, did not explain the motivation, did not name a
reviewer, and does not seem necessary.
* JavaScriptCore.xcodeproj/project.pbxproj:
2016-01-11 Joseph Pecoraro <pecoraro@apple.com>
keywords ("super", "delete", etc) should be valid method names
https://bugs.webkit.org/show_bug.cgi?id=144281
Reviewed by Ryosuke Niwa.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
- When parsing "static(" treat it as a method named "static" and not a static method.
- When parsing a keyword treat it like a string method name (get and set are not keywords)
- When parsing a getter / setter method name identifier, allow lookahead to be a keyword
(JSC::Parser<LexerType>::parseGetterSetter):
- When parsing the getter / setter's name, allow it to be a keyword.
2016-01-11 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add Div/Mod and fix Mul for B3 ARM64
https://bugs.webkit.org/show_bug.cgi?id=152978
Reviewed by Filip Pizlo.
Add the 3 operands forms of Mul.
Remove the form taking immediate on ARM64, there are no such instruction.
Add Div with sdiv.
Unfortunately, I discovered ChillMod's division by zero
makes it non-trivial on ARM64. I just made it into a macro like on x86.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::mul32):
(JSC::MacroAssemblerARM64::mul64):
(JSC::MacroAssemblerARM64::div32):
(JSC::MacroAssemblerARM64::div64):
* b3/B3LowerMacros.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
2016-01-11 Keith Miller <keith_miller@apple.com>
Arrays should use the InternalFunctionAllocationProfile when constructing new Arrays
https://bugs.webkit.org/show_bug.cgi?id=152949
Reviewed by Michael Saboff.
This patch updates Array constructors to use the new InternalFunctionAllocationProfile.
* runtime/ArrayConstructor.cpp:
(JSC::constructArrayWithSizeQuirk):
(JSC::constructWithArrayConstructor):
* runtime/InternalFunction.h:
(JSC::InternalFunction::createStructure):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation):
(JSC::JSGlobalObject::arrayStructureForProfileDuringAllocation):
(JSC::constructEmptyArray):
(JSC::constructArray):
(JSC::constructArrayNegativeIndexed):
* runtime/PrototypeMap.cpp:
(JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
* runtime/Structure.h:
* runtime/StructureInlines.h:
2016-01-08 Keith Miller <keith_miller@apple.com>
Use a profile to store allocation structures for subclasses of InternalFunctions
https://bugs.webkit.org/show_bug.cgi?id=152942
Reviewed by Michael Saboff.
This patch adds InternalFunctionAllocationProfile to FunctionRareData, which holds
a cached structure that can be used to quickly allocate any derived class of an InternalFunction.
InternalFunctionAllocationProfile ended up being distinct from ObjectAllocationProfile, due to
constraints imposed by Reflect.construct. Reflect.construct allows the user to pass an arbitrary
constructor as a new.target to any other constructor. This means that a user can pass some
non-derived constructor to an InternalFunction (they can even pass another InternalFunction as the
new.target). If we use the same profile for both InternalFunctions and JS allocations then we always
need to check in both JS code and C++ code that the profiled structure has the same ClassInfo as the
current constructor. By using different profiles, we only need to check the profile in InternalFunctions
as all JS constructed objects share the same ClassInfo (JSFinalObject). This comes at the relatively
low cost of using slightly more memory on FunctionRareData and being slightly more conceptually complex.
Additionally, this patch adds subclassing to some omitted classes.
* API/JSObjectRef.cpp:
(JSObjectMakeDate):
(JSObjectMakeRegExp):
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/InternalFunctionAllocationProfile.h: Added.
(JSC::InternalFunctionAllocationProfile::structure):
(JSC::InternalFunctionAllocationProfile::clear):
(JSC::InternalFunctionAllocationProfile::visitAggregate):
(JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_this):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_create_this):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/BooleanConstructor.cpp:
(JSC::constructWithBooleanConstructor):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/DateConstructor.cpp:
(JSC::constructDate):
(JSC::constructWithDateConstructor):
* runtime/DateConstructor.h:
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
* runtime/FunctionRareData.cpp:
(JSC::FunctionRareData::create):
(JSC::FunctionRareData::visitChildren):
(JSC::FunctionRareData::FunctionRareData):
(JSC::FunctionRareData::initializeObjectAllocationProfile):
(JSC::FunctionRareData::clear):
(JSC::FunctionRareData::finishCreation): Deleted.
(JSC::FunctionRareData::initialize): Deleted.
* runtime/FunctionRareData.h:
(JSC::FunctionRareData::offsetOfObjectAllocationProfile):
(JSC::FunctionRareData::objectAllocationProfile):
(JSC::FunctionRareData::objectAllocationStructure):
(JSC::FunctionRareData::allocationProfileWatchpointSet):
(JSC::FunctionRareData::isObjectAllocationProfileInitialized):
(JSC::FunctionRareData::internalFunctionAllocationStructure):
(JSC::FunctionRareData::createInternalFunctionAllocationStructureFromBase):
(JSC::FunctionRareData::offsetOfAllocationProfile): Deleted.
(JSC::FunctionRareData::allocationProfile): Deleted.
(JSC::FunctionRareData::allocationStructure): Deleted.
(JSC::FunctionRareData::isInitialized): Deleted.
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructure):
* runtime/InternalFunction.h:
* runtime/JSArrayBufferConstructor.cpp:
(JSC::constructArrayBuffer):
* runtime/JSFunction.cpp:
(JSC::JSFunction::allocateRareData):
(JSC::JSFunction::allocateAndInitializeRareData):
(JSC::JSFunction::initializeRareData):
* runtime/JSFunction.h:
(JSC::JSFunction::rareData):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayView):
* runtime/JSObject.h:
(JSC::JSFinalObject::typeInfo):
(JSC::JSFinalObject::createStructure):
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSPromiseConstructor.h:
* runtime/JSWeakMap.cpp:
* runtime/JSWeakSet.cpp:
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/NativeErrorConstructor.cpp:
(JSC::Interpreter::constructWithNativeErrorConstructor):
* runtime/NumberConstructor.cpp:
(JSC::constructWithNumberConstructor):
* runtime/PrototypeMap.cpp:
(JSC::PrototypeMap::createEmptyStructure):
(JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
(JSC::PrototypeMap::emptyObjectStructureForPrototype):
(JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
* runtime/PrototypeMap.h:
* runtime/RegExpConstructor.cpp:
(JSC::getRegExpStructure):
(JSC::constructRegExp):
(JSC::constructWithRegExpConstructor):
* runtime/RegExpConstructor.h:
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
* runtime/WeakSetConstructor.cpp:
(JSC::constructWeakSet):
* tests/stress/class-subclassing-misc.js:
(A):
(D):
(E):
(WM):
(WS):
(test):
* tests/stress/class-subclassing-typedarray.js: Added.
(test):
2016-01-11 Per Arne Vollan <peavo@outlook.com>
[B3][Win64] Compile error.
https://bugs.webkit.org/show_bug.cgi?id=152984
Reviewed by Alex Christensen.
Windows does not have bzero, use memset instead.
* b3/air/AirIteratedRegisterCoalescing.cpp:
2016-01-11 Konstantin Tokarev <annulen@yandex.ru>
Fixed compilation of JavaScriptCore with GCC 4.8 on 32-bit platforms
https://bugs.webkit.org/show_bug.cgi?id=152923
Reviewed by Alex Christensen.
* jit/CallFrameShuffler.h:
(JSC::CallFrameShuffler::assumeCalleeIsCell):
2016-01-11 Csaba Osztrogonác <ossy@webkit.org>
[B3] Fix control reaches end of non-void function GCC warnings on Linux
https://bugs.webkit.org/show_bug.cgi?id=152887
Reviewed by Mark Lam.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createBranch):
(JSC::B3::Air::LowerToAir::createCompare):
(JSC::B3::Air::LowerToAir::createSelect):
* b3/B3Type.h:
(JSC::B3::sizeofType):
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::isRepresentableAs):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isAnyUse):
(JSC::B3::Air::Arg::isColdUse):
(JSC::B3::Air::Arg::isEarlyUse):
(JSC::B3::Air::Arg::isLateUse):
(JSC::B3::Air::Arg::isAnyDef):
(JSC::B3::Air::Arg::isEarlyDef):
(JSC::B3::Air::Arg::isLateDef):
(JSC::B3::Air::Arg::isZDef):
(JSC::B3::Air::Arg::widthForB3Type):
(JSC::B3::Air::Arg::isGP):
(JSC::B3::Air::Arg::isFP):
(JSC::B3::Air::Arg::isType):
(JSC::B3::Air::Arg::isValidForm):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::newTmp):
(JSC::B3::Air::Code::numTmps):
2016-01-11 Filip Pizlo <fpizlo@apple.com>
Make it easier to introduce exotic instructions to Air
https://bugs.webkit.org/show_bug.cgi?id=152953
Reviewed by Benjamin Poulain.
Currently, you can define new "opcodes" in Air using either:
1) New opcode declared in AirOpcode.opcodes.
2) Patch opcode with a new implementation of Air::Special.
With (1), you are limited to fixed-argument-length instructions. There are other
restrictions as well, like that you can only use the roles that the AirOpcode syntax
supports.
With (2), you can do anything you like, but the instruction will be harder to match
since it will share the same opcode as any other Patch. Also, the instruction will have
the Special argument, which means more busy-work when creating the instruction and
validating it.
This introduces an in-between facility called "custom". This replaces what AirOpcode
previously called "special". A custom instruction is one whose behavior is defined by a
FooCustom struct with some static methods. Calls to those methods are emitted by
opcode_generator.rb.
The "custom" facility is powerful enough to be used to implement Patch, with the caveat
that we now treat the Patch instruction specially in a few places. Those places were
already effectively treating it specially by assuming that only Patch instructions have
a Special as their first argument.
This will let me implement the Shuffle instruction (bug 152952), which I think is needed
for performance work.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirCustom.h: Added.
(JSC::B3::Air::PatchCustom::forEachArg):
(JSC::B3::Air::PatchCustom::isValidFormStatic):
(JSC::B3::Air::PatchCustom::isValidForm):
(JSC::B3::Air::PatchCustom::admitsStack):
(JSC::B3::Air::PatchCustom::hasNonArgNonControlEffects):
(JSC::B3::Air::PatchCustom::generate):
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirInst.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::forEach):
(JSC::B3::Air::Inst::extraClobberedRegs):
(JSC::B3::Air::Inst::extraEarlyClobberedRegs):
(JSC::B3::Air::Inst::forEachDefWithExtraClobberedRegs):
(JSC::B3::Air::Inst::reportUsedRegisters):
(JSC::B3::Air::Inst::hasSpecial): Deleted.
* b3/air/AirOpcode.opcodes:
* b3/air/AirReportUsedRegisters.cpp:
(JSC::B3::Air::reportUsedRegisters):
* b3/air/opcode_generator.rb:
2016-01-11 Filip Pizlo <fpizlo@apple.com>
Turn Check(true) into Patchpoint() followed by Oops
https://bugs.webkit.org/show_bug.cgi?id=152968
Reviewed by Benjamin Poulain.
This is an obvious strength reduction to have, especially since if we discover that the
input to the Check is true after some amount of B3 optimization, then stubbing out the rest
of the basic block unlocks CFG simplification opportunities.
It's also a proof-of-concept for the Check->Patchpoint conversion that I'll use once I
implement sinking (bug 152162).
* b3/B3ControlValue.cpp:
(JSC::B3::ControlValue::convertToJump):
(JSC::B3::ControlValue::convertToOops):
(JSC::B3::ControlValue::dumpMeta):
* b3/B3ControlValue.h:
* b3/B3InsertionSet.h:
(JSC::B3::InsertionSet::insertValue):
* b3/B3InsertionSetInlines.h:
(JSC::B3::InsertionSet::insert):
* b3/B3ReduceStrength.cpp:
* b3/B3StackmapValue.h:
* b3/B3Value.h:
* tests/stress/ftl-force-osr-exit.js: Added.
2016-01-11 Benjamin Poulain <bpoulain@apple.com>
[JSC] When resolving Stack arguments, use addressing from SP when addressing from FP is invalid
https://bugs.webkit.org/show_bug.cgi?id=152840
Reviewed by Mark Lam.
ARM64 has two kinds of addressing with immediates:
-Signed 9bits direct (really only -256 to 255).
-Unsigned 12bits scaled by the load/store size.
When resolving the stack addresses, we easily run
past -256 bytes from FP. Addressing from SP gives us more
room to address the stack efficiently because we can
use unsigned immediates.
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::repForArg):
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
2016-01-10 Saam barati <sbarati@apple.com>
Implement a sampling profiler
https://bugs.webkit.org/show_bug.cgi?id=151713
Reviewed by Filip Pizlo.
This patch implements a sampling profiler for JavaScriptCore
that will be used in the Inspector UI. The implementation works as follows:
We queue the sampling profiler to run a task on a background
thread every 1ms. When the queued task executes, the sampling profiler
will pause the JSC execution thread and attempt to take a stack trace.
The sampling profiler does everything it can to be very careful
while taking this stack trace. Because it's reading arbitrary memory,
the sampling profiler must validate every pointer it reads from.
The sampling profiler tries to get an ExecutableBase for every call frame
it reads. It first tries to read the CodeBlock slot. It does this because
it can be 100% certain that a pointer is a CodeBlock while it's taking a
stack trace. But, not every call frame will have a CodeBlock. So we must read
the call frame's callee. For these stack traces where we read the callee, we
must verify the callee pointer, and the pointer traversal to an ExecutableBase,
on the main JSC execution thread, and not on the thread taking the stack
trace. We do this verification either before we run the marking phase in
GC, or when somebody asks the SamplingProfiler to materialize its data.
The SamplingProfiler must also be careful to not grab any locks while the JSC execution
thread is paused (this means it can't do anything that mallocs) because
that could cause a deadlock. Therefore, the sampling profiler grabs
locks for all data structures it consults before it pauses the JSC
execution thread.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.h:
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled):
(JSC::CodeBlockSet::mark):
* dfg/DFGNodeType.h:
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::add):
(JSC::CodeBlockSet::promoteYoungCodeBlocks):
(JSC::CodeBlockSet::clearMarksForFullCollection):
(JSC::CodeBlockSet::lastChanceToFinalize):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
(JSC::CodeBlockSet::contains):
(JSC::CodeBlockSet::writeBarrierCurrentlyExecutingCodeBlocks):
(JSC::CodeBlockSet::remove): Deleted.
* heap/CodeBlockSet.h:
(JSC::CodeBlockSet::getLock):
(JSC::CodeBlockSet::iterate):
The sampling pofiler uses the heap's CodeBlockSet to validate
CodeBlock pointers. This data structure must now be under a lock
because we must be certain we're not pausing the JSC execution thread
while it's manipulating this data structure.
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::ConservativeRoots):
(JSC::ConservativeRoots::grow):
(JSC::ConservativeRoots::genericAddPointer):
(JSC::ConservativeRoots::genericAddSpan):
(JSC::ConservativeRoots::add):
(JSC::CompositeMarkHook::CompositeMarkHook):
(JSC::CompositeMarkHook::mark):
* heap/ConservativeRoots.h:
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::visitHandleStack):
(JSC::Heap::visitSamplingProfiler):
(JSC::Heap::traceCodeBlocksAndJITStubRoutines):
(JSC::Heap::snapshotMarkedSpace):
* heap/Heap.h:
(JSC::Heap::structureIDTable):
(JSC::Heap::codeBlockSet):
* heap/MachineStackMarker.cpp:
(pthreadSignalHandlerSuspendResume):
(JSC::getCurrentPlatformThread):
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::Thread::createForCurrentThread):
(JSC::MachineThreads::Thread::operator==):
(JSC::isThreadInList):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::machineThreadForCurrentThread):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::Thread::Thread):
(JSC::MachineThreads::Thread::~Thread):
(JSC::MachineThreads::Thread::suspend):
(JSC::MachineThreads::Thread::resume):
(JSC::MachineThreads::Thread::getRegisters):
(JSC::MachineThreads::Thread::Registers::stackPointer):
(JSC::MachineThreads::Thread::Registers::framePointer):
(JSC::MachineThreads::Thread::Registers::instructionPointer):
(JSC::MachineThreads::Thread::freeRegisters):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(JSC::pthreadSignalHandlerSuspendResume): Deleted.
(JSC::MachineThreads::Thread::operator!=): Deleted.
* heap/MachineStackMarker.h:
(JSC::MachineThreads::Thread::operator!=):
(JSC::MachineThreads::getLock):
(JSC::MachineThreads::threadsListHead):
We can now ask a MachineThreads::Thread for its frame pointer
and program counter on darwin and windows platforms. efl
and gtk implementations will happen in another patch.
* heap/MarkedBlockSet.h:
(JSC::MarkedBlockSet::getLock):
(JSC::MarkedBlockSet::add):
(JSC::MarkedBlockSet::remove):
(JSC::MarkedBlockSet::recomputeFilter):
(JSC::MarkedBlockSet::filter):
(JSC::MarkedBlockSet::set):
* heap/MarkedSpace.cpp:
(JSC::Free::Free):
(JSC::Free::operator()):
(JSC::FreeOrShrink::FreeOrShrink):
(JSC::FreeOrShrink::operator()):
(JSC::MarkedSpace::~MarkedSpace):
(JSC::MarkedSpace::isPagedOut):
(JSC::MarkedSpace::freeBlock):
(JSC::MarkedSpace::freeOrShrinkBlock):
(JSC::MarkedSpace::shrink):
* heap/MarkedSpace.h:
(JSC::MarkedSpace::forEachLiveCell):
(JSC::MarkedSpace::forEachDeadCell):
* interpreter/CallFrame.h:
(JSC::ExecState::calleeAsValue):
(JSC::ExecState::callee):
(JSC::ExecState::unsafeCallee):
(JSC::ExecState::codeBlock):
(JSC::ExecState::scope):
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::dumpProfile):
(JSC::ExecutableAllocator::getLock):
(JSC::ExecutableAllocator::isValidExecutableMemory):
* jit/ExecutableAllocator.h:
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::ExecutableAllocator::allocate):
(JSC::ExecutableAllocator::isValidExecutableMemory):
(JSC::ExecutableAllocator::getLock):
(JSC::ExecutableAllocator::committedByteCount):
The sampling profiler consults the ExecutableAllocator to check
if the frame pointer it reads is in executable allocated memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionCheckModuleSyntax):
(functionStartSamplingProfiler):
(functionSamplingProfilerStackTraces):
* llint/LLIntPCRanges.h: Added.
(JSC::LLInt::isLLIntPC):
* offlineasm/asm.rb:
I added the ability to test whether the PC is executing
LLInt code because this code is not part of the memory
our executable allocator allocates.
* runtime/Executable.h:
(JSC::ExecutableBase::isModuleProgramExecutable):
(JSC::ExecutableBase::isExecutableType):
(JSC::ExecutableBase::isHostFunction):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
(JSC::JSLock::unlock):
* runtime/Options.h:
* runtime/SamplingProfiler.cpp: Added.
(JSC::reportStats):
(JSC::FrameWalker::FrameWalker):
(JSC::FrameWalker::walk):
(JSC::FrameWalker::wasValidWalk):
(JSC::FrameWalker::advanceToParentFrame):
(JSC::FrameWalker::isAtTop):
(JSC::FrameWalker::resetAtMachineFrame):
(JSC::FrameWalker::isValidFramePointer):
(JSC::FrameWalker::isValidCodeBlock):
(JSC::FrameWalker::tryToGetExecutableFromCallee):
The FrameWalker class is used to walk the stack in a safe
manner. It doesn't do anything that would deadlock, and it
validates all pointers that it sees.
(JSC::SamplingProfiler::SamplingProfiler):
(JSC::SamplingProfiler::~SamplingProfiler):
(JSC::SamplingProfiler::visit):
(JSC::SamplingProfiler::shutdown):
(JSC::SamplingProfiler::start):
(JSC::SamplingProfiler::stop):
(JSC::SamplingProfiler::pause):
(JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
(JSC::SamplingProfiler::dispatchIfNecessary):
(JSC::SamplingProfiler::dispatchFunction):
(JSC::SamplingProfiler::noticeJSLockAcquisition):
(JSC::SamplingProfiler::noticeVMEntry):
(JSC::SamplingProfiler::observeStackTrace):
(JSC::SamplingProfiler::clearData):
(JSC::displayName):
(JSC::startLine):
(JSC::startColumn):
(JSC::sourceID):
(JSC::url):
(JSC::SamplingProfiler::stacktracesAsJSON):
* runtime/SamplingProfiler.h: Added.
(JSC::SamplingProfiler::getLock):
(JSC::SamplingProfiler::setTimingInterval):
(JSC::SamplingProfiler::stackTraces):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
(JSC::VM::setLastStackTop):
(JSC::VM::createContextGroup):
(JSC::VM::ensureWatchdog):
(JSC::VM::ensureSamplingProfiler):
(JSC::thunkGeneratorForIntrinsic):
* runtime/VM.h:
(JSC::VM::watchdog):
(JSC::VM::isSafeToRecurse):
(JSC::VM::lastStackTop):
(JSC::VM::scratchBufferForSize):
(JSC::VM::samplingProfiler):
(JSC::VM::setShouldRewriteConstAsVar):
(JSC::VM::setLastStackTop): Deleted.
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
* tests/stress/sampling-profiler: Added.
* tests/stress/sampling-profiler-anonymous-function.js: Added.
(foo):
(baz):
* tests/stress/sampling-profiler-basic.js: Added.
(bar):
(foo):
(nothing):
(top):
(jaz):
(kaz):
(checkInlining):
* tests/stress/sampling-profiler-deep-stack.js: Added.
(foo):
(hellaDeep):
(start):
* tests/stress/sampling-profiler-microtasks.js: Added.
(testResults):
(loop.jaz):
(loop):
* tests/stress/sampling-profiler/samplingProfiler.js: Added.
(assert):
(let.nodePrototype.makeChildIfNeeded):
(makeNode):
(updateCallingContextTree):
(doesTreeHaveStackTrace):
(makeTree):
(runTest):
(dumpTree):
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::isInObjectSpace):
(JSC::JSDollarVMPrototype::isInStorageSpace):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generateEnter):
(JSC::Yarr::YarrGenerator::generateReturn):
(JSC::Yarr::YarrGenerator::YarrGenerator):
(JSC::Yarr::YarrGenerator::compile):
(JSC::Yarr::jitCompile):
We now have a boolean that's set to true when
we're executing a RegExp, and to false otherwise.
The boolean lives off of VM.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.h:
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled):
(JSC::CodeBlockSet::mark):
* dfg/DFGNodeType.h:
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::add):
(JSC::CodeBlockSet::promoteYoungCodeBlocks):
(JSC::CodeBlockSet::clearMarksForFullCollection):
(JSC::CodeBlockSet::lastChanceToFinalize):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
(JSC::CodeBlockSet::contains):
(JSC::CodeBlockSet::writeBarrierCurrentlyExecutingCodeBlocks):
(JSC::CodeBlockSet::remove): Deleted.
* heap/CodeBlockSet.h:
(JSC::CodeBlockSet::getLock):
(JSC::CodeBlockSet::iterate):
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::ConservativeRoots):
(JSC::ConservativeRoots::genericAddPointer):
(JSC::ConservativeRoots::add):
(JSC::CompositeMarkHook::CompositeMarkHook):
(JSC::CompositeMarkHook::mark):
* heap/ConservativeRoots.h:
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::visitHandleStack):
(JSC::Heap::visitSamplingProfiler):
(JSC::Heap::traceCodeBlocksAndJITStubRoutines):
* heap/Heap.h:
(JSC::Heap::structureIDTable):
(JSC::Heap::codeBlockSet):
* heap/HeapInlines.h:
(JSC::Heap::didFreeBlock):
(JSC::Heap::isPointerGCObject):
(JSC::Heap::isValueGCObject):
* heap/MachineStackMarker.cpp:
(pthreadSignalHandlerSuspendResume):
(JSC::getCurrentPlatformThread):
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::Thread::createForCurrentThread):
(JSC::MachineThreads::Thread::operator==):
(JSC::isThreadInList):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::machineThreadForCurrentThread):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::Thread::Thread):
(JSC::MachineThreads::Thread::~Thread):
(JSC::MachineThreads::Thread::suspend):
(JSC::MachineThreads::Thread::resume):
(JSC::MachineThreads::Thread::getRegisters):
(JSC::MachineThreads::Thread::Registers::stackPointer):
(JSC::MachineThreads::Thread::Registers::framePointer):
(JSC::MachineThreads::Thread::Registers::instructionPointer):
(JSC::MachineThreads::Thread::freeRegisters):
(JSC::pthreadSignalHandlerSuspendResume): Deleted.
(JSC::MachineThreads::Thread::operator!=): Deleted.
* heap/MachineStackMarker.h:
(JSC::MachineThreads::Thread::operator!=):
(JSC::MachineThreads::getLock):
(JSC::MachineThreads::threadsListHead):
* heap/MarkedBlockSet.h:
* heap/MarkedSpace.cpp:
(JSC::Free::Free):
(JSC::Free::operator()):
(JSC::FreeOrShrink::FreeOrShrink):
(JSC::FreeOrShrink::operator()):
* interpreter/CallFrame.h:
(JSC::ExecState::calleeAsValue):
(JSC::ExecState::callee):
(JSC::ExecState::unsafeCallee):
(JSC::ExecState::codeBlock):
(JSC::ExecState::scope):
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::dumpProfile):
(JSC::ExecutableAllocator::getLock):
(JSC::ExecutableAllocator::isValidExecutableMemory):
* jit/ExecutableAllocator.h:
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::ExecutableAllocator::allocate):
(JSC::ExecutableAllocator::isValidExecutableMemory):
(JSC::ExecutableAllocator::getLock):
(JSC::ExecutableAllocator::committedByteCount):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionCheckModuleSyntax):
(functionPlatformSupportsSamplingProfiler):
(functionStartSamplingProfiler):
(functionSamplingProfilerStackTraces):
* llint/LLIntPCRanges.h: Added.
(JSC::LLInt::isLLIntPC):
* offlineasm/asm.rb:
* runtime/Executable.h:
(JSC::ExecutableBase::isModuleProgramExecutable):
(JSC::ExecutableBase::isExecutableType):
(JSC::ExecutableBase::isHostFunction):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
(JSC::JSLock::unlock):
* runtime/Options.h:
* runtime/SamplingProfiler.cpp: Added.
(JSC::reportStats):
(JSC::FrameWalker::FrameWalker):
(JSC::FrameWalker::walk):
(JSC::FrameWalker::wasValidWalk):
(JSC::FrameWalker::advanceToParentFrame):
(JSC::FrameWalker::isAtTop):
(JSC::FrameWalker::resetAtMachineFrame):
(JSC::FrameWalker::isValidFramePointer):
(JSC::FrameWalker::isValidCodeBlock):
(JSC::SamplingProfiler::SamplingProfiler):
(JSC::SamplingProfiler::~SamplingProfiler):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::visit):
(JSC::SamplingProfiler::shutdown):
(JSC::SamplingProfiler::start):
(JSC::SamplingProfiler::stop):
(JSC::SamplingProfiler::pause):
(JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
(JSC::SamplingProfiler::dispatchIfNecessary):
(JSC::SamplingProfiler::dispatchFunction):
(JSC::SamplingProfiler::noticeJSLockAcquisition):
(JSC::SamplingProfiler::noticeVMEntry):
(JSC::SamplingProfiler::clearData):
(JSC::displayName):
(JSC::SamplingProfiler::stacktracesAsJSON):
(WTF::printInternal):
* runtime/SamplingProfiler.h: Added.
(JSC::SamplingProfiler::StackFrame::StackFrame):
(JSC::SamplingProfiler::getLock):
(JSC::SamplingProfiler::setTimingInterval):
(JSC::SamplingProfiler::stackTraces):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
(JSC::VM::setLastStackTop):
(JSC::VM::createContextGroup):
(JSC::VM::ensureWatchdog):
(JSC::VM::ensureSamplingProfiler):
(JSC::thunkGeneratorForIntrinsic):
* runtime/VM.h:
(JSC::VM::watchdog):
(JSC::VM::samplingProfiler):
(JSC::VM::isSafeToRecurse):
(JSC::VM::lastStackTop):
(JSC::VM::scratchBufferForSize):
(JSC::VM::setLastStackTop): Deleted.
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
* tests/stress/sampling-profiler: Added.
* tests/stress/sampling-profiler-anonymous-function.js: Added.
(platformSupportsSamplingProfiler.foo):
(platformSupportsSamplingProfiler.baz):
(platformSupportsSamplingProfiler):
* tests/stress/sampling-profiler-basic.js: Added.
(platformSupportsSamplingProfiler.bar):
(platformSupportsSamplingProfiler.foo):
(platformSupportsSamplingProfiler.nothing):
(platformSupportsSamplingProfiler.top):
(platformSupportsSamplingProfiler.jaz):
(platformSupportsSamplingProfiler.kaz):
(platformSupportsSamplingProfiler.checkInlining):
(platformSupportsSamplingProfiler):
* tests/stress/sampling-profiler-deep-stack.js: Added.
(platformSupportsSamplingProfiler.foo):
(platformSupportsSamplingProfiler.let.hellaDeep):
(platformSupportsSamplingProfiler.let.start):
(platformSupportsSamplingProfiler):
* tests/stress/sampling-profiler-microtasks.js: Added.
(platformSupportsSamplingProfiler.testResults):
(platformSupportsSamplingProfiler):
(platformSupportsSamplingProfiler.loop.jaz):
(platformSupportsSamplingProfiler.loop):
* tests/stress/sampling-profiler/samplingProfiler.js: Added.
(assert):
(let.nodePrototype.makeChildIfNeeded):
(makeNode):
(updateCallingContextTree):
(doesTreeHaveStackTrace):
(makeTree):
(runTest):
(dumpTree):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generateEnter):
(JSC::Yarr::YarrGenerator::generateReturn):
(JSC::Yarr::YarrGenerator::YarrGenerator):
(JSC::Yarr::YarrGenerator::compile):
(JSC::Yarr::jitCompile):
2016-01-10 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Iterating over a Set/Map is too slow
https://bugs.webkit.org/show_bug.cgi?id=152691
Reviewed by Saam Barati.
Set#forEach and Set & for-of are very slow. There are 2 reasons.
1. forEach is implemented in C++. And typically, taking JS callback and calling it from C++.
C++ to JS transition seems costly. perf result in Linux machine shows this.
Samples: 23K of event 'cycles', Event count (approx.): 21446074385
34.04% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] JSC::Interpreter::execute(JSC::CallFrameClosure&)
20.48% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] vmEntryToJavaScript
9.80% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*)
7.95% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] JSC::setProtoFuncForEach(JSC::ExecState*)
5.65% jsc perf-22854.map [.] 0x00007f5d2c204a6f
Writing forEach in JS eliminates this.
Samples: 23K of event 'cycles', Event count (approx.): 21255691651
62.91% jsc perf-22890.map [.] 0x00007fd117c0a3b9
24.89% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] JSC::privateFuncSetIteratorNext(JSC::ExecState*)
0.29% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] JSC::CodeBlock::updateAllPredictionsAndCountLiveness(unsigned int&, unsigned int&)
0.24% jsc [vdso] [.] 0x00000000000008e8
0.22% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] JSC::CodeBlock::predictedMachineCodeSize()
0.16% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] WTF::MetaAllocator::currentStatistics()
0.15% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] JSC::Lexer<unsigned char>::lex(JSC::JSToken*, unsigned int, bool)
2. Iterator result object allocation is costly.
Iterator result object allocation is costly. Even if the (1) is solved, when executing Set & for-of, perf result shows very slow performance due to (2).
Samples: 108K of event 'cycles', Event count (approx.): 95529273748
18.02% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] JSC::createIteratorResultObject(JSC::ExecState*, JSC::JSValue, bool)
15.68% jsc jsc [.] JSC::JSObject::putDirect(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int)
14.18% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] JSC::PrototypeMap::emptyObjectStructureForPrototype(JSC::JSObject*, unsigned int)
13.40% jsc perf-25420.map [.] 0x00007fce158006a1
6.79% jsc libjavascriptcoregtk-4.0.so.18.3.1 [.] JSC::StructureTransitionTable::get(WTF::UniquedStringImpl*, unsigned int) const
In the long term, we should implement SetIterator#next in JS and make the iterator result object allocation written in JS to encourage object allocation elimination in FTL.
But seeing the perf result, we can find the easy to fix bottleneck in the current implementation.
Every time createIteratorResultObject creates the empty object and use putDirect to store properties.
The pre-baked Structure* with `done` and `value` properties makes this implementation fast.
After these improvements, the micro benchmark[1] shows the following.
old:
Linked List x 212,776 ops/sec ±0.21% (162 runs sampled)
Array x 376,156 ops/sec ±0.20% (162 runs sampled)
Array forEach x 17,345 ops/sec ±0.99% (137 runs sampled)
Array for-of x 16,518 ops/sec ±0.58% (160 runs sampled)
Set forEach x 13,263 ops/sec ±0.20% (162 runs sampled)
Set for-of x 4,732 ops/sec ±0.34% (123 runs sampled)
new:
Linked List x 210,833 ops/sec ±0.28% (161 runs sampled)
Array x 371,347 ops/sec ±0.36% (162 runs sampled)
Array forEach x 17,460 ops/sec ±0.84% (136 runs sampled)
Array for-of x 16,188 ops/sec ±1.27% (158 runs sampled)
Set forEach x 23,684 ops/sec ±2.46% (139 runs sampled)
Set for-of x 12,176 ops/sec ±0.54% (157 runs sampled)
Set#forEach becomes comparable to Array#forEach. And Set#forEach and Set & for-of are improved (1.79x, and 2.57x).
After this optimizations, they are still much slower than linked list and array.
This should be optimized in the long term.
[1]: https://gist.github.com/Constellation/8db5f5b8f12fe7e283d0
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/MapPrototype.js: Copied from Source/JavaScriptCore/runtime/IteratorOperations.h.
(forEach):
* builtins/SetPrototype.js: Copied from Source/JavaScriptCore/runtime/IteratorOperations.h.
(forEach):
* runtime/CommonIdentifiers.h:
* runtime/IteratorOperations.cpp:
(JSC::createIteratorResultObjectStructure):
(JSC::createIteratorResultObject):
* runtime/IteratorOperations.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::iteratorResultObjectStructure):
(JSC::JSGlobalObject::iteratorResultStructure): Deleted.
(JSC::JSGlobalObject::iteratorResultStructureOffset): Deleted.
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::getOwnPropertySlot):
(JSC::privateFuncIsMap):
(JSC::privateFuncMapIterator):
(JSC::privateFuncMapIteratorNext):
(JSC::MapPrototype::finishCreation): Deleted.
(JSC::mapProtoFuncForEach): Deleted.
* runtime/MapPrototype.h:
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::getOwnPropertySlot):
(JSC::privateFuncIsSet):
(JSC::privateFuncSetIterator):
(JSC::privateFuncSetIteratorNext):
(JSC::SetPrototype::finishCreation): Deleted.
(JSC::setProtoFuncForEach): Deleted.
* runtime/SetPrototype.h:
2016-01-10 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix ARM64 build.
* b3/air/AirOpcode.opcodes:
2016-01-10 Filip Pizlo <fpizlo@apple.com>
B3 should reduce Trunc(BitOr(value, constant)) where !(constant & 0xffffffff) to Trunc(value)
https://bugs.webkit.org/show_bug.cgi?id=152955
Reviewed by Saam Barati.
This happens when we box an int32 and then immediately unbox it.
This makes an enormous difference on AsmBench/FloatMM. It's a 2x speed-up on that
benchmark. It's neutral elsewhere.
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testPowDoubleByIntegerLoop):
(JSC::B3::testTruncOrHigh):
(JSC::B3::testTruncOrLow):
(JSC::B3::testBitAndOrHigh):
(JSC::B3::testBitAndOrLow):
(JSC::B3::zero):
(JSC::B3::run):
2016-01-10 Skachkov Oleksandr <gskachkov@gmail.com>
[ES6] Arrow function syntax. Get rid of JSArrowFunction and use standard JSFunction class
https://bugs.webkit.org/show_bug.cgi?id=149855
Reviewed by Saam Barati.
JSArrowFunction.h/cpp were removed from JavaScriptCore, because now is used new approach for storing
'this', 'arguments' and 'super'
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunction):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* ftl/FTLAbstractHeapRepository.cpp:
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
* interpreter/Interpreter.cpp:
* interpreter/Interpreter.h:
* jit/JITOpcodes.cpp:
* jit/JITOpcodes32_64.cpp:
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
* runtime/JSArrowFunction.cpp: Removed.
* runtime/JSArrowFunction.h: Removed.
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
2016-01-10 Filip Pizlo <fpizlo@apple.com>
It should be possible to run liveness over registers without also tracking Tmps
https://bugs.webkit.org/show_bug.cgi?id=152963
Reviewed by Saam Barati.
This adds a RegLivenessAdapter so that we can run Liveness over registers. This makes it
easier to write certain kinds of phases, like ReportUsedRegisters. I anticipate writing more
code like that for handling cold function calls. It also makes code like that somewhat more
scalable, since we're no longer using HashSets.
Currently, the way we track sets of registers is with a BitVector. Normally, we use the
RegisterSet class, which wraps BitVector, so that we can add()/contains() on Reg's. But in
the liveness analysis, everything gets turned into an index. So, we want to use BitVector
directly. To do that, I needed to make the BitVector API look a bit more like a set API. I
think that this is good, because the lack of set methods (add/remove/contains) has caused
bugs in the past. This makes BitVector have methods both for set operations on bits and array
operations on bits. I think that's good, since BitVector gets used in both contexts.
* b3/B3IndexSet.h:
(JSC::B3::IndexSet::Iterable::iterator::iterator):
(JSC::B3::IndexSet::Iterable::begin):
(JSC::B3::IndexSet::dump):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::ForEach<Tmp>::forEach):
(JSC::B3::Air::ForEach<Arg>::forEach):
(JSC::B3::Air::ForEach<Reg>::forEach):
(JSC::B3::Air::Inst::forEach):
* b3/air/AirLiveness.h:
(JSC::B3::Air::RegLivenessAdapter::RegLivenessAdapter):
(JSC::B3::Air::RegLivenessAdapter::maxIndex):
(JSC::B3::Air::RegLivenessAdapter::acceptsType):
(JSC::B3::Air::RegLivenessAdapter::valueToIndex):
(JSC::B3::Air::RegLivenessAdapter::indexToValue):
* b3/air/AirReportUsedRegisters.cpp:
(JSC::B3::Air::reportUsedRegisters):
* jit/Reg.h:
(JSC::Reg::next):
(JSC::Reg::index):
(JSC::Reg::maxIndex):
(JSC::Reg::isSet):
(JSC::Reg::operator bool):
* jit/RegisterSet.h:
(JSC::RegisterSet::forEach):
2016-01-10 Benjamin Poulain <bpoulain@apple.com>
[JSC] Make branchMul functional in ARM B3 and minor fixes
https://bugs.webkit.org/show_bug.cgi?id=152889
Reviewed by Mark Lam.
ARM64 does not have a "S" version of MUL setting the flags.
What we do is abstract that in the MacroAssembler. The problem
is that form requires scratch registers.
For simplicity, I just exposed the two scratch registers
for Air. Filip already added the concept of Scratch role,
all I needed was to expose it for opcodes.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchMul32):
(JSC::MacroAssemblerARM64::branchMul64):
Expose a version with the scratch registers as arguments.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
Add the new form of CheckMul lowering.
* b3/air/AirOpcode.opcodes:
Expose the new BranchMuls.
Remove all the Test variants that use immediates
since Air can't handle those immediates correctly yet.
* b3/air/opcode_generator.rb:
Expose the Scratch role.
* b3/testb3.cpp:
(JSC::B3::testPatchpointLotsOfLateAnys):
Ooops, the scratch registers were not clobbered. We were just lucky
on x86.
2016-01-10 Benjamin Poulain <bpoulain@apple.com>
[JSC] B3 is unable to do function calls on ARM64
https://bugs.webkit.org/show_bug.cgi?id=152895
Reviewed by Mark Lam.
Apparently iOS does not follow the ARM64 ABI for function calls.
Instead of giving each value a 8 bytes slot, it must be packed
while preserving alignment.
This patch adds a #ifdef to make function calls functional.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::marshallCCallArgument):
(JSC::B3::Air::LowerToAir::lower):
2016-01-09 Filip Pizlo <fpizlo@apple.com>
Air should support Branch64 with immediates
https://bugs.webkit.org/show_bug.cgi?id=152951
Reviewed by Oliver Hunt.
This doesn't significantly improve performance on any benchmarks, but it's great to get this
obvious omission out of the way.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::branch64):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testPowDoubleByIntegerLoop):
(JSC::B3::testBranch64Equal):
(JSC::B3::testBranch64EqualImm):
(JSC::B3::testBranch64EqualMem):
(JSC::B3::testBranch64EqualMemImm):
(JSC::B3::zero):
(JSC::B3::run):
2016-01-09 Dan Bernstein <mitz@apple.com>
[Cocoa] Allow overriding the frameworks directory independently of using a staging install path
https://bugs.webkit.org/show_bug.cgi?id=152926
Reviewed by Tim Horton.
Introduce a new build setting, WK_OVERRIDE_FRAMEWORKS_DIR. When not empty, it determines
where the frameworks are installed. Setting USE_STAGING_INSTALL_PATH to YES sets
WK_OVERRIDE_FRAMEWORKS_DIR to $(SYSTEM_LIBRARY_DIR)/StagedFrameworks/Safari.
Account for the possibility of WK_OVERRIDE_FRAMEWORKS_DIR containing spaces.
* Configurations/Base.xcconfig:
- Replace STAGED_FRAMEWORKS_SEARCH_PATH in FRAMEWORK_SEARCH_PATHS with
WK_OVERRIDE_FRAMEWORKS_DIR and add quotes to account for spaces.
- Define JAVASCRIPTCORE_FRAMEWORKS_DIR based on WK_OVERRIDE_FRAMEWORKS_DIR.
* Configurations/JSC.xcconfig:
Add quotes to account for spaces.
* Configurations/ToolExecutable.xcconfig:
Ditto.
* postprocess-headers.sh:
Ditto.
2016-01-09 Mark Lam <mark.lam@apple.com>
The FTL allocated spill slots for BinaryOps is sometimes inaccurate.
https://bugs.webkit.org/show_bug.cgi?id=152918
Reviewed by Filip Pizlo and Saam Barati.
* ftl/FTLCompile.cpp:
- Updated a comment.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
- The code to compute maxNumberOfCatchSpills was unnecessarily allocating an
extra slot for BinaryOps that don't have Untyped operands, and failing to
allocate that extra slot for some binary ops. This is now fixed.
* tests/stress/ftl-shr-exception.js:
* tests/stress/ftl-xor-exception.js:
- Un-skipped these tests. They now pass with this patch.
2016-01-09 Andreas Kling <akling@apple.com>
Use NeverDestroyed instead of DEPRECATED_DEFINE_STATIC_LOCAL
<https://webkit.org/b/152902>
Reviewed by Anders Carlsson.
Mostly mechanical conversion to NeverDestroyed throughout JavaScriptCore.
* API/JSAPIWrapperObject.mm:
(jsAPIWrapperObjectHandleOwner):
* API/JSManagedValue.mm:
(managedValueHandleOwner):
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::objectGroupForBreakpointAction):
* jit/ExecutableAllocator.cpp:
(JSC::DemandExecutableAllocator::allocators):
2016-01-08 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do varargs tail calls and stack overflows
https://bugs.webkit.org/show_bug.cgi?id=152934
Reviewed by Saam Barati.
I was trying to get tail-call-varargs-no-stack-overflow.js.ftl-no-cjit-validate to work and
at first I hit the stack overflow issue and then I hit the varargs tail call issue. That's
why I have two fixes in one change. Now the test passes.
This reduces the number of failures from 13 to 0.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower): Implement stack overflow handling.
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs): Varargs tail calls need to
append an Oops (i.e. "unreachable").
2016-01-08 Filip Pizlo <fpizlo@apple.com>
B3 needs Neg()
https://bugs.webkit.org/show_bug.cgi?id=152925
Reviewed by Mark Lam.
Previously we said that negation should be represented as Sub(0, x). That's wrong, since
for floats, Sub(0, 0) == 0 while Neg(0) == -0.
One way to solve this would be to say that anyone trying to say Neg(x) where x is a float
should instead say BitXor(x, -0). That's actually correct, but I think that it would be odd
to use bitops to represent floating point operations. Whatever cuteness this would have
bought us would be outweighed by the annoyance of having to write code that matches
Sub(0, x) for integer negation and BitXor(x, -0) for double negation. For example, this
would mean strictly more code for anyone implementing a Neg(Neg(x))=>x strength reduction.
Also, I suspect that the omission of Neg would cause others to make the mistake of using
Sub to represent floating point negation.
So, this introduces a proper Neg() opcode to B3. It's now the canonical way of saying
negation for both ints and floats. For ints, we canonicalize Sub(0, x) to Neg(x). For
floats, we lower it to BitXor(x, -0) on x86.
This reduces the number of failures from 13 to 12.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::andFloat):
(JSC::MacroAssemblerX86Common::xorDouble):
(JSC::MacroAssemblerX86Common::xorFloat):
(JSC::MacroAssemblerX86Common::convertInt32ToDouble):
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/air/AirOpcode.opcodes:
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::lockedStackSlot):
(JSC::FTL::Output::neg):
(JSC::FTL::Output::bitNot):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::chillDiv):
(JSC::FTL::Output::mod):
(JSC::FTL::Output::chillMod):
(JSC::FTL::Output::doubleAdd):
(JSC::FTL::Output::doubleSub):
(JSC::FTL::Output::doubleMul):
(JSC::FTL::Output::doubleDiv):
(JSC::FTL::Output::doubleMod):
(JSC::FTL::Output::doubleNeg):
(JSC::FTL::Output::bitAnd):
(JSC::FTL::Output::bitOr):
(JSC::FTL::Output::neg): Deleted.
* tests/stress/ftl-negate-zero.js: Added. This was already covered by op_negate but since
it's such a glaring bug, I thought having a test for it specifically would be good.
2016-01-08 Filip Pizlo <fpizlo@apple.com>
FTL B3 compile() doesn't clear exception handlers before we add FTL-specific ones
https://bugs.webkit.org/show_bug.cgi?id=152922
Reviewed by Saam Barati.
FTL B3 was generating a handler table that first contained the old baseline handlers keyed
by baseline's bytecode indices and then the FTL handlers keyed by FTL callsite index. That's
wrong, since the FTL code block should not contain any baseline handlers. The fix is to
clear the handlers before generation, sort of like FTL LLVM does.
Also added some stuff to make it easier to inspect the handler table.
This reduces the numbe rof failures from 25 to 13.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::dumpExceptionHandlers):
(JSC::CodeBlock::beginDumpProfiling):
* bytecode/CodeBlock.h:
* ftl/FTLB3Compile.cpp:
(JSC::FTL::compile):
2016-01-08 Filip Pizlo <fpizlo@apple.com>
B3 incorrectly turns NotEqual(bool, 1) into Equal(bool, 1) instead of Equal(bool, 0)
https://bugs.webkit.org/show_bug.cgi?id=152916
Reviewed by Mark Lam.
This was causing a failure in an ancient DFG layout test. Thanks, ftl-eager-no-cjit!
This reduces the number of failures from 27 to 25.
* b3/B3ReduceStrength.cpp:
2016-01-08 Filip Pizlo <fpizlo@apple.com>
FTL B3 allocateCell() should not crash
https://bugs.webkit.org/show_bug.cgi?id=152909
Reviewed by Mark Lam.
This code was crashing in some tests that forced GC slow paths because it was stubbed out
due to the use of undef. B3 doesn't have undef. In this case, there's no good reason to use
undef. We can just use zero. Since the path is dead anyway in that case, we weren't gaining
any LLVM optimizations by using undef.
This reduces the number of failures from 35 to 27.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
2016-01-08 Filip Pizlo <fpizlo@apple.com>
FTL B3 fails to realize that binary snippets might choose to omit their fast path
https://bugs.webkit.org/show_bug.cgi?id=152901
Reviewed by Mark Lam.
This reduces the number of failures from 99 to 35.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::emitBinarySnippet):
2016-01-08 Saam barati <sbarati@apple.com>
restoreCalleeSavesFromVMCalleeSavesBuffer should use the scratch register
https://bugs.webkit.org/show_bug.cgi?id=152879
Reviewed by Filip Pizlo.
We were clobbering a register we needed when picking
a scratch register inside an FTL OSR Exit.
* dfg/DFGThunks.cpp:
(JSC::DFG::osrEntryThunkGenerator):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitRandomThunk):
(JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer):
(JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer): Deleted.
* tests/stress/ftl-put-by-id-setter-exception-interesting-live-state.js:
(foo):
2016-01-08 Mark Lam <mark.lam@apple.com>
Rolling out: Rename StringFromCharCode to StringFromSingleCharCode.
https://bugs.webkit.org/show_bug.cgi?id=152897
Not reviewed.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileFromCharCode):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* runtime/StringConstructor.cpp:
(JSC::stringFromCharCode):
(JSC::stringFromSingleCharCode): Deleted.
* runtime/StringConstructor.h:
2016-01-08 Per Arne Vollan <peavo@outlook.com>
[JSC] Use std::call_once instead of pthread_once when initializing LLVM.
https://bugs.webkit.org/show_bug.cgi?id=152893
Reviewed by Mark Lam.
Use std::call_once since pthreads is not present on all platforms.
* llvm/InitializeLLVM.cpp:
(JSC::initializeLLVMImpl):
(JSC::initializeLLVM):
2016-01-08 Mark Lam <mark.lam@apple.com>
Rename StringFromCharCode to StringFromSingleCharCode.
https://bugs.webkit.org/show_bug.cgi?id=152897
Reviewed by Daniel Bates.
StringFromSingleCharCode is a better name because the intrinsic it represents
only applies when we are converting from a single char code. This is purely
a refactoring patch. There is no semantic change.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileFromCharCode):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* runtime/StringConstructor.cpp:
(JSC::stringFromCharCode):
(JSC::stringFromSingleCharCode):
* runtime/StringConstructor.h:
2016-01-08 Konstantin Tokarev <annulen@yandex.ru>
[mips] Fixed unused parameter warnings
https://bugs.webkit.org/show_bug.cgi?id=152885
Reviewed by Mark Lam.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
2016-01-08 Konstantin Tokarev <annulen@yandex.ru>
[mips] Max value of immediate arg of logical ops is 0xffff
https://bugs.webkit.org/show_bug.cgi?id=152884
Reviewed by Michael Saboff.
Replaced imm.m_value < 65535 checks with imm.m_value <= 65535
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::and32):
(JSC::MacroAssemblerMIPS::or32):
2016-01-08 Konstantin Tokarev <annulen@yandex.ru>
[mips] Add new or32 implementation after r194613
https://bugs.webkit.org/show_bug.cgi?id=152865
Reviewed by Michael Saboff.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::or32):
2016-01-07 Filip Pizlo <fpizlo@apple.com>
FTL B3 lazy slow paths should do exceptions
https://bugs.webkit.org/show_bug.cgi?id=152853
Reviewed by Saam Barati.
This reduces the number of JSC test failures to 97.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
* tests/stress/ftl-new-negative-array-size.js: Added.
(foo):
2016-01-07 Filip Pizlo <fpizlo@apple.com>
Unreviewed, skip more tests that fail.
* tests/stress/ftl-shr-exception.js:
(foo):
* tests/stress/ftl-xor-exception.js:
(foo):
2016-01-07 Filip Pizlo <fpizlo@apple.com>
FTL B3 binary snippets should do exceptions
https://bugs.webkit.org/show_bug.cgi?id=152852
Reviewed by Saam Barati.
This reduces the number of JSC test failures to 110.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::emitBinarySnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBinaryBitOpSnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::emitRightShiftSnippet):
* tests/stress/ftl-shr-exception.js: Added.
(foo):
(result.foo.valueOf):
* tests/stress/ftl-sub-exception.js: Added.
(foo):
(result.foo.valueOf):
* tests/stress/ftl-xor-exception.js: Added.
(foo):
(result.foo.valueOf):
2016-01-07 Filip Pizlo <fpizlo@apple.com>
Unreviewed, skipping this test. Looks like LLVM can't handle this one, either.
* tests/stress/ftl-call-varargs-bad-args-exception-interesting-live-state.js:
(foo):
2016-01-07 Filip Pizlo <fpizlo@apple.com>
Unreviewed, skipping this test. Looks like LLVM can't handle it.
* tests/stress/ftl-put-by-id-setter-exception-interesting-live-state.js:
(foo):
2016-01-07 Filip Pizlo <fpizlo@apple.com>
FTL B3 JS calls should do exceptions
https://bugs.webkit.org/show_bug.cgi?id=152851
Reviewed by Geoffrey Garen.
This reduces the number of JSC test failures with FTL B3 to 111.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
* tests/stress/ftl-call-bad-args-exception-interesting-live-state.js: Added.
* tests/stress/ftl-call-bad-callee-exception-interesting-live-state.js: Added.
* tests/stress/ftl-call-exception-interesting-live-state.js: Added.
* tests/stress/ftl-call-exception-no-catch.js: Added.
* tests/stress/ftl-call-exception.js: Added.
* tests/stress/ftl-call-varargs-bad-callee-exception-interesting-live-state.js: Added.
* tests/stress/ftl-call-varargs-exception-interesting-live-state.js: Added.
* tests/stress/ftl-call-varargs-exception-no-catch.js: Added.
* tests/stress/ftl-call-varargs-exception.js: Added.
2016-01-07 Filip Pizlo <fpizlo@apple.com>
FTL B3 PutById should do exceptions
https://bugs.webkit.org/show_bug.cgi?id=152850
Reviewed by Saam Barati.
Implemented PutById exception handling by following the idiom used in GetById. Reduces the
number of JSC test failures to 128.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
* tests/stress/ftl-put-by-id-setter-exception-interesting-live-state.js: Added.
* tests/stress/ftl-put-by-id-setter-exception-no-catch.js: Added.
* tests/stress/ftl-put-by-id-setter-exception.js: Added.
* tests/stress/ftl-put-by-id-slow-exception-interesting-live-state.js: Added.
* tests/stress/ftl-put-by-id-slow-exception-no-catch.js: Added.
* tests/stress/ftl-put-by-id-slow-exception.js: Added.
2016-01-07 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r194714.
https://bugs.webkit.org/show_bug.cgi?id=152864
it broke many JSC tests when FTL B3 is enabled (Requested by
pizlo on #webkit).
Reverted changeset:
"[JSC] When resolving Stack arguments, use addressing from SP
when addressing from FP is invalid"
https://bugs.webkit.org/show_bug.cgi?id=152840
http://trac.webkit.org/changeset/194714
2016-01-07 Konstantin Tokarev <annulen@yandex.ru>
[mips] Lower immediates of logical operations.
https://bugs.webkit.org/show_bug.cgi?id=152693
On MIPS immediate operands of andi, ori, and xori are required to be 16-bit
non-negative numbers.
Reviewed by Michael Saboff.
* offlineasm/mips.rb:
2016-01-07 Benjamin Poulain <bpoulain@apple.com>
[JSC] Update testCheckSubBadImm() for ARM64
https://bugs.webkit.org/show_bug.cgi?id=152846
Reviewed by Mark Lam.
* b3/testb3.cpp:
(JSC::B3::testCheckSubBadImm):
The test was assuming the constant can always be used
as immediate. That's obviously not the case on ARM64.
2016-01-07 Filip Pizlo <fpizlo@apple.com>
FTL B3 getById() should do exceptions
https://bugs.webkit.org/show_bug.cgi?id=152810
Reviewed by Saam Barati.
This adds abstractions for doing exceptions from patchpoints, and uses them to implement
exceptions from GetById. This covers all of the following ways that a GetById might throw an
exceptions:
- Throw without try/catch from the vmCall() in a GetById(Untyped:)
- Throw with try/catch from the vmCall() in a GetById(Untyped:)
- Throw without try/catch from the callOperation() in the patchpoint of a GetById
- Throw with try/catch from the callOperation() in the patchpoint of a GetById
- Throw without try/catch from the Call IC generated in the patchpoint of a GetById
- Throw with try/catch from the Call IC generated in the patchpoint of a GetById
This requires having a default exception target in FTL-generated code, and ensuring that this
target is generated regardless of whether we have branches to the B3 basic block of the
default exception target. This also requires adding some extra arguments to a
PatchpointValue, and then knowing that the arguments are used for OSR exit and not anything
else. This also requires associating the CallSiteIndex of the patchpoint with the register
set used for exit and with the OSR exit label for the unwind exit.
All of the stuff that you have to worry about when wiring a patchpoint to exception handling
is covered by the new PatchpointExceptionHandle object. You create one by calling
preparePatchpointForExceptions(). This sets up the B3 IR representation of the patchpoint
with stackmap arguments for the exceptional exit, and creates a PatchpointExceptionHandle
object that can be used to create zero or more actual OSR exits. It can create both OSR exits
for operation calls and OSR exits for unwind. You call the
PatchpointExceptionHandle::scheduleExitCreationXXX() methods from the generator callback to
actually get OSR exits.
This API makes heavy use of Box<>, late paths, and link tasks. For example, you can use the
PatchpointExceptionHandle to get a Box<JumpList> that you can append exception jumps to. When
you use this API, it automatically registers a link task that will link the JumpList to the
actual OSR exit label.
This API is very flexible about how you get to the label of the OSR exit. You are encouraged
to use the Box<JumpList> approach, but if you really just need the label, you can also get
a RefPtr<ExceptionTarget> and rely on the fact that the ExceptionTarget object will be able
to vend you the OSR exit label at link-time.
This reduces the number of JSC test failures with FTL B3 from 186 to 133. It also adds a
bunch of new tests specifically for all of the ways you might throw from GetById, and B3
passes all of these new tests. Note that I'm not counting the new tests as part of the
previous 186 test failures (FTL B3 failed all of the new tests prior to this change).
After this change, it should be easy to make all of the other patchpoints also handle
exceptions by just following the preparePatchpointForExceptions() idiom.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3StackmapValue.h:
* b3/B3ValueRep.cpp:
(JSC::B3::ValueRep::addUsedRegistersTo):
(JSC::B3::ValueRep::usedRegisters):
(JSC::B3::ValueRep::dump):
* b3/B3ValueRep.h:
(JSC::B3::ValueRep::doubleValue):
(JSC::B3::ValueRep::withOffset):
(JSC::B3::ValueRep::usedRegisters):
* ftl/FTLB3Compile.cpp:
(JSC::FTL::compile):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::unreachable):
(JSC::FTL::Output::speculate):
* ftl/FTLExceptionTarget.cpp: Added.
(JSC::FTL::ExceptionTarget::~ExceptionTarget):
(JSC::FTL::ExceptionTarget::label):
(JSC::FTL::ExceptionTarget::jumps):
(JSC::FTL::ExceptionTarget::ExceptionTarget):
* ftl/FTLExceptionTarget.h: Added.
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBinarySnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBinaryBitOpSnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::emitRightShiftSnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::preparePatchpointForExceptions):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
* ftl/FTLPatchpointExceptionHandle.cpp: Added.
(JSC::FTL::PatchpointExceptionHandle::create):
(JSC::FTL::PatchpointExceptionHandle::defaultHandle):
(JSC::FTL::PatchpointExceptionHandle::~PatchpointExceptionHandle):
(JSC::FTL::PatchpointExceptionHandle::scheduleExitCreation):
(JSC::FTL::PatchpointExceptionHandle::scheduleExitCreationForUnwind):
(JSC::FTL::PatchpointExceptionHandle::PatchpointExceptionHandle):
(JSC::FTL::PatchpointExceptionHandle::createHandle):
* ftl/FTLPatchpointExceptionHandle.h: Added.
* ftl/FTLState.cpp:
* ftl/FTLState.h:
(JSC::FTL::verboseCompilationEnabled):
* tests/stress/ftl-get-by-id-getter-exception-interesting-live-state.js: Added.
* tests/stress/ftl-get-by-id-getter-exception-no-catch.js: Added.
* tests/stress/ftl-get-by-id-getter-exception.js: Added.
* tests/stress/ftl-get-by-id-slow-exception-interesting-live-state.js: Added.
* tests/stress/ftl-get-by-id-slow-exception-no-catch.js: Added.
* tests/stress/ftl-get-by-id-slow-exception.js: Added.
* tests/stress/ftl-operation-exception-interesting-live-state.js: Added.
* tests/stress/ftl-operation-exception-no-catch.js: Added.
2016-01-07 Konstantin Tokarev <annulen@yandex.ru>
[mips] Implemented missing branch patching methods.
https://bugs.webkit.org/show_bug.cgi?id=152845
Reviewed by Michael Saboff.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::canJumpReplacePatchableBranch32WithPatch):
(JSC::MacroAssemblerMIPS::startOfPatchableBranch32WithPatchOnAddress):
(JSC::MacroAssemblerMIPS::revertJumpReplacementToPatchableBranch32WithPatch):
2016-01-07 Benjamin Poulain <bpoulain@apple.com>
[JSC] When resolving Stack arguments, use addressing from SP when addressing from FP is invalid
https://bugs.webkit.org/show_bug.cgi?id=152840
Reviewed by Mark Lam.
ARM64 has two kinds of addressing with immediates:
-Signed 9bits direct (really only -256 to 255).
-Unsigned 12bits scaled by the load/store size.
When resolving the stack addresses, we easily run
past -256 bytes from FP. Addressing from SP gives us more
room to address the stack efficiently because we can
use unsigned immediates.
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::repForArg):
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
2016-01-07 Konstantin Tokarev <annulen@yandex.ru>
[mips] Make repatchCall public to fix compilation.
https://bugs.webkit.org/show_bug.cgi?id=152843
Reviewed by Michael Saboff.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::repatchCall):
(JSC::MacroAssemblerMIPS::linkCall): Deleted.
2016-01-07 Konstantin Tokarev <annulen@yandex.ru>
[mips] Replaced subi with addi in getHostCallReturnValue
https://bugs.webkit.org/show_bug.cgi?id=152841
Reviewed by Michael Saboff.
MIPS architecture does not have subi instruction, addi with negative
number should be used instead.
* jit/JITOperations.cpp:
2016-01-07 Mark Lam <mark.lam@apple.com>
ARMv7 or32(TrustedImm32, AbsoluteAddress) may have a bug with its use of dataTempRegister.
https://bugs.webkit.org/show_bug.cgi?id=152833
Reviewed by Michael Saboff.
Follow-up patch to fix illegal use of memoryTempRegister as the src for ARM64's
store32.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::or32):
(JSC::MacroAssemblerARM64::store):
2016-01-07 Konstantin Tokarev <annulen@yandex.ru>
[mips] GPRInfo::toArgumentRegister missing
https://bugs.webkit.org/show_bug.cgi?id=152838
Reviewed by Michael Saboff.
* jit/GPRInfo.h:
(JSC::GPRInfo::toArgumentRegister):
2016-01-07 Mark Lam <mark.lam@apple.com>
ARMv7 or32(TrustedImm32, AbsoluteAddress) may have a bug with its use of dataTempRegister.
https://bugs.webkit.org/show_bug.cgi?id=152833
Reviewed by Benjamin Poulain.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::or32):
- Added some assertions to make sure it is safe to use ARMRegisters::S0 as a temp.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::or32):
- Implement an optimization that avoids reloading the memoryTempRegister when
the immediate is encodable as an instruction immediate.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::or32):
- Added an assertion to make sure it is safe to use the dataTempRegister as a temp.
- Implement an optimization that avoids reloading the memoryTempRegister when
the immediate is encodable as an instruction immediate. In the event that we
cannot encode the immediate, we'll use the addressTempRegister as a temp, and
reload it later.
2016-01-07 Konstantin Tokarev <annulen@yandex.ru>
[CMake] JSC shell sources should include JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES
https://bugs.webkit.org/show_bug.cgi?id=152664
Reviewed by Alex Christensen.
* shell/CMakeLists.txt:
2016-01-06 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: CRASH Attempting to pause on CSP violation not inside of script
https://bugs.webkit.org/show_bug.cgi?id=152825
<rdar://problem/24021276>
Reviewed by Timothy Hatcher.
* debugger/Debugger.cpp:
(JSC::Debugger::breakProgram):
We cannot pause if we are not evaluating JavaScript, so bail.
2016-01-07 Benjamin Poulain <bpoulain@apple.com>
[JSC] Re-enable lea() in Air on ARM64
https://bugs.webkit.org/show_bug.cgi?id=152832
Reviewed by Michael Saboff.
Lea() on the MacroAssembler is not the full x86 Lea (the real one being
x86Lea32()). Instead, it is a addPtr() with SP and a constant.
The instruction is required to implement B3's StackSlot. It is not
safe for big offsets but none of the stack operations are at the moment.
* b3/air/AirOpcode.opcodes:
2016-01-07 Julien Brianceau <jbriance@cisco.com>
[mips] Add two missing abortWithReason implementations
https://bugs.webkit.org/show_bug.cgi?id=136753
Reviewed by Benjamin Poulain.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::memoryFence):
(JSC::MacroAssemblerMIPS::abortWithReason):
(JSC::MacroAssemblerMIPS::readCallTarget):
2016-01-07 Csaba Osztrogonác <ossy@webkit.org>
Add new or32 implementation to MacroAssemblerARM after r194613
https://bugs.webkit.org/show_bug.cgi?id=152784
Reviewed by Benjamin Poulain.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::or32):
2016-01-06 Mark Lam <mark.lam@apple.com>
REGRESSION(r194613): JITMulGenerator needs a scratch GPR on 32-bit too.
https://bugs.webkit.org/show_bug.cgi?id=152805
Reviewed by Michael Saboff.
There aren't enough registers on x86 32-bit to allocate the needed scratch GPR.
So, we'll continue to use one of the result registers as the scratch, and
re-compute the result at the end.
* jit/JITMulGenerator.cpp:
(JSC::JITMulGenerator::generateFastPath):
2016-01-06 Anders Carlsson <andersca@apple.com>
Add a smart block pointer
https://bugs.webkit.org/show_bug.cgi?id=152799
Reviewed by Tim Horton.
Get rid of RemoteTargetBlock and replace it with WTF::BlockPtr<void ()>.
* inspector/remote/RemoteConnectionToTarget.h:
(Inspector::RemoteTargetBlock::RemoteTargetBlock): Deleted.
(Inspector::RemoteTargetBlock::~RemoteTargetBlock): Deleted.
(Inspector::RemoteTargetBlock::operator=): Deleted.
(Inspector::RemoteTargetBlock::operator()): Deleted.
* inspector/remote/RemoteConnectionToTarget.mm:
(Inspector::RemoteTargetQueueTaskOnGlobalQueue):
(Inspector::RemoteConnectionToTarget::queueTaskOnPrivateRunLoop):
2016-01-06 Benjamin Poulain <bpoulain@apple.com>
[JSC] More B3 tests passing on ARM64
https://bugs.webkit.org/show_bug.cgi?id=152787
Reviewed by Michael Saboff.
Some more minor bugs.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::urshift64):
The offset was being truncated. That code was just copied
from the 32bits version of urshift.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createGenericCompare):
Very few instructions can encode -1 as immediate.
TST certainly can't. The fallback works for ARM.
* b3/air/AirOpcode.opcodes:
Bit instructions have very specific immediate encoding.
B3 cannot express that properly yet. I disabled those
forms for now. Immediates encoding is something we'll really
have to look into at some point for B3 ARM64.
2016-01-06 Michael Catanzaro <mcatanzaro@igalia.com>
Silence -Wtautological-compare
https://bugs.webkit.org/show_bug.cgi?id=152768
Reviewed by Saam Barati.
* runtime/Options.cpp:
(JSC::Options::setAliasedOption):
2016-01-06 Filip Pizlo <fpizlo@apple.com>
Make sure that the basic throw-from-operation mode of throwing makes sense in FTL B3
https://bugs.webkit.org/show_bug.cgi?id=152798
Reviewed by Oliver Hunt.
This really just contains one change: we inline emitBranchToOSRExitIfWillCatchException()
into callCheck(), since that was its only caller. This makes it a bit more clear what is
going on.
It turns out that FTL B3 already handled this case properly. I added a test that I believe
illustrates this. Note that although the test uses GetById, which ordinarily throws
exceptions from inside a patchpoint, it uses it in such a way that the exception is thrown
from the operation call for the non-cell bypass path of a GetById(UntypedUse:).
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBranchToOSRExitIfWillCatchException): Deleted.
* tests/stress/ftl-operation-exception.js: Added.
(foo):
2016-01-06 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove duplicate check
https://bugs.webkit.org/show_bug.cgi?id=152792
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.RemoteObject.prototype._generatePreview): Deleted.
This method is only called from one place, and it does an equivalent
check before calling this function. Remove the duplicate check.
2016-01-06 Brian Burg <bburg@apple.com>
Add a WebKit SPI for registering an automation controller with RemoteInspector
https://bugs.webkit.org/show_bug.cgi?id=151576
Reviewed by Dan Bernstein and Joseph Pecoraro.
Given a RemoteInspector endpoint that is instantiated in UIProcess, there
should be a way to delegate automation-related functionality and policy to
clients of WebKit.
This class adds a RemoteInspector::Client interface that serves a delegate.
This is ultimately delegated via _WKAutomationDelegate, which is an SPI
that allows clients to install an Objective-C delegate for automation.
The setting for whether remote automation is allowed is included in the
listing that RemoteInspector sends out. It is updated when RemoteInspector::Client
is assigned, or when the client signals that its capabilities have changed.
* inspector/remote/RemoteInspector.h:
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::setRemoteInspectorClient): Added.
(Inspector::RemoteInspector::pushListingsNow):
In the listing, include whether the application supports remote automation.
* inspector/remote/RemoteInspectorConstants.h: Add a constant.
2016-01-05 Keith Miller <keith_miller@apple.com>
[ES6] Boolean, Number, Map, RegExp, and Set should be subclassable
https://bugs.webkit.org/show_bug.cgi?id=152765
Reviewed by Michael Saboff.
This patch enables subclassing of five more builtins: Boolean, Number, Map, RegExp, and Set.
* runtime/BooleanConstructor.cpp:
(JSC::constructWithBooleanConstructor):
(JSC::constructBoolean): Deleted.
* runtime/BooleanConstructor.h:
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/NumberConstructor.cpp:
(JSC::constructWithNumberConstructor):
* runtime/RegExpConstructor.cpp:
(JSC::getRegExpStructure):
(JSC::constructRegExp):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* tests/es6.yaml:
* tests/stress/class-subclassing-misc.js: Added.
(B):
(N):
(M):
(R):
(S):
(test):
2016-01-06 Julien Brianceau <jbriance@cisco.com>
[mips] Fix branchTruncateDoubleToUint32 implementation in macro assembler
https://bugs.webkit.org/show_bug.cgi?id=152782
Reviewed by Benjamin Poulain.
Already covered by LayoutTests/js/dfg-uint32array-overflow-values test.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branchTruncateDoubleToUint32):
2016-01-06 Julien Brianceau <jbriance@cisco.com>
[mips] Fix or32 implementation in macro assembler
https://bugs.webkit.org/show_bug.cgi?id=152781
Reviewed by Michael Saboff.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::or32):
2016-01-06 Julien Brianceau <jbriance@cisco.com>
[mips] Add missing branchAdd32 implementation in macro assembler
https://bugs.webkit.org/show_bug.cgi?id=152785
Reviewed by Michael Saboff.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branchAdd32):
2016-01-06 Andy VanWagoner <thetalecrafter@gmail.com>
[ES6] Date.prototype should be a plain object
https://bugs.webkit.org/show_bug.cgi?id=152574
Reviewed by Benjamin Poulain.
* runtime/DateConstructor.cpp:
(JSC::DateConstructor::finishCreation):
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::DatePrototype):
* runtime/DatePrototype.h:
* tests/mozilla/mozilla-tests.yaml: Expect errors from old Date.prototype as Date instance tests.
2016-01-06 Benjamin Poulain <bpoulain@apple.com>
[JSC] Get more of testb3 to pass on ARM64
https://bugs.webkit.org/show_bug.cgi?id=152737
Reviewed by Geoffrey Garen.
A bunch of minor bugs and missing function to make most of testb3
run on ARM64.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::canEncodePImmOffset):
(JSC::ARM64Assembler::canEncodeSImmOffset):
(JSC::isInt9): Deleted.
(JSC::isUInt12): Deleted.
* assembler/ARMv7Assembler.h:
* assembler/AssemblerCommon.h: Added.
(JSC::isInt9):
(JSC::isUInt12):
(JSC::isValidScaledUImm12):
(JSC::isValidSignedImm9):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load16SignedExtendTo32):
(JSC::MacroAssemblerARM64::load8SignedExtendTo32):
(JSC::MacroAssemblerARM64::store16):
(JSC::MacroAssemblerARM64::absFloat):
(JSC::MacroAssemblerARM64::loadFloat):
(JSC::MacroAssemblerARM64::storeFloat):
(JSC::MacroAssemblerARM64::loadSignedAddressedByUnsignedImmediate):
(JSC::MacroAssemblerARM64::loadSignedAddressedByUnscaledImmediate):
(JSC::MacroAssemblerARM64::tryLoadSignedWithOffset):
(JSC::MacroAssemblerARM64::loadSignedAddressedByUnsignedImmediate<8>):
(JSC::MacroAssemblerARM64::loadSignedAddressedByUnsignedImmediate<16>):
(JSC::MacroAssemblerARM64::loadSignedAddressedByUnscaledImmediate<8>):
(JSC::MacroAssemblerARM64::loadSignedAddressedByUnscaledImmediate<16>):
* assembler/X86Assembler.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isValidImmForm):
(JSC::B3::Air::Arg::isValidAddrForm):
(JSC::B3::Air::Arg::isValidForm):
* b3/air/AirOpcode.opcodes:
2016-01-05 Zan Dobersek <zdobersek@igalia.com>
[CMake] Remove USE_UDIS86 variable
https://bugs.webkit.org/show_bug.cgi?id=152731
Reviewed by Gyuyoung Kim.
* CMakeLists.txt: Unconditionally build the Udis86-specific files.
2016-01-05 Filip Pizlo <fpizlo@apple.com>
FTL B3 fails cdjs-tests.yaml/red_black_tree_test.js.ftl-eager-no-cjit
https://bugs.webkit.org/show_bug.cgi?id=152770
Reviewed by Mark Lam.
It turns out that liveness didn't know that the return value GPR or FPR is live at the
return. Consequently, we can end up with code that clobbers the return value register after
the move of the return value into that register. This could happen if we start with
something like:
Move 42(%tmp1), %tmp2
Move 50(%tmp1), %tmp3
Move %tmp3, 58(%tmp1)
Move %tmp2, %rax
Ret
Then we might coalesce %tmp2 with %rax:
Move 42(%tmp1), %rax
Move 50(%tmp1), %tmp3
Move %tmp3, 58(%tmp1)
Ret
But now there is no use of %rax after that first instruction, so %rax appears dead at the
other two Move's. So, the register allocator could then do this:
Move 42(%tmp1), %rax
Move 50(%tmp1), %rax
Move %rax, 58(%tmp1)
Ret
And that's clearly wrong. This patch solves this issue by replacing the old Ret instruction
with Ret32, Ret64, RetFloat, and RetDouble. These all take the return value register as an
argument. They also tell Air which parts of the return value register the caller will
observe. That's great for width analysis.
This resolves a test failure in the CDjs red_black_tree_test. This reduces the total number
of JSC test failures from 217 to 191.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::oops):
(JSC::MacroAssembler::ret32):
(JSC::MacroAssembler::ret64):
(JSC::MacroAssembler::retFloat):
(JSC::MacroAssembler::retDouble):
(JSC::MacroAssembler::shouldConsiderBlinding):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirOpcode.opcodes:
* b3/air/opcode_generator.rb:
2016-01-05 Keith Miller <keith_miller@apple.com>
Unreviewed build fix. A symbol was being exported that should not have been.
* runtime/Structure.h:
2016-01-05 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r194603.
https://bugs.webkit.org/show_bug.cgi?id=152762
This change introduced JSC test failures (Requested by
ryanhaddad on #webkit).
Reverted changeset:
"[ES6] Date.prototype should be a plain object"
https://bugs.webkit.org/show_bug.cgi?id=152574
http://trac.webkit.org/changeset/194603
2016-01-05 Filip Pizlo <fpizlo@apple.com>
stress/v8-crypto-strict.js.ftl-eager-no-cjit in FTL B3 fails with an assertion in the callframe shuffler
https://bugs.webkit.org/show_bug.cgi?id=152756
Reviewed by Saam Barati.
This fixes a really obvious and dumb tail call bug in FTL B3. I think that tail calls work
for real now. I have no idea why I got any tail call tests to pass before this fix.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
2016-01-04 Mark Lam <mark.lam@apple.com>
Profiling should detect when multiplication overflows but does not create negative zero.
https://bugs.webkit.org/show_bug.cgi?id=132470
Reviewed by Geoffrey Garen.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::or32):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::or32):
- New or32 emitter needed by the mul snippet.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::resultProfileForBytecodeOffset):
(JSC::CodeBlock::updateResultProfileForBytecodeOffset): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::ensureResultProfile):
(JSC::CodeBlock::addResultProfile): Deleted.
(JSC::CodeBlock::likelyToTakeDeepestSlowCase): Deleted.
- Added a m_bytecodeOffsetToResultProfileIndexMap because we can now add result
profiles in any order (based on runtime execution), not necessarily in bytecode
order at baseline compilation time.
* bytecode/ValueProfile.cpp:
(WTF::printInternal):
* bytecode/ValueProfile.h:
(JSC::ResultProfile::didObserveInt52Overflow):
(JSC::ResultProfile::setObservedInt52Overflow):
- Add new Int52Overflow flags.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
- Now with more straightforward mapping of profiling info.
* dfg/DFGCommon.h:
- Fixed a typo in a comment.
* dfg/DFGNode.h:
(JSC::DFG::Node::arithNodeFlags):
(JSC::DFG::Node::mayHaveNonIntResult):
(JSC::DFG::Node::hasConstantBuffer):
* dfg/DFGNodeFlags.cpp:
(JSC::DFG::dumpNodeFlags):
* dfg/DFGNodeFlags.h:
(JSC::DFG::nodeMayOverflowInt52):
(JSC::DFG::nodeCanSpeculateInt52):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
- We now have profiling info for whether the result was ever seen to be a non-Int.
Use this to make a better prediction.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_div):
(JSC::JIT::emit_op_mul):
- Switch to using CodeBlock::ensureResultProfile(). ResultProfiles can now be
created at any time (including the slow path), not just in bytecode order
during baseline compilation.
* jit/JITMulGenerator.cpp:
(JSC::JITMulGenerator::generateFastPath):
- Removed the fast path profiling code for NegZero because we'll go to the slow
path anyway. Let the slow path do the profiling for us.
- Added profiling for NegZero and potential Int52 overflows in the fast path
that does double math.
* runtime/CommonSlowPaths.cpp:
(JSC::updateResultProfileForBinaryArithOp):
- Removed the RETURN_WITH_RESULT_PROFILING macro (2 less macros), and just use
the RETURN_WITH_PROFILING macro instead with a call to
updateResultProfileForBinaryArithOp(). This makes it clear what we're doing
to do profiling in each case, and also allows us to do custom profiling for
each opcode if needed. However, so far, we always call
updateResultProfileForBinaryArithOp().
2016-01-05 Keith Miller <keith_miller@apple.com>
[ES6] Arrays should be subclassable.
https://bugs.webkit.org/show_bug.cgi?id=152706
Reviewed by Benjamin Poulain.
This patch enables full subclassing of Arrays. We do this by fetching the new.target's prototype property
in the Array constructor and transitioning the old structure to have the new prototype. This method has
two downsides. The first is that we clobber the transition watchpoint on the base structure. The second,
which is currently very significant but should be fixed in a future patch, is that we allocate a new
structure for each new derived class we allocate.
* runtime/ArrayConstructor.cpp:
(JSC::constructArrayWithSizeQuirk):
(JSC::constructWithArrayConstructor):
(JSC::callArrayConstructor):
* runtime/ArrayConstructor.h:
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation):
(JSC::JSGlobalObject::arrayStructureForProfileDuringAllocation):
(JSC::constructEmptyArray):
(JSC::constructArray):
(JSC::constructArrayNegativeIndexed):
* runtime/PrototypeMap.h:
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::createSubclassStructure):
* tests/es6.yaml:
* tests/stress/class-subclassing-array.js: Added.
(A):
(B.prototype.get 1):
(B):
(C):
(test):
2016-01-05 Filip Pizlo <fpizlo@apple.com>
regress/script-tests/deltablue-varargs.js.ftl-no-cjit-no-put-stack-validate on FTL B3 gets a B3 validation failure
https://bugs.webkit.org/show_bug.cgi?id=152754
Reviewed by Geoffrey Garen and Saam Barati.
It turns out that the FTL was creating orphans. Rather than making the FTL handle them by
itself, I gave B3 the power to eliminate them for you. I also made the dumper print them
since otherwise, you wouldn't know anything about the orphan when looking at a validation
failure or other kind of procedure dump.
* b3/B3IndexSet.h:
(JSC::B3::IndexSet::add):
(JSC::B3::IndexSet::addAll):
(JSC::B3::IndexSet::remove):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::dump):
(JSC::B3::Procedure::deleteValue):
(JSC::B3::Procedure::deleteOrphans):
(JSC::B3::Procedure::dominators):
* b3/B3Procedure.h:
(JSC::B3::Procedure::cfg):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
2015-12-24 Mark Lam <mark.lam@apple.com>
Re-landing: Add validation of JSC options to catch typos.
https://bugs.webkit.org/show_bug.cgi?id=152549
Reviewed by Benjamin Poulain.
1. If a JSC_xxx option is found and xxx is not a valid option, we will now log
an error message.
2. If a --xxx jsc option is specified, but xxx is not a valid option, we will
now log an error message.
3. Added JSC_validateOptions, which if set to true will cause the VM to crash if
an invalid option was seen during options parsing.
In this version for re-landing, I removed the change where I disallowed -- options
after the script name. Apparently, we have some test harnesses that do append the
-- options after the script name.
* jsc.cpp:
(CommandLine::parseArguments):
* runtime/Options.cpp:
(JSC::Options::initialize):
* runtime/Options.h:
2016-01-05 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do ArithNegate
https://bugs.webkit.org/show_bug.cgi?id=152745
Reviewed by Geoffrey Garen.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithNegate):
2016-01-05 Andy VanWagoner <thetalecrafter@gmail.com>
[ES6] Date.prototype should be a plain object
https://bugs.webkit.org/show_bug.cgi?id=152574
Reviewed by Benjamin Poulain.
* runtime/DateConstructor.cpp:
(JSC::DateConstructor::finishCreation):
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::DatePrototype):
* runtime/DatePrototype.h:
2016-01-05 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r194590.
https://bugs.webkit.org/show_bug.cgi?id=152751
"Causes bot failures" (Requested by mlam on #webkit).
Reverted changeset:
"Add validation of JSC options to catch typos."
https://bugs.webkit.org/show_bug.cgi?id=152549
http://trac.webkit.org/changeset/194590
2016-01-05 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do In
https://bugs.webkit.org/show_bug.cgi?id=152744
Reviewed by Michael Saboff.
This was easy; I just used the same idiom that we already established for ICs in FTL B3.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
2016-01-05 Filip Pizlo <fpizlo@apple.com>
Implement B3 version of FTL::Output::check()
https://bugs.webkit.org/show_bug.cgi?id=152743
Reviewed by Geoffrey Garen.
Turns out this was just like the LLVM version.
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::branch):
(JSC::FTL::Output::check):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::switchInstruction):
(JSC::FTL::Output::check): Deleted.
2016-01-05 Mark Lam <mark.lam@apple.com>
Add support for aliasing JSC Options.
https://bugs.webkit.org/show_bug.cgi?id=152551
Reviewed by Filip Pizlo.
This allows us to use old options names as well. This is for the benefit of
third party tools which may have been built to rely on those old options. The
old option names will be mapped to the current option names in setOption().
For some options, the old option name specifies the inverse boolean value of the
current option name. setOption() will take care of inverting the value before
applying it to the option.
* jsc.cpp:
(CommandLine::parseArguments):
- Switch to dumping only overridden options here. Verbose dumping is too much
for common usage.
* runtime/Options.cpp:
(JSC::overrideOptionWithHeuristic):
(JSC::Options::overrideAliasedOptionWithHeuristic):
(JSC::computeNumberOfWorkerThreads):
(JSC::Options::initialize):
(JSC::Options::setOptionWithoutAlias):
(JSC::invertBoolOptionValue):
(JSC::Options::setAliasedOption):
(JSC::Options::setOption):
(JSC::Options::dumpAllOptions):
- String.ascii() converts newline characters to '?', and this was messing up the
printing of the options. Switched to using String.utf8() instead.
(JSC::Options::dumpOption):
* runtime/Options.h:
2016-01-05 Mark Lam <mark.lam@apple.com>
Add validation of JSC options to catch typos.
https://bugs.webkit.org/show_bug.cgi?id=152549
Reviewed by Benjamin Poulain.
1. If a JSC_xxx option is found and xxx is not a valid option, we will now log
an error message.
2. The jsc app is commonly used as follows:
$ jsc [jsc options] [scripts]
Previously, we'll continue to parse for [jsc options] after [scripts] is seen.
We won't do this anymore. Any --xxx jsc options must precede the [scripts]
arguments.
3. If a --xxx jsc option is specified, but xxx is not a valid option, we will
now log an error message.
4. Added JSC_validateOptions, which if set to true will cause the VM to crash if
an invalid option was seen during options parsing.
* jsc.cpp:
(CommandLine::parseArguments):
* runtime/Options.cpp:
(JSC::Options::initialize):
* runtime/Options.h:
2016-01-04 Keith Miller <keith_miller@apple.com>
Turn off Internal Function inlining in the DFG for super calls.
https://bugs.webkit.org/show_bug.cgi?id=152695
Reviewed by Geoffrey Garen.
Currently, we inline several InternalFunctions into an alloctation with a
fixed structure in the DFG. This optimization is not valid when the
InternalFunction is called via a super call.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::attemptToInlineCall):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2016-01-04 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do binary snippets
https://bugs.webkit.org/show_bug.cgi?id=152668
Reviewed by Mark Lam.
This finishes all of the rest of the snippets.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitOr):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitXor):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitRShift):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitLShift):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitURShift):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBinaryBitOpSnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::emitRightShiftSnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
* tests/stress/object-bit-or.js: Added.
(foo):
(things.valueOf):
* tests/stress/object-bit-xor.js: Added.
(foo):
(things.valueOf):
* tests/stress/object-lshift.js: Added.
(foo):
(things.valueOf):
* tests/stress/object-rshift.js: Added.
(foo):
(things.valueOf):
* tests/stress/object-urshift.js: Added.
(foo):
(things.valueOf):
* tests/stress/untyped-bit-or.js: Added.
(foo):
(valueOf):
* tests/stress/untyped-bit-xor.js: Added.
(foo):
(valueOf):
* tests/stress/untyped-lshift.js: Added.
(foo):
(valueOf):
* tests/stress/untyped-rshift.js: Added.
(foo):
(valueOf):
* tests/stress/untyped-urshift.js: Added.
(foo):
(valueOf):
2016-01-04 Mark Lam <mark.lam@apple.com>
isUntypedSpeculationForArithmetic is wrong.
https://bugs.webkit.org/show_bug.cgi?id=152708
Reviewed by Filip Pizlo.
The isUntypedSpeculation...() checks should return true is we ever see
non-numeric types, regardless of whether numeric types are seen or not.
Previously, they only return true if we only see non-numeric types, and false if
we ever see numeric types.
This patch is perf neutral on both x86_64 and x86.
* bytecode/SpeculatedType.h:
(JSC::isUntypedSpeculationForArithmetic):
(JSC::isUntypedSpeculationForBitOps):
2016-01-04 Tim Horton <timothy_horton@apple.com>
Turn on gesture events when building for Yosemite
https://bugs.webkit.org/show_bug.cgi?id=152704
rdar://problem/24042472
Reviewed by Anders Carlsson.
* Configurations/FeatureDefines.xcconfig:
2016-01-04 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do BitAnd binary snippets
https://bugs.webkit.org/show_bug.cgi?id=152713
Reviewed by Mark Lam.
Getting ready to finish up the binary bitop snippets.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitAnd):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBinarySnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBinaryBitOpSnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
* tests/stress/object-bit-and.js: Added.
(foo):
(things.valueOf):
* tests/stress/untyped-bit-and.js: Added.
(foo):
(valueOf):
2016-01-04 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do all of the non-bitop binary snippets
https://bugs.webkit.org/show_bug.cgi?id=152709
Reviewed by Mark Lam.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
* tests/stress/object-add.js: Added.
(foo):
(things.valueOf):
* tests/stress/object-div.js: Added.
(foo):
(things.valueOf):
* tests/stress/object-mul.js: Added.
(foo):
(things.valueOf):
* tests/stress/untyped-add.js: Added.
(foo):
(valueOf):
* tests/stress/untyped-div.js: Added.
(foo):
(valueOf):
* tests/stress/untyped-mul.js: Added.
(foo):
(valueOf):
2016-01-04 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do the ArithSub binary snippet
https://bugs.webkit.org/show_bug.cgi?id=152705
Reviewed by Saam Barati.
This implements the ArithSub binary snippet generator in FTL B3.
While doing this, I discovered that the DFG type inference logic for ArithSub contains a
classic mistake: it causes the snippets to kick in when the type set does not contain numbers
rather than kicking in when the type set contains non-numbers. So, the original test that I
wrote for this doesn't work right (it runs to completion but OSR exits ad infinitum). I wrote
a second test that is simpler, and that one shows that the binary snippets "work". That's
sort of a joke though, since the only way to trigger binary snippets is to never pass numbers
and the only way to actually cause a binary snippet to do meaninful work is to pass numbers.
I filed a bug about this mess: https://bugs.webkit.org/show_bug.cgi?id=152708.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileUntypedBinaryOp):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBinarySnippet):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
* tests/stress/object-sub.js: Added.
(foo):
(things.valueOf):
* tests/stress/untyped-sub.js: Added.
(foo):
(valueOf):
2016-01-04 Filip Pizlo <fpizlo@apple.com>
Unreviewed, disable FTL B3 for now. I didn't intend to enable it yet.
* dfg/DFGCommon.h:
2016-01-04 Filip Pizlo <fpizlo@apple.com>
B3 patchpoints should allow requesting scratch registers
https://bugs.webkit.org/show_bug.cgi?id=152669
Reviewed by Benjamin Poulain.
Scratch registers are something that we often need in many patchpoint use cases. In LLVM's
patchpoints, we didn't have a good way to request scratch registers. So, our current FTL code
often does crazy scratch register allocation madness even when it would be better to just ask
the backend for some registers. This patch adds a mechanism for requesting scratch registers
in B3, and wires it all the way to all of our register allocation and liveness
infrastructure.
From the standpoint of a patchpoint, a "scratch register" is an instruction argument that
only admits Tmp and is defined early (like an early clobber register) and is used late (like
what we previously called LateUse, except that this time it's also a warm use). We already
had the beginning of support for early def's because of early clobbers, and we already
supported late uses albeit cold ones. I really only needed to add one new role: "Scratch",
which means both early def and late use in much the same way as "UseDef" means both early
use and late def. But, it feels better to complete the set of roles, so I added LateColdUse
to differentiate from LateUse (which is now a warm use) and EarlyDef to differentiate from
Def (which is, and always has been, a late def). Forcing the code to deal with the full
matrix of possibilities resulted in what is probably a progression in how we handle defs in
the register and stack allocators. The new Inst::forEachDef(Inst*, Inst*, callback) fully
recognizes that a "def" is something that can come from either the preceding instruction or
the succeeding one.
This doesn't add any new functionality to FTL B3 yet, but the new scratch register mechanism
is covered by new testb3 tests.
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::isValid):
(JSC::B3::CheckSpecial::admitsStack):
(JSC::B3::CheckSpecial::generate):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::forEachArg):
(JSC::B3::PatchpointSpecial::isValid):
(JSC::B3::PatchpointSpecial::admitsStack):
(JSC::B3::PatchpointSpecial::generate):
* b3/B3PatchpointValue.cpp:
(JSC::B3::PatchpointValue::dumpMeta):
(JSC::B3::PatchpointValue::PatchpointValue):
* b3/B3PatchpointValue.h:
* b3/B3StackmapGenerationParams.cpp:
(JSC::B3::StackmapGenerationParams::unavailableRegisters):
* b3/B3StackmapGenerationParams.h:
(JSC::B3::StackmapGenerationParams::gpScratch):
(JSC::B3::StackmapGenerationParams::fpScratch):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
(JSC::B3::StackmapSpecial::isValidImpl):
(JSC::B3::StackmapSpecial::admitsStackImpl):
(JSC::B3::StackmapSpecial::repsImpl):
(JSC::B3::StackmapSpecial::isArgValidForValue):
(JSC::B3::StackmapSpecial::appendRepsImpl): Deleted.
* b3/B3StackmapSpecial.h:
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirArg.cpp:
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isAnyUse):
(JSC::B3::Air::Arg::isColdUse):
(JSC::B3::Air::Arg::isEarlyUse):
(JSC::B3::Air::Arg::isLateUse):
(JSC::B3::Air::Arg::isAnyDef):
(JSC::B3::Air::Arg::isEarlyDef):
(JSC::B3::Air::Arg::isLateDef):
(JSC::B3::Air::Arg::isZDef):
(JSC::B3::Air::Arg::Arg):
(JSC::B3::Air::Arg::imm):
(JSC::B3::Air::Arg::isDef): Deleted.
* b3/air/AirBasicBlock.h:
(JSC::B3::Air::BasicBlock::at):
(JSC::B3::Air::BasicBlock::get):
(JSC::B3::Air::BasicBlock::last):
* b3/air/AirEliminateDeadCode.cpp:
(JSC::B3::Air::eliminateDeadCode):
* b3/air/AirFixPartialRegisterStalls.cpp:
(JSC::B3::Air::fixPartialRegisterStalls):
* b3/air/AirInst.cpp:
(JSC::B3::Air::Inst::hasArgEffects):
* b3/air/AirInst.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::extraEarlyClobberedRegs):
(JSC::B3::Air::Inst::forEachDef):
(JSC::B3::Air::Inst::forEachDefWithExtraClobberedRegs):
(JSC::B3::Air::Inst::reportUsedRegisters):
(JSC::B3::Air::Inst::forEachTmpWithExtraClobberedRegs): Deleted.
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirLiveness.h:
(JSC::B3::Air::AbstractLiveness::AbstractLiveness):
(JSC::B3::Air::AbstractLiveness::LocalCalc::execute):
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/AirTmpWidth.cpp:
(JSC::B3::Air::TmpWidth::recompute):
* b3/air/AirUseCounts.h:
(JSC::B3::Air::UseCounts::UseCounts):
* b3/testb3.cpp:
(JSC::B3::testPatchpointAny):
(JSC::B3::testPatchpointGPScratch):
(JSC::B3::testPatchpointFPScratch):
(JSC::B3::testPatchpointLotsOfLateAnys):
(JSC::B3::run):
2016-01-04 Csaba Osztrogonác <ossy@webkit.org>
Fix the !ENABLE(INTL) build after r193493
https://bugs.webkit.org/show_bug.cgi?id=152689
Reviewed by Alex Christensen.
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation):
2016-01-04 Csaba Osztrogonác <ossy@webkit.org>
JSC generator scripts shouldn't have verbose output
https://bugs.webkit.org/show_bug.cgi?id=152382
Reviewed by Michael Catanzaro.
* b3/air/opcode_generator.rb:
* generate-bytecode-files:
* offlineasm/asm.rb:
* offlineasm/generate_offset_extractor.rb:
* offlineasm/parser.rb:
2016-01-04 Benjamin Poulain <bpoulain@apple.com>
[JSC] Build B3 by default on iOS ARM64
https://bugs.webkit.org/show_bug.cgi?id=152525
Reviewed by Filip Pizlo.
Minor changes required to get testb3 to compile.
* Configurations/ToolExecutable.xcconfig:
We need an entitlement to allocate executable memory.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::scratchRegister):
(JSC::MacroAssemblerARM64::getCachedDataTempRegisterIDAndInvalidate):
(JSC::MacroAssemblerARM64::getCachedMemoryTempRegisterIDAndInvalidate):
Expose one of the scratch registers for ValueRep::emitRestore().
Guard the use of scratch registers when not allowed.
* b3/air/AirOpcode.opcodes:
ARM addressing is a bit different. Skip Addr to make things build.
* b3/testb3.cpp:
(JSC::B3::testPatchpointWithStackArgumentResult):
Add on memory only exists on x86.
* jit/RegisterSet.cpp:
(JSC::RegisterSet::macroScratchRegisters):
Add the two scratch registers, useful for patchpoints.
2016-01-03 Khem Raj <raj.khem@gmail.com>
WebKit fails to build with musl libc library
https://bugs.webkit.org/show_bug.cgi?id=152625
Reviewed by Daniel Bates.
Qualify isnan() calls with std namespace.
* runtime/Options.cpp:
(Option::operator==): Add std namespace qualifier.
2016-01-03 Andreas Kling <akling@apple.com>
Remove redundant StringImpl substring creation function.
<https://webkit.org/b/152652>
Reviewed by Daniel Bates.
Remove jsSubstring8() and make the only call site use jsSubstring().
* runtime/JSString.h:
(JSC::jsSubstring8): Deleted.
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
2016-01-02 Khem Raj <raj.khem@gmail.com>
Clang's builtin for clear_cache accepts char* and errors out
when using void*, using char* work on both gcc and clang
since char* is auto-converted to void* in gcc case.
https://bugs.webkit.org/show_bug.cgi?id=152654
Reviewed by Michael Saboff;
* assembler/ARM64Assembler.h:
(linuxPageFlush): Convert arguments to __builtin___clear_cache()
to char*.
2015-12-31 Andy Estes <aestes@apple.com>
Replace WTF::move with WTFMove
https://bugs.webkit.org/show_bug.cgi?id=152601
Reviewed by Brady Eidson.
* API/ObjCCallbackFunction.mm:
(JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl):
(JSC::ObjCCallbackFunction::ObjCCallbackFunction):
(JSC::ObjCCallbackFunction::create):
(objCCallbackFunctionForInvocation):
* assembler/AssemblerBuffer.h:
(JSC::AssemblerBuffer::releaseAssemblerData):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::linkCode):
* b3/B3BlockInsertionSet.cpp:
(JSC::B3::BlockInsertionSet::insert):
(JSC::B3::BlockInsertionSet::splitForward):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3OpaqueByproducts.cpp:
(JSC::B3::OpaqueByproducts::add):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addBlock):
(JSC::B3::Procedure::addDataSection):
* b3/B3Procedure.h:
(JSC::B3::Procedure::releaseByproducts):
* b3/B3ProcedureInlines.h:
(JSC::B3::Procedure::add):
* b3/B3Value.h:
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::addBlock):
(JSC::B3::Air::Code::addStackSlot):
(JSC::B3::Air::Code::addSpecial):
* b3/air/AirInst.h:
(JSC::B3::Air::Inst::Inst):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirSimplifyCFG.cpp:
(JSC::B3::Air::simplifyCFG):
* bindings/ScriptValue.cpp:
(Deprecated::jsToInspectorValue):
* builtins/BuiltinExecutables.cpp:
(JSC::createExecutableInternal):
* bytecode/BytecodeBasicBlock.cpp:
(JSC::computeBytecodeBasicBlocks):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setCalleeSaveRegisters):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCodeMap):
(JSC::CodeBlock::livenessAnalysis):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/GetByIdVariant.cpp:
(JSC::GetByIdVariant::GetByIdVariant):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerateWithCases):
(JSC::PolymorphicAccess::regenerateWithCase):
(JSC::PolymorphicAccess::regenerate):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/PutByIdVariant.cpp:
(JSC::PutByIdVariant::setter):
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::push):
* bytecode/StructureStubClearingWatchpoint.h:
(JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::addAccessCase):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::setInstructions):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/SetForScope.h:
(JSC::SetForScope::SetForScope):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::livenessFor):
(JSC::DFG::Graph::killsFor):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::JITFinalizer):
* dfg/DFGLivenessAnalysisPhase.cpp:
(JSC::DFG::LivenessAnalysisPhase::process):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
(JSC::DFG::SpeculativeJIT::compileIn):
(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::finishCreation):
* disassembler/Disassembler.cpp:
(JSC::disassembleAsynchronously):
* ftl/FTLB3Compile.cpp:
(JSC::FTL::compile):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::initializeB3Byproducts):
* ftl/FTLJITFinalizer.h:
(JSC::FTL::OutOfLineCodeInfo::OutOfLineCodeInfo):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
* heap/Heap.cpp:
(JSC::Heap::releaseDelayedReleasedObjects):
(JSC::Heap::markRoots):
(JSC::Heap::setIncrementalSweeper):
* heap/HeapInlines.h:
(JSC::Heap::releaseSoon):
(JSC::Heap::registerWeakGCMap):
* heap/WeakInlines.h:
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::addToFrontend):
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::searchInTextByLines):
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::getFunctionDetails):
(Inspector::InjectedScript::getProperties):
(Inspector::InjectedScript::getDisplayableProperties):
(Inspector::InjectedScript::getInternalProperties):
(Inspector::InjectedScript::getCollectionEntries):
(Inspector::InjectedScript::wrapCallFrames):
* inspector/InspectorAgentRegistry.cpp:
(Inspector::AgentRegistry::append):
(Inspector::AgentRegistry::appendExtraAgent):
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::CallbackBase::CallbackBase):
(Inspector::BackendDispatcher::CallbackBase::sendSuccess):
(Inspector::BackendDispatcher::BackendDispatcher):
(Inspector::BackendDispatcher::create):
(Inspector::BackendDispatcher::sendPendingErrors):
* inspector/InspectorProtocolTypes.h:
(Inspector::Protocol::Array::addItem):
* inspector/InspectorValues.cpp:
* inspector/InspectorValues.h:
(Inspector::InspectorObjectBase::setValue):
(Inspector::InspectorObjectBase::setObject):
(Inspector::InspectorObjectBase::setArray):
(Inspector::InspectorArrayBase::pushValue):
(Inspector::InspectorArrayBase::pushObject):
(Inspector::InspectorArrayBase::pushArray):
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
(Inspector::JSGlobalObjectConsoleClient::timeEnd):
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::JSInjectedScriptHost):
* inspector/JSInjectedScriptHost.h:
(Inspector::JSInjectedScriptHost::create):
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::activateExtraDomain):
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::addMessageToConsole):
(Inspector::InspectorConsoleAgent::addConsoleMessage):
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
(Inspector::InspectorDebuggerAgent::resolveBreakpoint):
(Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
(Inspector::InspectorDebuggerAgent::breakpointActionProbe):
(Inspector::InspectorDebuggerAgent::breakProgram):
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::didGarbageCollect):
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
(Inspector::InspectorRuntimeAgent::getBasicBlocks):
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::addEvent):
(Inspector::buildInspectorObject):
(Inspector::buildProfileInspectorObject):
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
* inspector/augmentable/AlternateDispatchableAgent.h:
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(_generate_unchecked_setter_for_member):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
* inspector/scripts/codegen/objc_generator_templates.py:
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::performSafeWrites):
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
(JSC::tryRepatchIn):
(JSC::linkPolymorphicCall):
* parser/Nodes.cpp:
(JSC::ProgramNode::setClosedVariables):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::closedVariables):
* parser/SourceProviderCache.cpp:
(JSC::SourceProviderCache::add):
* profiler/ProfileNode.h:
(JSC::CalculateProfileSubtreeDataFunctor::returnValue):
* replay/EncodedValue.cpp:
(JSC::EncodedValue::get<EncodedValue>):
* replay/scripts/CodeGeneratorReplayInputs.py:
(Generator.generate_member_move_expression):
* replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp:
(Test::HandleWheelEvent::HandleWheelEvent):
(JSC::InputTraits<Test::HandleWheelEvent>::decode):
* replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp:
(Test::MapInput::MapInput):
(JSC::InputTraits<Test::MapInput>::decode):
* runtime/ConsoleClient.cpp:
(JSC::ConsoleClient::internalMessageWithTypeAndLevel):
(JSC::ConsoleClient::logWithLevel):
(JSC::ConsoleClient::clear):
(JSC::ConsoleClient::dir):
(JSC::ConsoleClient::dirXML):
(JSC::ConsoleClient::table):
(JSC::ConsoleClient::trace):
(JSC::ConsoleClient::assertCondition):
(JSC::ConsoleClient::group):
(JSC::ConsoleClient::groupCollapsed):
(JSC::ConsoleClient::groupEnd):
* runtime/JSNativeStdFunction.cpp:
(JSC::JSNativeStdFunction::create):
* runtime/JSString.h:
(JSC::jsNontrivialString):
* runtime/JSStringJoiner.cpp:
(JSC::JSStringJoiner::join):
* runtime/JSStringJoiner.h:
(JSC::JSStringJoiner::append):
* runtime/NativeStdFunctionCell.cpp:
(JSC::NativeStdFunctionCell::create):
(JSC::NativeStdFunctionCell::NativeStdFunctionCell):
* runtime/ScopedArgumentsTable.cpp:
(JSC::ScopedArgumentsTable::setLength):
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::resize):
* runtime/TypeSet.cpp:
(JSC::StructureShape::inspectorRepresentation):
* runtime/WeakGCMap.h:
(JSC::WeakGCMap::set):
* tools/CodeProfile.h:
(JSC::CodeProfile::addChild):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::ByteCompiler::compile):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
* yarr/YarrInterpreter.h:
(JSC::Yarr::BytecodePattern::BytecodePattern):
* yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
(JSC::Yarr::YarrPatternConstructor::reset):
(JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
(JSC::Yarr::YarrPatternConstructor::atomCharacterClassEnd):
(JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin):
(JSC::Yarr::YarrPatternConstructor::atomParentheticalAssertionBegin):
(JSC::Yarr::YarrPatternConstructor::copyDisjunction):
2016-01-01 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix copyright dates. It's super annoying when we forget to update these, and I
just forgot to do so in the last commit. Also update the date of the last commit in the
ChangeLog.
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirOpcode.opcodes:
* b3/air/AirTmpWidth.cpp:
* b3/air/AirTmpWidth.h:
* ftl/FTLB3Output.cpp:
* ftl/FTLB3Output.h:
2016-01-01 Filip Pizlo <fpizlo@apple.com>
FTL B3 should be able to run all of the old V8v7 tests
https://bugs.webkit.org/show_bug.cgi?id=152579
Reviewed by Saam Barati.
Fixes some silly bugs that were preventing us from running all of the old V8v7 tests.
IRC's analysis of when to turn a Move into a Move32 when spilling is based on the premise
that if the dst has a 32-bit def width, then the src must also have a 32-bit def width. But
that doesn't happen if the src is an immediate.
This changes that condition in IRC to use the combined use/def width of both src and dst
rather than being clever. This is great because it's the combined width that determines the
size of the spill slot.
Also added some more debug support to TmpWidth.
This also fixes Air's description of DivDouble; previously it claimed to be a 32-bit
operation. Also implements Output::unsignedToDouble(), since we already had everything we
needed to implement this optimally.
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirOpcode.opcodes:
* b3/air/AirTmpWidth.cpp:
(JSC::B3::Air::TmpWidth::recompute):
(JSC::B3::Air::TmpWidth::Widths::dump):
* b3/air/AirTmpWidth.h:
(JSC::B3::Air::TmpWidth::Widths::Widths):
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::doubleToUInt):
(JSC::FTL::Output::unsignedToDouble):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::zeroExt):
(JSC::FTL::Output::zeroExtPtr):
(JSC::FTL::Output::intToDouble):
(JSC::FTL::Output::castToInt32):
(JSC::FTL::Output::unsignedToDouble): Deleted.
2016-01-01 Jeff Miller <jeffm@apple.com>
Update user-visible copyright strings to include 2016
https://bugs.webkit.org/show_bug.cgi?id=152531
Reviewed by Alexey Proskuryakov.
* Info.plist:
2015-12-31 Andy Estes <aestes@apple.com>
Fix warnings uncovered by migrating to WTF_MOVE
https://bugs.webkit.org/show_bug.cgi?id=152601
Reviewed by Daniel Bates.
* create_regex_tables: Moving a return value prevented copy elision.
* ftl/FTLUnwindInfo.cpp:
(JSC::FTL::parseUnwindInfo): Ditto.
* replay/EncodedValue.h: Ditto.
2015-12-30 Aleksandr Skachkov <gskachkov@gmail.com>
[ES6] Arrow function syntax. Arrow function specific features. Lexical bind "super"
https://bugs.webkit.org/show_bug.cgi?id=149615
Reviewed by Saam Barati.
Implemented lexical bind "super" property for arrow function. 'super' property can be accessed
inside of the arrow function in case if arrow function is nested in constructor, method,
getter or setter of class. In current patch using 'super' in arrow function, that declared out of the
class, lead to wrong type of error, should be SyntaxError(https://bugs.webkit.org/show_bug.cgi?id=150893)
and this will be fixed in separete patch.
* builtins/BuiltinExecutables.cpp:
(JSC::createExecutableInternal):
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::getSlow):
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::derivedContextType):
(JSC::ExecutableInfo::isClassContext):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::derivedContextType):
(JSC::UnlinkedCodeBlock::isClassContext):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::derivedContextType):
(JSC::BytecodeGenerator::isDerivedConstructorContext):
(JSC::BytecodeGenerator::isDerivedClassContext):
(JSC::BytecodeGenerator::isArrowFunction):
(JSC::BytecodeGenerator::makeFunction):
* bytecompiler/NodesCodegen.cpp:
(JSC::emitHomeObjectForCallee):
(JSC::FunctionCallValueNode::emitBytecode):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluate):
* interpreter/Interpreter.cpp:
(JSC::eval):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::EvalExecutable::create):
(JSC::EvalExecutable::EvalExecutable):
(JSC::ProgramExecutable::ProgramExecutable):
(JSC::ModuleProgramExecutable::ModuleProgramExecutable):
(JSC::FunctionExecutable::FunctionExecutable):
* runtime/Executable.h:
(JSC::ScriptExecutable::derivedContextType):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* tests/es6.yaml:
* tests/stress/arrowfunction-lexical-bind-superproperty.js: Added.
2015-12-29 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, relax limitation in operationCreateThis
https://bugs.webkit.org/show_bug.cgi?id=152383
Unreviewed. operationCreateThis now can be called with non constructible function.
* dfg/DFGOperations.cpp:
2015-12-29 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6][ES7] Drop Constructability of generator function
https://bugs.webkit.org/show_bug.cgi?id=152383
Reviewed by Saam Barati.
We drop the constructability of generator functions.
This functionality is already landed in ES 2016 draft[1].
And this simplifies the existing JSC's generator implementation;
dropping GeneratorThisMode flag.
[1]: https://github.com/tc39/ecma262/releases/tag/es2016-draft-20151201
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinExecutables.cpp:
(JSC::createExecutableInternal):
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::generatorThisMode): Deleted.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::generatorThisMode): Deleted.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::makeFunction):
(JSC::BytecodeGenerator::generatorThisMode): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
* interpreter/Interpreter.cpp:
(JSC::eval): Deleted.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/Executable.h:
* runtime/GeneratorThisMode.h: Removed.
* tests/stress/generator-eval-this.js:
(shouldThrow):
* tests/stress/generator-is-not-constructible.js: Added.
(shouldThrow):
(A.staticGen):
(A.prototype.gen):
(A):
(TypeError):
* tests/stress/generator-this.js:
(shouldBe.g.next):
* tests/stress/generator-with-new-target.js:
(shouldThrow):
2015-12-27 Filip Pizlo <fpizlo@apple.com>
FTL B3 should know that used registers are not the same thing as used registers. Rename the
latter to unavailable registers to avoid future confusion.
https://bugs.webkit.org/show_bug.cgi?id=152572
Reviewed by Saam Barati.
Prior to this change, we used the term "used registers" in two different senses:
- The set of registers that are live at some point in the current compilation unit. A
register is live at some point if it is read after that point on some path through that
point.
- The set of registers that are not available for scratch register use at some point. A
register may not be available if it is live or if it is a callee-save register but it is
not being saved by the current compilation.
In the old FTL LLVM code, we had some translations from the first sense into the second
sense. We forgot to do those in FTL B3, and so we get crashes, for example in V8/splay. That
benchmark highlighted this issue because it fired some lazy slow paths, and then used an
unsaved callee-save for scratch.
Curiously, we could merge these two definitions by observing that, in some sense, an unsaved
callee save is live at every point in a compilation in the sense that it may contain a value
that will be read when the compilation returns. That's pretty cool, but it feels strange to
me. This isn't how we would normally define liveness of registers. It's not how the
Air::TmpLiveness analysis would do it for any of its other clients.
So, this changes B3 to have two different concepts:
- Used registers. These are the registers that are live.
- Unavailable registers. These are the registers that are not available for scratch. It's
always a superset of used registers.
This also changes FTLLower to use unavailableRegisters() pretty much everywhere that it
previously used usedRegisters().
This makes it possible to run V8/splay.
* b3/B3StackmapGenerationParams.cpp:
(JSC::B3::StackmapGenerationParams::usedRegisters):
(JSC::B3::StackmapGenerationParams::unavailableRegisters):
(JSC::B3::StackmapGenerationParams::proc):
* b3/B3StackmapGenerationParams.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
2015-12-25 Andy Estes <aestes@apple.com>
Stop moving local objects in return statements
https://bugs.webkit.org/show_bug.cgi?id=152557
Reviewed by Brady Eidson.
Calling std::move() on a local object in a return statement prevents the compiler from applying the return value optimization.
Clang can warn about these mistakes with -Wpessimizing-move, although only when std::move() is called directly.
I found these issues by temporarily replacing WTF::move with std::move and recompiling.
* inspector/ScriptCallStack.cpp:
(Inspector::ScriptCallStack::buildInspectorArray):
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::buildInspectorObject):
* jit/CallFrameShuffler.h:
(JSC::CallFrameShuffler::snapshot):
* runtime/TypeSet.cpp:
(JSC::TypeSet::allStructureRepresentations):
(JSC::StructureShape::inspectorRepresentation):
2015-12-26 Mark Lam <mark.lam@apple.com>
Rename NodeMayOverflowInXXX to NodeMayOverflowInt32InXXX.
https://bugs.webkit.org/show_bug.cgi?id=152555
Reviewed by Alex Christensen.
That's because the NodeMayOverflowInBaseline and NodeMayOverflowInDFG flags only
indicates potential overflowing of Int32 values. We'll be adding overflow
profiling for Int52 values later, and we should disambiguate between the 2 types.
This is purely a renaming patch. There are no semantic changes.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
(JSC::DFG::ByteCodeParser::makeDivSafe):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGNodeFlags.cpp:
(JSC::DFG::dumpNodeFlags):
* dfg/DFGNodeFlags.h:
(JSC::DFG::nodeMayOverflowInt32):
(JSC::DFG::nodeCanSpeculateInt32):
(JSC::DFG::nodeMayOverflow): Deleted.
2015-12-23 Andreas Kling <akling@apple.com>
jsc CLI tool crashes on EOF.
<https://webkit.org/b/152522>
Reviewed by Benjamin Poulain.
SourceProvider should treat String() like the empty string for hashing purposes.
This was a subtle behavior change in r194017 due to how zero-length strings are
treated by StringImpl::createSubstringSharingImpl().
I made these SourceProviders store a Ref<StringImpl> internally instead of a
String, to codify the fact that these strings can't be null strings.
I couldn't find a way to cause this crash through the API.
* API/JSScriptRef.cpp:
(OpaqueJSScript::OpaqueJSScript):
* parser/SourceProvider.h:
(JSC::StringSourceProvider::StringSourceProvider):
2015-12-23 Filip Pizlo <fpizlo@apple.com>
FTL B3 should be able to run crypto-sha1 in eager mode
https://bugs.webkit.org/show_bug.cgi?id=152539
Reviewed by Saam Barati.
This patch contains one real bug fix and some other fixes that are primarily there for sanity
because I don't believe they are symptomatic.
The real fix is the instruction selector's handling of Phi. It was assuming that the correct
lowering of Phi is to do nothing and the correct lowering of Upsilon is to store into the tmp
that the Phi uses. But this fails for code patterns like:
@a = Phi()
Upsilon(@x, ^a)
use(@a) // this should see the value that @a had at the point that "@a = Phi()" executed.
This arises when we have a lot of Upsilons in a row and they are trying to perform a
shuffling. Prior to this change, "use(@a)" would see the new value of @a, i.e. @x. That's
wrong. So, this changes the lowering to make each Phi have a special shadow Tmp, and Upsilon
stores to it while Phi loads from it. Most of these assignments get copy-propagated by IRC,
so it doesn't really hurt us. I couldn't find any benchmarks that slowed down because of
this. In fact, I believe that the only time that this would lead to extra interference or
extra assignments is when it's actually needed to be correct.
This also contains other fixes, which are probably not for real bugs, but they make me feel
all warm and fuzzy:
- spillEverything() works again. Previously, it didn't have all of IRC's smarts for handling
a spill of a ZDef. I fixed this by creating a helper phase that finds all subwidth ZDefs
to spill slots and amends them with zero-fills of the top bits.
- IRC no longer requires precise TmpWidth analysis. Previously, if TmpWidth gave pessimistic
results, the subwidth ZDef bug would return. That probably means that it was never fixed
to begin with, since it's totally cool for just a single def or use of a tmp to cause it
to become pessimistic. But there may still have been some subwidth ZDefs. The way that I
fixed this bug is to have IRC also run the ZDef fixup code that spillEverything() uses.
This is abstracted behind the beautifully named Air::fixSpillSlotZDef().
- B3::validate() does dominance checks! So, if you shoot yourself in the foot by using
something before defining it, validate() will tell you.
- Air::TmpWidth is now easy to "turn off" - i.e. to make it go fully conservative. It's not
an Option; you have to hack code. But that's better than nothing, and it's consistent with
what we do for other super-internal compiler options that we use rarely.
- You can now run spillEverything() without hacking code. Just use
Options::airSpillSeverything().
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::LowerToAir):
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Validate.cpp:
* b3/air/AirCode.h:
(JSC::B3::Air::Code::specials):
(JSC::B3::Air::Code::forAllTmps):
(JSC::B3::Air::Code::isFastTmp):
* b3/air/AirFixSpillSlotZDef.h: Added.
(JSC::B3::Air::fixSpillSlotZDef):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/AirTmpWidth.cpp:
(JSC::B3::Air::TmpWidth::recompute):
* jit/JITOperations.cpp:
* runtime/Options.h:
2015-12-23 Filip Pizlo <fpizlo@apple.com>
Need a story for platform-specific Args
https://bugs.webkit.org/show_bug.cgi?id=152529
Reviewed by Michael Saboff.
This teaches Arg that some Arg forms are not valid on some targets. The instruction selector now
uses this to avoid immediates and addresses that the target wouldn't like.
This shouldn't change code generation on X86, but is meant as a step towards ARM64 support.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::crossesInterference):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::addr):
(JSC::B3::Air::LowerToAir::loadPromise):
(JSC::B3::Air::LowerToAir::imm):
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::Arg):
(JSC::B3::Air::Arg::imm):
(JSC::B3::Air::Arg::imm64):
(JSC::B3::Air::Arg::callArg):
(JSC::B3::Air::Arg::isValidScale):
(JSC::B3::Air::Arg::tmpIndex):
(JSC::B3::Air::Arg::withOffset):
(JSC::B3::Air::Arg::isValidImmForm):
(JSC::B3::Air::Arg::isValidAddrForm):
(JSC::B3::Air::Arg::isValidIndexForm):
(JSC::B3::Air::Arg::isValidForm):
(JSC::B3::Air::Arg::forEachTmpFast):
* b3/air/opcode_generator.rb:
2015-12-23 Keith Miller <keith_miller@apple.com>
[JSC] Bugfix for intrinsic getters with dictionary structures.
https://bugs.webkit.org/show_bug.cgi?id=152538
Reviewed by Mark Lam.
Intrinsic getters did not check if an object was a dictionary. This meant, if a property on
the prototype chain of a dictionary was an intrinsic getter we would IC it. Later, if a
property is added to the dictionary the IC would still return the result of the intrinsic.
The fix is to no longer IC intrinsic getters if the base object is a dictionary.
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
* tests/stress/typedarray-length-dictionary.js: Added.
(len):
2015-12-23 Andy VanWagoner <andy@instructure.com>
[INTL] Implement DateTime Format Functions
https://bugs.webkit.org/show_bug.cgi?id=147606
Reviewed by Benjamin Poulain.
Initialize a UDateFormat from the generated pattern. Use udat_format()
to format the value. Make sure that the UDateFormat is cleaned up when
the DateTimeFormat is deconstructed.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::~IntlDateTimeFormat):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::format):
* runtime/IntlDateTimeFormat.h:
2015-12-23 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement String.prototype.localeCompare in ECMA-402
https://bugs.webkit.org/show_bug.cgi?id=147607
Reviewed by Benjamin Poulain.
Add localeCompare in builtin JavaScript that delegates comparing to Intl.Collator.
Keep existing native implementation for use if INTL flag is disabled.
For the common case where no locale or options are specified, avoid creating
a new collator and just use the prototype which is initialized with the defaults.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/StringPrototype.js: Added.
(localeCompare):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
2015-12-23 Benjamin Poulain <benjamin@webkit.org>
Fix x86_64 after r194388
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::appendShift):
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::lowerX86Div):
2015-12-23 Benjamin Poulain <bpoulain@apple.com>
[JSC] Get the JavaScriptCore framework to build on ARM64 with B3 enabled
https://bugs.webkit.org/show_bug.cgi?id=152503
Reviewed by Filip Pizlo.
It is not working but it builds.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::vand):
(JSC::ARM64Assembler::vectorDataProcessing2Source):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::add32):
(JSC::MacroAssemblerARM64::add64):
(JSC::MacroAssemblerARM64::countLeadingZeros64):
(JSC::MacroAssemblerARM64::not32):
(JSC::MacroAssemblerARM64::not64):
(JSC::MacroAssemblerARM64::zeroExtend16To32):
(JSC::MacroAssemblerARM64::signExtend16To32):
(JSC::MacroAssemblerARM64::zeroExtend8To32):
(JSC::MacroAssemblerARM64::signExtend8To32):
(JSC::MacroAssemblerARM64::addFloat):
(JSC::MacroAssemblerARM64::ceilFloat):
(JSC::MacroAssemblerARM64::branchDouble):
(JSC::MacroAssemblerARM64::branchFloat):
(JSC::MacroAssemblerARM64::divFloat):
(JSC::MacroAssemblerARM64::moveZeroToDouble):
(JSC::MacroAssemblerARM64::moveFloatTo32):
(JSC::MacroAssemblerARM64::move32ToFloat):
(JSC::MacroAssemblerARM64::moveConditionallyDouble):
(JSC::MacroAssemblerARM64::moveConditionallyFloat):
(JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare):
(JSC::MacroAssemblerARM64::mulFloat):
(JSC::MacroAssemblerARM64::andDouble):
(JSC::MacroAssemblerARM64::andFloat):
(JSC::MacroAssemblerARM64::sqrtFloat):
(JSC::MacroAssemblerARM64::subFloat):
(JSC::MacroAssemblerARM64::signExtend32ToPtr):
(JSC::MacroAssemblerARM64::moveConditionally32):
(JSC::MacroAssemblerARM64::moveConditionally64):
(JSC::MacroAssemblerARM64::moveConditionallyTest32):
(JSC::MacroAssemblerARM64::moveConditionallyTest64):
(JSC::MacroAssemblerARM64::test32):
(JSC::MacroAssemblerARM64::setCarry):
(JSC::MacroAssemblerARM64::jumpAfterFloatingPointCompare):
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::moveDoubleToInts):
(JSC::MacroAssemblerX86::moveIntsToDouble):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::move32ToFloat):
(JSC::MacroAssemblerX86Common::moveFloatTo32):
(JSC::MacroAssemblerX86Common::moveInt32ToPacked): Deleted.
(JSC::MacroAssemblerX86Common::movePackedToInt32): Deleted.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::appendShift):
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::isX86DivHelperValid):
* b3/air/AirOpcode.opcodes:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitFunctionEpilogueWithEmptyFrame):
(JSC::AssemblyHelpers::emitFunctionEpilogue):
* jit/FPRInfo.h:
(JSC::FPRInfo::toArgumentRegister):
2015-12-23 Andy VanWagoner <andy@instructure.com>
[INTL] Implement Intl.DateTimeFormat.prototype.resolvedOptions ()
https://bugs.webkit.org/show_bug.cgi?id=147603
Reviewed by Benjamin Poulain.
Implements InitializeDateTimeFormat and related abstract operations
using ICU. Lazy initialization is used for DateTimeFormat.prototype.
Refactor to align with Collator work.
* icu/unicode/udatpg.h: Added.
* icu/unicode/unumsys.h: Added.
* runtime/CommonIdentifiers.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::defaultTimeZone):
(JSC::canonicalizeTimeZoneName):
(JSC::localeData):
(JSC::toDateTimeOptions):
(JSC::IntlDateTimeFormat::setFormatsFromPattern):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::weekdayString):
(JSC::IntlDateTimeFormat::eraString):
(JSC::IntlDateTimeFormat::yearString):
(JSC::IntlDateTimeFormat::monthString):
(JSC::IntlDateTimeFormat::dayString):
(JSC::IntlDateTimeFormat::hourString):
(JSC::IntlDateTimeFormat::minuteString):
(JSC::IntlDateTimeFormat::secondString):
(JSC::IntlDateTimeFormat::timeZoneNameString):
(JSC::IntlDateTimeFormat::resolvedOptions):
(JSC::IntlDateTimeFormat::format):
(JSC::IntlDateTimeFormatFuncFormatDateTime): Deleted.
* runtime/IntlDateTimeFormat.h:
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::constructIntlDateTimeFormat):
(JSC::callIntlDateTimeFormat):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatFuncFormatDateTime):
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
(JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
* runtime/IntlObject.cpp:
(JSC::resolveLocale):
(JSC::getNumberingSystemsForLocale):
* runtime/IntlObject.h:
2015-12-22 Filip Pizlo <fpizlo@apple.com>
REGRESSION(194382): FTL B3 no longer runs V8/encrypt
https://bugs.webkit.org/show_bug.cgi?id=152519
Reviewed by Saam Barati.
A "Move Imm, Tmp" instruction should turn into "Move32 Imm, Tmp" if the Tmp is spilled to a
32-bit slot. Changing where we check isTmp() achieves this. Since all of the logic is only
relevant to when we spill without introducing a Tmp, and since a Move does not have a "Move Addr,
Addr" form, this code ensures that the logic only happens for "Tmp, Tmp" and "Imm, Tmp".
* b3/air/AirIteratedRegisterCoalescing.cpp:
* dfg/DFGOperations.cpp:
2015-12-22 Filip Pizlo <fpizlo@apple.com>
FTL B3 should use the right type for comparison slow paths
https://bugs.webkit.org/show_bug.cgi?id=152521
Reviewed by Saam Barati.
Fixes a small goof that was leading to B3 validation failures.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare):
2015-12-22 Filip Pizlo <fpizlo@apple.com>
FTL B3 should be able to run richards
https://bugs.webkit.org/show_bug.cgi?id=152514
Reviewed by Michael Saboff.
This came down to a liveness bug and a register allocation bug.
The liveness bug was that the code that determined whether we should go around the fixpoint
assumed that BitVector::quickSet() would return true if the bit changed state from false to
true. That's not how it works. It returns the old value of the bit, so it will return false
if the bit changed from false to true. Since there is already a lot of code that relies on
this behavior, I fixed Liveness instead of changing BitVector.
The register allocation bug was that we weren't guarding some checks of tmp()'s with checks
that the Arg isTmp().
The liveness took a long time to track down, and I needed to add a lot of dumping to do it.
It's now possible to dump more of the liveness states, including liveAtHead. I found this
extremely helpful, so I removed the code that cleared liveAtHead.
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirLiveness.h:
(JSC::B3::Air::AbstractLiveness::AbstractLiveness):
(JSC::B3::Air::AbstractLiveness::Iterable::Iterable):
(JSC::B3::Air::AbstractLiveness::Iterable::iterator::iterator):
(JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator*):
(JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator++):
(JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator==):
(JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator!=):
(JSC::B3::Air::AbstractLiveness::Iterable::begin):
(JSC::B3::Air::AbstractLiveness::Iterable::end):
(JSC::B3::Air::AbstractLiveness::liveAtHead):
(JSC::B3::Air::AbstractLiveness::liveAtTail):
* b3/air/AirStackSlot.h:
(WTF::printInternal):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileFTLOSRExit):
2015-12-22 Saam barati <sbarati@apple.com>
Cloop build fix after https://bugs.webkit.org/show_bug.cgi?id=152511.
Unreviewed build fix.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2015-12-22 Saam barati <sbarati@apple.com>
Work around issue in bug #152510
https://bugs.webkit.org/show_bug.cgi?id=152511
Reviewed by Filip Pizlo.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2015-12-22 Filip Pizlo <fpizlo@apple.com>
FTL B3 does not logicalNot correctly
https://bugs.webkit.org/show_bug.cgi?id=152512
Reviewed by Saam Barati.
I'm working on a bug where V8/richards does not run correctly. I noticed that the codegen was
doing a log of Not32's followed by branches, which smelled like badness. To debug this, I
needed B3's origins to dump as something other than a hexed pointer to a node. The node index
would be better. So, I added the notion of an origin printer to Procedure.
The bug was easy enough to fix. This introduces Output::logicalNot(). In LLVM, it's the same
as bitNot(). In B3, it's compiled to Equal(value, 0). We could have also compiled it to
BitXor(value, 1), except that B3 will strength-reduce to that anyway whenever it's safe. It's
sort of nice that right now, you could use logicalNot() on non-bool values and get C-like
behavior.
Richards still doesn't run, though. There are more bugs!
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3BasicBlock.cpp:
(JSC::B3::BasicBlock::dump):
(JSC::B3::BasicBlock::deepDump):
* b3/B3BasicBlock.h:
(JSC::B3::BasicBlock::frequency):
(JSC::B3::DeepBasicBlockDump::DeepBasicBlockDump):
(JSC::B3::DeepBasicBlockDump::dump):
(JSC::B3::deepDump):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Origin.h:
(JSC::B3::Origin::data):
* b3/B3OriginDump.h: Added.
(JSC::B3::OriginDump::OriginDump):
(JSC::B3::OriginDump::dump):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::~Procedure):
(JSC::B3::Procedure::printOrigin):
(JSC::B3::Procedure::addBlock):
(JSC::B3::Procedure::dump):
* b3/B3Procedure.h:
(JSC::B3::Procedure::setOriginPrinter):
* b3/B3Value.cpp:
(JSC::B3::Value::dumpChildren):
(JSC::B3::Value::deepDump):
* b3/B3Value.h:
(JSC::B3::DeepValueDump::DeepValueDump):
(JSC::B3::DeepValueDump::dump):
(JSC::B3::deepDump):
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::lockedStackSlot):
(JSC::FTL::Output::bitNot):
(JSC::FTL::Output::logicalNot):
(JSC::FTL::Output::load):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::aShr):
(JSC::FTL::Output::lShr):
(JSC::FTL::Output::ctlz32):
(JSC::FTL::Output::addWithOverflow32):
(JSC::FTL::Output::lessThanOrEqual):
(JSC::FTL::Output::doubleEqual):
(JSC::FTL::Output::doubleEqualOrUnordered):
(JSC::FTL::Output::doubleNotEqualOrUnordered):
(JSC::FTL::Output::doubleLessThan):
(JSC::FTL::Output::doubleLessThanOrEqual):
(JSC::FTL::Output::doubleGreaterThan):
(JSC::FTL::Output::doubleGreaterThanOrEqual):
(JSC::FTL::Output::doubleNotEqualAndOrdered):
(JSC::FTL::Output::doubleLessThanOrUnordered):
(JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
(JSC::FTL::Output::doubleGreaterThanOrUnordered):
(JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
(JSC::FTL::Output::isZero32):
(JSC::FTL::Output::notZero32):
(JSC::FTL::Output::addIncomingToPhi):
(JSC::FTL::Output::bitCast):
(JSC::FTL::Output::bitNot): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckArray):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
(JSC::FTL::DFG::LowerDFGToLLVM::compileLogicalNot):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInstanceOfCustom):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCountExecution):
(JSC::FTL::DFG::LowerDFGToLLVM::boolify):
(JSC::FTL::DFG::LowerDFGToLLVM::isMisc):
(JSC::FTL::DFG::LowerDFGToLLVM::isNotBoolean):
(JSC::FTL::DFG::LowerDFGToLLVM::isBoolean):
(JSC::FTL::DFG::LowerDFGToLLVM::unboxBoolean):
(JSC::FTL::DFG::LowerDFGToLLVM::isNotType):
(JSC::FTL::DFG::LowerDFGToLLVM::speculateObject):
* ftl/FTLOutput.h:
(JSC::FTL::Output::aShr):
(JSC::FTL::Output::lShr):
(JSC::FTL::Output::bitNot):
(JSC::FTL::Output::logicalNot):
(JSC::FTL::Output::insertElement):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
2015-12-22 Keith Miller <keith_miller@apple.com>
Remove OverridesHasInstance from TypeInfoFlags
https://bugs.webkit.org/show_bug.cgi?id=152005
Reviewed by Saam Barati.
Currently, we have three TypeInfo flags associated with instanceof behavior,
ImplementsHasInstance, ImplementDefaultHasInstance, and OverridesHasInstance. This patch
removes the third and moves the first to the out of line flags. In theory, we should only
need one flag but removing ImplementsHasInstance is more involved and should be done in a
separate patch.
* API/JSCallbackConstructor.h:
* API/JSCallbackObject.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_overrides_has_instance):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_overrides_has_instance):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/InternalFunction.h:
* runtime/JSBoundFunction.h:
* runtime/JSCallee.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::implementsHasInstance):
(JSC::TypeInfo::TypeInfo): Deleted.
(JSC::TypeInfo::overridesHasInstance): Deleted.
* runtime/NumberConstructor.h:
2015-12-22 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do tail calls
https://bugs.webkit.org/show_bug.cgi?id=152494
Reviewed by Michael Saboff.
OMG this was so easy.
The only shady part is that I broke a layering rule that we had so far been following: B3 was
sitting below the JSC runtime, and did not use JS-specific types. No more, since B3::ValueRep
can now turn itself into a ValueRecovery for a JSValue. This small feature makes a huge
difference for the readability of tail call code: it makes it plain that the call frame
shuffler is basically just directly consuming the stackmap generation params, and insofar as
there is any data transformation, it's just because it uses different classes to say the same
thing.
I think we should avoid adding too many JS-specific things to B3. But, so long as it's still
possible to use B3 to compile things that aren't JS, I think we'll be fine.
* b3/B3ValueRep.cpp:
(JSC::B3::ValueRep::dump):
(JSC::B3::ValueRep::emitRestore):
(JSC::B3::ValueRep::recoveryForJSValue):
* b3/B3ValueRep.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
* test/stress/ftl-tail-call.js: Added.
2015-12-21 Mark Lam <mark.lam@apple.com>
Snippefy op_negate for the baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=152447
Reviewed by Benjamin Poulain.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_op_negate):
(JSC::JIT::emitSlow_op_negate):
(JSC::JIT::emitBitBinaryOpFastPath):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_op_negate): Deleted.
(JSC::JIT::emitSlow_op_negate): Deleted.
* jit/JITNegGenerator.cpp: Added.
(JSC::JITNegGenerator::generateFastPath):
* jit/JITNegGenerator.h: Added.
(JSC::JITNegGenerator::JITNegGenerator):
(JSC::JITNegGenerator::didEmitFastPath):
(JSC::JITNegGenerator::endJumpList):
(JSC::JITNegGenerator::slowPathJumpList):
2015-12-21 Filip Pizlo <fpizlo@apple.com>
Address review feedback from Saam. I should have landed it in r194354.
* b3/testb3.cpp:
(JSC::B3::testStore16Arg):
2015-12-21 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile Store16
https://bugs.webkit.org/show_bug.cgi?id=152493
Reviewed by Saam Barati.
This adds comprehensive Store16 support to our assembler, Air, and B3->Air lowering.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::store16):
* assembler/X86Assembler.h:
(JSC::X86Assembler::movb_rm):
(JSC::X86Assembler::movw_rm):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testStorePartial8BitRegisterOnX86):
(JSC::B3::testStore16Arg):
(JSC::B3::testStore16Imm):
(JSC::B3::testTrunc):
(JSC::B3::run):
2015-12-21 Filip Pizlo <fpizlo@apple.com>
Unreviewed, remove highBitsAreZero(), it's unused.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::shouldCopyPropagate):
(JSC::B3::Air::LowerToAir::highBitsAreZero): Deleted.
2015-12-21 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed, fix the !FTL_USES_B3 build after r194334.
* ftl/FTLLowerDFGToLLVM.cpp: Mark forwarding unused variable.
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
2015-12-21 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do doubleToInt32
https://bugs.webkit.org/show_bug.cgi?id=152484
Reviewed by Saam Barati.
We used to have a DToI32 opcode in B3 that we never implemented. This removes that opcode,
since double-to-int conversion has dramatically different semantics on different
architectures. We let FTL get the conversion instruction it wants by using a patchpoint.
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::materialize):
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::Output):
(JSC::FTL::Output::appendTo):
(JSC::FTL::Output::lockedStackSlot):
(JSC::FTL::Output::load):
(JSC::FTL::Output::doublePowi):
(JSC::FTL::Output::hasSensibleDoubleToInt):
(JSC::FTL::Output::doubleToInt):
(JSC::FTL::Output::doubleToUInt):
(JSC::FTL::Output::load8SignExt32):
(JSC::FTL::Output::load8ZeroExt32):
(JSC::FTL::Output::load16SignExt32):
(JSC::FTL::Output::load16ZeroExt32):
(JSC::FTL::Output::store):
(JSC::FTL::Output::store32As8):
(JSC::FTL::Output::store32As16):
(JSC::FTL::Output::branch):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doubleLog):
(JSC::FTL::Output::signExt32To64):
(JSC::FTL::Output::zeroExt):
(JSC::FTL::Output::zeroExtPtr):
(JSC::FTL::Output::intToDouble):
(JSC::FTL::Output::unsignedToDouble):
(JSC::FTL::Output::castToInt32):
(JSC::FTL::Output::hasSensibleDoubleToInt): Deleted.
(JSC::FTL::Output::sensibleDoubleToInt): Deleted.
(JSC::FTL::Output::fpToInt32): Deleted.
(JSC::FTL::Output::fpToUInt32): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithPow):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutByVal):
(JSC::FTL::DFG::LowerDFGToLLVM::compileSwitch):
(JSC::FTL::DFG::LowerDFGToLLVM::doubleToInt32):
(JSC::FTL::DFG::LowerDFGToLLVM::sensibleDoubleToInt32):
(JSC::FTL::DFG::LowerDFGToLLVM::convertDoubleToInt32):
* ftl/FTLOutput.h:
(JSC::FTL::Output::hasSensibleDoubleToInt):
(JSC::FTL::Output::doubleToInt):
(JSC::FTL::Output::doubleToUInt):
(JSC::FTL::Output::signExt32To64):
(JSC::FTL::Output::zeroExt):
2015-12-21 Skachkov Oleksandr <gskachkov@gmail.com>
Unexpected exception assigning to this._property inside arrow function
https://bugs.webkit.org/show_bug.cgi?id=152028
Reviewed by Saam Barati.
The issue appeared in case if in arrow function created base-level lexical envioronment, and in this case
|this| value was loaded from wrong scope. The problem was that loading of the |this| happened too early when
compiling bytecode because the bytecode generators's scope stack wasn't in sync with runtime scope stack.
To fix issue loading of |this| was moved after initializeDefaultParameterValuesAndSetupFunctionScopeStack
in BytecodeGenerator.cpp
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* tests/stress/arrowfunction-lexical-bind-this-2.js:
2015-12-21 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do vararg calls
https://bugs.webkit.org/show_bug.cgi?id=152468
Reviewed by Benjamin Poulain.
This adds FTL->B3 lowering of all kinds of varargs calls - forwarding or not, tail or not,
and construct or not. Like all other such lowerings, all of the code is in one place in
FTLLower.
I removed code for varargs and exception spill slots from the B3 path, since it won't need
it. The plan is to rely on B3 doing the spilling for us by using some combination of early
clobber and late use.
This adds ValueRep::emitRestore(), a helpful method for emitting code to restore any ValueRep
into any 64-bit Reg (FPR or GPR).
I wrote new tests for vararg calls, because I wasn't sure which of the existing ones we can
run. These are short-running tests, so I'm not worried about bloating our test suite.
* b3/B3ValueRep.cpp:
(JSC::B3::ValueRep::dump):
(JSC::B3::ValueRep::emitRestore):
* b3/B3ValueRep.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
* ftl/FTLState.h:
* tests/stress/varargs-no-forward.js: Added.
* tests/stress/varargs-simple.js: Added.
* tests/stress/varargs-two-level.js: Added.
2015-12-18 Mark Lam <mark.lam@apple.com>
Add unary operator tests to compare JIT and LLINT results.
https://bugs.webkit.org/show_bug.cgi?id=152453
Reviewed by Benjamin Poulain.
Also fixed a few things in the binary-op-test.js.
* tests/stress/op_negate.js: Added.
(o1.valueOf):
* tests/stress/op_postdec.js: Added.
(o1.valueOf):
* tests/stress/op_postinc.js: Added.
(o1.valueOf):
* tests/stress/op_predec.js: Added.
(o1.valueOf):
* tests/stress/op_preinc.js: Added.
(o1.valueOf):
* tests/stress/resources/binary-op-test.js:
(stringifyIfNeeded):
(isIdentical):
(run):
* tests/stress/resources/unary-op-test.js: Added.
(stringifyIfNeeded):
(generateBinaryTests):
(isIdentical):
(runTest):
(run):
2015-12-21 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r194328.
This change appears to have caused failures in JSC tests
Reverted changeset:
"[INTL] Implement String.prototype.localeCompare in ECMA-402"
https://bugs.webkit.org/show_bug.cgi?id=147607
http://trac.webkit.org/changeset/194328
2015-12-21 Filip Pizlo <fpizlo@apple.com>
B3->Air lowering incorrectly copy-propagates over ZExt32's
https://bugs.webkit.org/show_bug.cgi?id=152365
Reviewed by Benjamin Poulain.
The instruction selector thinks that Value's that return Int32's are going to always be lowered
to instructions that zero-extend the destination. But this isn't actually true. If you have an
Add32 with a destination on the stack (i.e. spilled) then it only writes 4 bytes. Then, the
filler will load 8 bytes from the stack at the point of use. So, the use of the Add32 will see
garbage in the high bits.
The fact that the spiller chose to use 8 bytes for a Tmp that gets defined by an Add32 is a
pretty sad bug, but:
- It's entirely up to the spiller to decide how many bytes to use for a Tmp, since we do not
ascribe a type to Tmps. We could ascribe types to Tmps, but then coalescing would become
harder. Our goal is to fix the bug while still enabling coalescing in cases like "a[i]" where
"i" is a 32-bit integer that is computed using operations that already do zero-extension.
- More broadly, it's strange that the instruction selector decides whether a Value will be
lowered to something that zero-extends. That's too constraining, since the most optimal
instruction selection might involve something that doesn't zero-extend in cases of spilling, so
the zero-extension should only happen if it's actually needed. This means that we need to
understand which Air instructions cause zero-extensions.
- If we know which Air instructions cause zero-extensions, then we don't need the instruction
selector to copy-propagate ZExt32's. We have copy-propagation in Air thanks to the register
allocator.
In fact, the register allocator is exactly where all of the pieces come together. It's there that
we want to know which operations zero-extend and which don't. It also wants to know how many bits
of a Tmp each instruction reads. Armed with that information, the register allocator can emit
more optimal spill code, use less stack space for spill slots, and coalesce Move32's. As a bonus,
on X86, it replaces Move's with Move32's whenever it can. On X86, Move32 is cheaper.
This fixes a crash bug in V8/encrypt. After fixing this, I only needed two minor fixes to get
V8/encrypt to run. We're about 10% behind LLVM on steady state throughput on this test. It
appears to be mostly due to excessive spilling caused by CCall slow paths. That's fixable: we
could make CCalls on slow paths use a variant of CCallSpecial that promises not to clobber any
registers, and then have it emit spill code around the call itself. LLVM probably gets this
optimization from its live range splitting.
I tried writing a regression test. The problem is that you need garbage on the stack for this to
work, and I didn't feel like writing a flaky test. It appears that running V8/encrypt will cover
this, so we do have coverage.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::isX86):
(JSC::isX86_64):
(JSC::optimizeForARMv7IDIVSupported):
(JSC::optimizeForX86):
(JSC::optimizeForX86_64):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::highBitsAreZero):
(JSC::B3::Air::LowerToAir::shouldCopyPropagate):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::forEachArg):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
* b3/B3Value.h:
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirArg.cpp:
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::pointerWidth):
(JSC::B3::Air::Arg::isAnyUse):
(JSC::B3::Air::Arg::isColdUse):
(JSC::B3::Air::Arg::isEarlyUse):
(JSC::B3::Air::Arg::isDef):
(JSC::B3::Air::Arg::isZDef):
(JSC::B3::Air::Arg::widthForB3Type):
(JSC::B3::Air::Arg::conservativeWidth):
(JSC::B3::Air::Arg::minimumWidth):
(JSC::B3::Air::Arg::bytes):
(JSC::B3::Air::Arg::widthForBytes):
(JSC::B3::Air::Arg::Arg):
(JSC::B3::Air::Arg::forEachTmp):
* b3/air/AirCCallSpecial.cpp:
(JSC::B3::Air::CCallSpecial::forEachArg):
* b3/air/AirEliminateDeadCode.cpp:
(JSC::B3::Air::eliminateDeadCode):
* b3/air/AirFixPartialRegisterStalls.cpp:
(JSC::B3::Air::fixPartialRegisterStalls):
* b3/air/AirInst.cpp:
(JSC::B3::Air::Inst::hasArgEffects):
* b3/air/AirInst.h:
(JSC::B3::Air::Inst::forEachTmpFast):
(JSC::B3::Air::Inst::forEachTmp):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::forEachTmpWithExtraClobberedRegs):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirLiveness.h:
(JSC::B3::Air::AbstractLiveness::AbstractLiveness):
(JSC::B3::Air::AbstractLiveness::LocalCalc::execute):
* b3/air/AirOpcode.opcodes:
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/AirTmpWidth.cpp: Added.
(JSC::B3::Air::TmpWidth::TmpWidth):
(JSC::B3::Air::TmpWidth::~TmpWidth):
* b3/air/AirTmpWidth.h: Added.
(JSC::B3::Air::TmpWidth::width):
(JSC::B3::Air::TmpWidth::defWidth):
(JSC::B3::Air::TmpWidth::useWidth):
(JSC::B3::Air::TmpWidth::Widths::Widths):
* b3/air/AirUseCounts.h:
(JSC::B3::Air::UseCounts::UseCounts):
* b3/air/opcode_generator.rb:
* b3/testb3.cpp:
(JSC::B3::testCheckMegaCombo):
(JSC::B3::testCheckTrickyMegaCombo):
(JSC::B3::testCheckTwoMegaCombos):
(JSC::B3::run):
2015-12-21 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement String.prototype.localeCompare in ECMA-402
https://bugs.webkit.org/show_bug.cgi?id=147607
Reviewed by Darin Adler.
Add localeCompare in builtin JavaScript that delegates comparing to Intl.Collator.
Keep existing native implementation for use if INTL flag is disabled.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/StringPrototype.js: Added.
(localeCompare):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
2015-12-18 Filip Pizlo <fpizlo@apple.com>
Implement compareDouble in B3/Air
https://bugs.webkit.org/show_bug.cgi?id=150903
Reviewed by Benjamin Poulain.
A hole in our coverage is that we don't fuse a double comparison into a branch, then we will
crash in the instruction selector. Obviously, we *really* want to fuse double comparisons,
but we can't guarantee that this will always happen.
This also removes all uses of WTF::Dominators verification, since it's extremely slow even in
a release build. This speeds up testb3 with validateGraphAtEachPhase=true by an order of
magnitude.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::moveDoubleConditionallyFloat):
(JSC::MacroAssembler::compareDouble):
(JSC::MacroAssembler::compareFloat):
(JSC::MacroAssembler::lea):
* b3/B3Dominators.h:
(JSC::B3::Dominators::Dominators):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createCompare):
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testCompare):
(JSC::B3::testEqualDouble):
(JSC::B3::simpleFunction):
(JSC::B3::run):
* dfg/DFGDominators.h:
(JSC::DFG::Dominators::Dominators):
2015-12-19 Dan Bernstein <mitz@apple.com>
[Mac] WebKit contains dead source code for OS X Mavericks and earlier
https://bugs.webkit.org/show_bug.cgi?id=152462
Reviewed by Alexey Proskuryakov.
- Removed build setting definitions for OS X 10.9 and earlier, and simplified defintions
that became uniform across all OS X versions as a result:
* Configurations/DebugRelease.xcconfig:
* Configurations/FeatureDefines.xcconfig:
* Configurations/Version.xcconfig:
* API/JSBase.h: Removed check against __MAC_OS_X_VERSION_MIN_REQUIRED that was always true.
2015-12-19 Benjamin Poulain <bpoulain@apple.com>
[JSC] Streamline Tmp indexing inside the register allocator
https://bugs.webkit.org/show_bug.cgi?id=152420
Reviewed by Filip Pizlo.
AirIteratedRegisterCoalescing has been accumulating a bit of mess over time.
When it started, every map addressed by Tmp was using Tmp hashing.
That caused massive performance problems. Everything perf sensitive was moved
to direct array addressing by the absolute Tmp index. This left the code
with half of the function using Tmp, the other half using indices.
With this patch, almost everything is moved to absolute indexing.
There are a few advantages to this:
-No more conversion churn for Floating Point registers.
-Most of the functions can now be shared between GP and FP.
-A bit of clean up since the core algorithm only deals with integers now.
This patch also changes the index type to be a template argument.
That will allow future specialization of "m_interferenceEdges" based
on the expected problem size.
Finally, the code related to the program modification (register assignment
and spilling) was moved to the wrapper "IteratedRegisterCoalescing".
The current split is:
-AbstractColoringAllocator: common core. Share as much as possible between
GP and FP.
-ColoringAllocator: the remaining parts of the algorithm, everything that
is specific to GP, FP.
-IteratedRegisterCoalescing: the "iterated" part of the algorithm.
Try to allocate and modify the code as needed.
The long term plan is:
-Move selectSpill() and the coloring loop to AbstractColoringAllocator.
-Specialize m_interferenceEdges to make it faster.
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirTmpInlines.h:
(JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::lastMachineRegisterIndex):
(JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::lastMachineRegisterIndex):
2015-12-19 Benjamin Poulain <bpoulain@apple.com>
[JSC] FTLB3Output generates some invalid ZExt32
https://bugs.webkit.org/show_bug.cgi?id=151905
Reviewed by Filip Pizlo.
FTLLowerDFGToLLVM calls zeroExt() to int32 in some cases.
We were generating ZExt32 with Int32 as return type :(
* ftl/FTLB3Output.h:
(JSC::FTL::Output::zeroExt):
2015-12-19 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add EqualOrUnordered to B3
https://bugs.webkit.org/show_bug.cgi?id=152425
Reviewed by Mark Lam.
Add EqualOrUnordered to B3 and use it to implements
FTL::Output's NotEqualAndOrdered.
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::equalOrUnordered):
* b3/B3ConstDoubleValue.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createGenericCompare):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3ReduceDoubleToFloat.cpp:
(JSC::B3::reduceDoubleToFloat):
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::equalOrUnordered):
(JSC::B3::Value::returnsBool):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/testb3.cpp:
(JSC::B3::testBranchEqualOrUnorderedArgs):
(JSC::B3::testBranchNotEqualAndOrderedArgs):
(JSC::B3::testBranchEqualOrUnorderedDoubleArgImm):
(JSC::B3::testBranchEqualOrUnorderedFloatArgImm):
(JSC::B3::testBranchEqualOrUnorderedDoubleImms):
(JSC::B3::testBranchEqualOrUnorderedFloatImms):
(JSC::B3::testBranchEqualOrUnorderedFloatWithUselessDoubleConversion):
(JSC::B3::run):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doubleNotEqualAndOrdered):
(JSC::FTL::Output::doubleNotEqual): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::boolify):
* ftl/FTLOutput.h:
(JSC::FTL::Output::doubleNotEqualAndOrdered):
(JSC::FTL::Output::doubleNotEqual): Deleted.
2015-12-19 Benjamin Poulain <bpoulain@apple.com>
[JSC] B3: Add indexed addressing when lowering BitwiseCast
https://bugs.webkit.org/show_bug.cgi?id=152432
Reviewed by Geoffrey Garen.
The MacroAssembler supports it, we should use it.
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testBitwiseCastOnDoubleInMemoryIndexed):
(JSC::B3::testBitwiseCastOnInt64InMemoryIndexed):
2015-12-18 Andreas Kling <akling@apple.com>
Make JSString::SafeView less of a footgun.
<https://webkit.org/b/152376>
Reviewed by Darin Adler.
Remove the "operator StringView()" convenience helper on JSString::SafeString since that
made it possible to casually turn the return value from JSString::view() into an unsafe
StringView local on the stack with this pattern:
StringView view = someJSValue.toString(exec)->view(exec);
The JSString* returned by toString() above will go out of scope by the end of the statement
and does not stick around to protect itself from garbage collection.
It will now look like this instead:
JSString::SafeView view = someJSValue.toString(exec)->view(exec);
To be extra clear, the following is not safe:
StringView view = someJSValue.toString(exec)->view(exec).get();
By the end of that statement, the JSString::SafeView goes out of scope, and the JSString*
is no longer protected from GC.
I added a couple of forwarding helpers to the SafeView class, and if you need a StringView
object from it, you can call .get() just like before.
Finally I also removed the JSString::SafeView() constructor, since nobody was instantiating
empty SafeView objects anyway. This way we don't have to worry about null members.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncJoin):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncJoin):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::decode):
(JSC::globalFuncParseInt):
(JSC::globalFuncParseFloat):
(JSC::globalFuncEscape):
(JSC::globalFuncUnescape):
* runtime/JSONObject.cpp:
(JSC::JSONProtoFuncParse):
* runtime/JSString.cpp:
(JSC::JSString::getPrimitiveNumber):
(JSC::JSString::toNumber):
* runtime/JSString.h:
(JSC::JSString::SafeView::is8Bit):
(JSC::JSString::SafeView::length):
(JSC::JSString::SafeView::characters8):
(JSC::JSString::SafeView::characters16):
(JSC::JSString::SafeView::operator[]):
(JSC::JSString::SafeView::SafeView):
(JSC::JSString::SafeView::get):
(JSC::JSString::SafeView::operator StringView): Deleted.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncCharAt):
(JSC::stringProtoFuncCharCodeAt):
(JSC::stringProtoFuncIndexOf):
(JSC::stringProtoFuncNormalize):
2015-12-18 Saam barati <sbarati@apple.com>
BytecodeGenerator::pushLexicalScopeInternal and pushLexicalScope should use enums instead of bools
https://bugs.webkit.org/show_bug.cgi?id=152450
Reviewed by Geoffrey Garen and Joseph Pecoraro.
This makes comprehending the call sites of these functions
easier without looking up the header of the function.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
(JSC::BytecodeGenerator::emitPushCatchScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::lastOpcodeID):
* bytecompiler/NodesCodegen.cpp:
(JSC::BlockNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitMultiLoopBytecode):
(JSC::ForOfNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
2015-12-18 Michael Catanzaro <mcatanzaro@igalia.com>
Avoid triggering clang's -Wundefined-bool-conversion
https://bugs.webkit.org/show_bug.cgi?id=152408
Reviewed by Mark Lam.
Add ASSERT_THIS_GC_OBJECT_LOOKS_VALID and ASSERT_THIS_GC_OBJECT_INHERITS to avoid use of
ASSERT(this) by ASSERT_GC_OBJECT_LOOKS_VALID and ASSERT_GC_OBJECT_INHERITS.
* heap/GCAssertions.h:
2015-12-18 Mark Lam <mark.lam@apple.com>
Replace SpecialFastCase profiles with ResultProfiles.
https://bugs.webkit.org/show_bug.cgi?id=152433
Reviewed by Saam Barati.
This is in preparation for upcoming work to enhance the DFG predictions to deal
with untyped operands.
This patch also enhances some of the arithmetic slow paths (for the LLINT and
baseline JIT) to collect result profiling info. This profiling info is not put
to use yet.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpRareCaseProfile):
(JSC::CodeBlock::dumpResultProfile):
(JSC::CodeBlock::printLocationAndOp):
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::shrinkToFit):
(JSC::CodeBlock::dumpValueProfiles):
(JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
(JSC::CodeBlock::resultProfileForBytecodeOffset):
(JSC::CodeBlock::updateResultProfileForBytecodeOffset):
(JSC::CodeBlock::capabilityLevel):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::couldTakeSlowCase):
(JSC::CodeBlock::addResultProfile):
(JSC::CodeBlock::numberOfResultProfiles):
(JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
(JSC::CodeBlock::couldTakeSpecialFastCase):
(JSC::CodeBlock::addSpecialFastCaseProfile): Deleted.
(JSC::CodeBlock::numberOfSpecialFastCaseProfiles): Deleted.
(JSC::CodeBlock::specialFastCaseProfile): Deleted.
(JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset): Deleted.
* bytecode/ValueProfile.cpp: Added.
(WTF::printInternal):
* bytecode/ValueProfile.h:
(JSC::getRareCaseProfileBytecodeOffset):
(JSC::ResultProfile::ResultProfile):
(JSC::ResultProfile::bytecodeOffset):
(JSC::ResultProfile::specialFastPathCount):
(JSC::ResultProfile::didObserveNonInt32):
(JSC::ResultProfile::didObserveDouble):
(JSC::ResultProfile::didObserveNonNegZeroDouble):
(JSC::ResultProfile::didObserveNegZeroDouble):
(JSC::ResultProfile::didObserveNonNumber):
(JSC::ResultProfile::didObserveInt32Overflow):
(JSC::ResultProfile::setObservedNonNegZeroDouble):
(JSC::ResultProfile::setObservedNegZeroDouble):
(JSC::ResultProfile::setObservedNonNumber):
(JSC::ResultProfile::setObservedInt32Overflow):
(JSC::ResultProfile::addressOfFlags):
(JSC::ResultProfile::addressOfSpecialFastPathCount):
(JSC::ResultProfile::hasBits):
(JSC::ResultProfile::setBit):
(JSC::getResultProfileBytecodeOffset):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_div):
(JSC::JIT::emit_op_mul):
* jit/JITDivGenerator.cpp:
(JSC::JITDivGenerator::generateFastPath):
* jit/JITDivGenerator.h:
(JSC::JITDivGenerator::JITDivGenerator):
* jit/JITMulGenerator.cpp:
(JSC::JITMulGenerator::generateFastPath):
* jit/JITMulGenerator.h:
(JSC::JITMulGenerator::JITMulGenerator):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2015-12-18 Keith Miller <keith_miller@apple.com>
verboseDFGByteCodeParsing option should show the bytecode it is parsing.
https://bugs.webkit.org/show_bug.cgi?id=152434
Reviewed by Michael Saboff.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2015-12-18 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Add the missing setupArgumentsWithExecState functions after r193974
https://bugs.webkit.org/show_bug.cgi?id=152214
Reviewed by Mark Lam.
Relanding r194007 after r194248.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
2015-12-17 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove "local" scope type from the protocol
https://bugs.webkit.org/show_bug.cgi?id=152409
Reviewed by Timothy Hatcher.
After r194251 the backend no longer sends this scope type.
So remove it from the protocol.
The concept of a Local Scope should be calculatable by the
frontend. In fact the way the backend used to do this could
easily be done by the frontend. To be done in a follow-up.
* inspector/InjectedScriptSource.js:
* inspector/JSJavaScriptCallFrame.h:
* inspector/protocol/Debugger.json:
2015-12-17 Sukolsak Sakshuwong <sukolsak@gmail.com>
[INTL] Implement Collator Compare Functions
https://bugs.webkit.org/show_bug.cgi?id=147604
Reviewed by Darin Adler.
This patch implements Intl.Collator.prototype.compare() according
to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.)
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::~IntlCollator):
(JSC::sortLocaleData):
(JSC::searchLocaleData):
(JSC::IntlCollator::initializeCollator):
(JSC::IntlCollator::createCollator):
(JSC::IntlCollator::compareStrings):
(JSC::IntlCollator::usageString):
(JSC::IntlCollator::sensitivityString):
(JSC::IntlCollator::resolvedOptions):
(JSC::IntlCollator::setBoundCompare):
(JSC::IntlCollatorFuncCompare): Deleted.
* runtime/IntlCollator.h:
(JSC::IntlCollator::usage): Deleted.
(JSC::IntlCollator::setUsage): Deleted.
(JSC::IntlCollator::locale): Deleted.
(JSC::IntlCollator::setLocale): Deleted.
(JSC::IntlCollator::collation): Deleted.
(JSC::IntlCollator::setCollation): Deleted.
(JSC::IntlCollator::numeric): Deleted.
(JSC::IntlCollator::setNumeric): Deleted.
(JSC::IntlCollator::sensitivity): Deleted.
(JSC::IntlCollator::setSensitivity): Deleted.
(JSC::IntlCollator::ignorePunctuation): Deleted.
(JSC::IntlCollator::setIgnorePunctuation): Deleted.
* runtime/IntlCollatorConstructor.cpp:
(JSC::constructIntlCollator):
(JSC::callIntlCollator):
(JSC::sortLocaleData): Deleted.
(JSC::searchLocaleData): Deleted.
(JSC::initializeCollator): Deleted.
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorFuncCompare):
(JSC::IntlCollatorPrototypeFuncResolvedOptions):
* runtime/IntlObject.cpp:
(JSC::defaultLocale):
(JSC::convertICULocaleToBCP47LanguageTag):
(JSC::intlStringOption):
(JSC::resolveLocale):
(JSC::supportedLocales):
* runtime/IntlObject.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::intlCollatorAvailableLocales):
(JSC::JSGlobalObject::intlDateTimeFormatAvailableLocales):
(JSC::JSGlobalObject::intlNumberFormatAvailableLocales):
2015-12-17 Joseph Pecoraro <pecoraro@apple.com>
Provide a way to distinguish a nested lexical block from a function's lexical block
https://bugs.webkit.org/show_bug.cgi?id=152361
Reviewed by Saam Barati.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
(JSC::BytecodeGenerator::emitPushCatchScope):
Each of these are specialized scopes. They are not nested lexical scopes.
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
Include an extra parameter to mark the SymbolTable as a nested lexical or not.
* bytecompiler/NodesCodegen.cpp:
(JSC::BlockNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitMultiLoopBytecode):
(JSC::ForOfNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
Each of these are cases of non-function nested lexical scopes.
So mark the SymbolTable as nested.
* inspector/protocol/Debugger.json:
* inspector/InjectedScriptSource.js:
Include a new scope type.
* inspector/JSJavaScriptCallFrame.h:
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::scopeType):
Use the new "NestedLexical" scope type for nested, non-function,
lexical scopes. The Inspector can use this to better describe
this scope in the frontend.
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::isNestedLexicalScope):
* debugger/DebuggerScope.h:
* runtime/JSScope.cpp:
(JSC::JSScope::isNestedLexicalScope):
* runtime/JSScope.h:
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::SymbolTable):
(JSC::SymbolTable::cloneScopePart):
* runtime/SymbolTable.h:
Access the isNestedLexicalScope bit.
2015-12-17 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed EFL Build Fix after r194247.
* interpreter/CallFrame.cpp:
(JSC::CallFrame::friendlyFunctionName):
Handle compilers that don't realize the switch handles all cases.
2015-12-17 Keith Miller <keith_miller@apple.com>
[ES6] Add support for Symbol.hasInstance
https://bugs.webkit.org/show_bug.cgi?id=151839
Reviewed by Saam Barati.
Fixed version of r193986, r193983, and r193974.
This patch adds support for Symbol.hasInstance, unfortunately in order to prevent
regressions several new bytecodes and DFG IR nodes were necessary. Before, Symbol.hasInstance
when executing an instanceof expression we would emit three bytecodes: overrides_has_instance, get_by_id,
then instanceof. As the spec has changed, we emit a more complicated set of bytecodes in addition to some
new ones. First the role of overrides_has_instance and its corresponding DFG node have changed. Now it returns
a js-boolean indicating whether the RHS of the instanceof expression (from here on called the constructor for simplicity)
needs non-default behavior for resolving the expression. i.e. The constructor has a Symbol.hasInstance that differs from the one on
Function.prototype[Symbol.hasInstance] or is a bound/C-API function. Once we get to the DFG this node is generally eliminated as
we can prove the value of Symbol.hasInstance is a constant. The second new bytecode is instanceof_custom. insntanceof_custom, just
emits a call to slow path code that computes the result.
In the DFG, there is also a new node, CheckTypeInfoFlags, which checks the type info flags are consistent with the ones provided and
OSR exits if the flags are not. Additionally, we attempt to prove that the result of CheckHasValue will be a constant and transform
it into a CheckTypeInfoFlags followed by a JSConstant.
* API/JSCallbackObject.h:
* builtins/FunctionPrototype.js:
(symbolHasInstance):
* bytecode/BytecodeBasicBlock.cpp:
(JSC::isBranch): Deleted.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* bytecode/PreciseJumpTargets.cpp:
(JSC::getJumpTargetsForBytecodeOffset): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitOverridesHasInstance):
(JSC::BytecodeGenerator::emitInstanceOfCustom):
(JSC::BytecodeGenerator::emitCheckHasInstance): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::InstanceOfNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCellOperand):
(JSC::DFG::Node::hasTypeInfoOperand):
(JSC::DFG::Node::typeInfoOperand):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags):
(JSC::DFG::SpeculativeJIT::compileInstanceOfCustom):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileOverridesHasInstance):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckTypeInfoFlags):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInstanceOfCustom):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckHasInstance): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emit_op_instanceof_custom):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_check_has_instance): Deleted.
(JSC::JIT::emitSlow_op_check_has_instance): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emit_op_instanceof_custom):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_check_has_instance): Deleted.
(JSC::JIT::emitSlow_op_check_has_instance): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonIdentifiers.h:
* runtime/ExceptionHelpers.cpp:
(JSC::invalidParameterInstanceofSourceAppender):
(JSC::invalidParameterInstanceofNotFunctionSourceAppender):
(JSC::invalidParameterInstanceofhasInstanceValueNotFunctionSourceAppender):
(JSC::createInvalidInstanceofParameterErrorNotFunction):
(JSC::createInvalidInstanceofParameterErrorhasInstanceValueNotFunction):
(JSC::createInvalidInstanceofParameterError): Deleted.
* runtime/ExceptionHelpers.h:
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::addFunctionProperties):
* runtime/FunctionPrototype.h:
* runtime/JSBoundFunction.cpp:
(JSC::isBoundFunction):
(JSC::hasInstanceBoundFunction):
* runtime/JSBoundFunction.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
* runtime/JSObject.cpp:
(JSC::JSObject::hasInstance):
(JSC::objectPrivateFuncInstanceOf):
* runtime/JSObject.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::TypeInfo):
(JSC::TypeInfo::overridesHasInstance):
* runtime/WriteBarrier.h:
(JSC::WriteBarrierBase<Unknown>::slot):
* tests/es6.yaml:
* tests/stress/instanceof-custom-hasinstancesymbol.js: Added.
(Constructor):
(value):
(instanceOf):
(body):
* tests/stress/symbol-hasInstance.js: Added.
(Constructor):
(value):
(ObjectClass.Symbol.hasInstance):
(NumberClass.Symbol.hasInstance):
2015-12-17 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Improve names in Debugger Call Stack section when paused
https://bugs.webkit.org/show_bug.cgi?id=152398
Reviewed by Brian Burg.
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::functionName):
Provide a better name from the underlying CallFrame.
* inspector/InjectedScriptSource.js:
(InjectedScript.CallFrameProxy):
Just call functionName, it will provide a better
than nothing function name.
* runtime/JSFunction.cpp:
(JSC::getCalculatedDisplayName):
Use emptyString().
* interpreter/CallFrame.h:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::friendlyFunctionName):
This is the third similiar implementation of this,
but all other cases use other "StackFrame" objects.
Use the expected names for program code.
2015-12-16 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Add JSContext Script Profiling
https://bugs.webkit.org/show_bug.cgi?id=151899
Reviewed by Brian Burg.
Extend JSC::Debugger to include a profiling client interface
that the Inspector can implement to be told about script execution
entry and exit points. Add new profiledCall/Evaluate/Construct
methods that are entry points that will notify the profiling
client if it exists.
By putting the profiling client on Debugger it avoids having
special code paths for a JSGlobalObject being JSContext inspected
or a JSGlobalObject in a Page being Web inspected. In either case
the JSGlobalObject can go through its debugger() which always
reaches the correct inspector instance.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
Handle new files.
* runtime/CallData.cpp:
(JSC::profiledCall):
* runtime/CallData.h:
* runtime/Completion.cpp:
(JSC::profiledEvaluate):
* runtime/Completion.h:
(JSC::profiledEvaluate):
* runtime/ConstructData.cpp:
(JSC::profiledConstruct):
* runtime/ConstructData.h:
(JSC::profiledConstruct):
Create profiled versions of interpreter entry points. If a profiler client is
available, this will automatically inform it of entry/exit. Include a reason
why this is being profiled. Currently all reasons in JavaScriptCore are enumerated
(API, Microtask) and Other is to be used by WebCore or future clients.
* debugger/ScriptProfilingScope.h: Added.
(JSC::ScriptProfilingScope::ScriptProfilingScope):
(JSC::ScriptProfilingScope::~ScriptProfilingScope):
(JSC::ScriptProfilingScope::shouldStartProfile):
(JSC::ScriptProfilingScope::shouldEndProfile):
At profiled entry points inform the profiling client if needed.
* API/JSBase.cpp:
(JSEvaluateScript):
* API/JSObjectRef.cpp:
(JSObjectCallAsFunction):
(JSObjectCallAsConstructor):
* runtime/JSJob.cpp:
(JSC::JSJobMicrotask::run):
Use the profiled functions for API and Microtask execution entry points.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::hasProfiler):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::hasProfiler):
Extend hasProfiler to also check the new Debugger script profiler.
* debugger/Debugger.cpp:
(JSC::Debugger::setProfilingClient):
(JSC::Debugger::willEvaluateScript):
(JSC::Debugger::didEvaluateScript):
* debugger/Debugger.h:
Pass through to the profiling client.
* inspector/protocol/ScriptProfiler.json: Added.
* inspector/agents/InspectorScriptProfilerAgent.cpp: Added.
(Inspector::InspectorScriptProfilerAgent::InspectorScriptProfilerAgent):
(Inspector::InspectorScriptProfilerAgent::~InspectorScriptProfilerAgent):
(Inspector::InspectorScriptProfilerAgent::didCreateFrontendAndBackend):
(Inspector::InspectorScriptProfilerAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorScriptProfilerAgent::startTracking):
(Inspector::InspectorScriptProfilerAgent::stopTracking):
(Inspector::InspectorScriptProfilerAgent::isAlreadyProfiling):
(Inspector::InspectorScriptProfilerAgent::willEvaluateScript):
(Inspector::InspectorScriptProfilerAgent::didEvaluateScript):
(Inspector::toProtocol):
(Inspector::InspectorScriptProfilerAgent::addEvent):
(Inspector::buildAggregateCallInfoInspectorObject):
(Inspector::buildInspectorObject):
(Inspector::buildProfileInspectorObject):
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
* inspector/agents/InspectorScriptProfilerAgent.h: Added.
New ScriptProfiler domain to just turn on / off script profiling.
It introduces a start/update/complete event model which we want
to include in new domains.
* inspector/InspectorEnvironment.h:
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
Simplify this now that we want it to be the same for all clients.
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
Create the new agent.
* inspector/InspectorProtocolTypes.h:
(Inspector::Protocol::Array::addItem):
Allow pushing a double onto a Protocol::Array.
2015-12-17 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Handle new_generator_func / new_generator_func_exp in DFG / FTL
https://bugs.webkit.org/show_bug.cgi?id=152227
Reviewed by Saam Barati.
This patch introduces new_generator_func / new_generator_func_exp into DFG and FTL.
We add a new DFG Node, NewGeneratorFunction. It will construct a function with GeneratorFunction's structure.
The structure of GeneratorFunction is different from one of Function because GeneratorFunction has the different __proto__.
Instead of extending NewFunction / PhantomNewFunction, we just added new DFG nodes, NewGeneratorFunction and PhantomNewGeneratorFunction.
This is because NewGeneratorFunction will generate an object that has different class info from JSFunction (And if JSGeneratorFunction is extended, its size will become different from JSFunction).
So, rather than extending NewFunction with generator flag, just adding new DFG nodes seems cleaner.
Object allocation sinking phase will change NewGeneratorFunction to PhantomNewGeneratorFunction and defer or eliminate its actual materialization.
It is completely the same to NewFunction and PhantomNewFunction.
And when OSR exit occurs, we need to execute deferred NewGeneratorFunction since Baseline JIT does not consider it.
So in FTL operation, we should create JSGeneratorFunction if we see PhantomNewGeneratorFunction materialization.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToPhantomNewFunction):
(JSC::DFG::Node::convertToPhantomNewGeneratorFunction):
(JSC::DFG::Node::hasCellOperand):
(JSC::DFG::Node::isFunctionAllocation):
(JSC::DFG::Node::isPhantomFunctionAllocation):
(JSC::DFG::Node::isPhantomAllocation):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunction):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateCPS):
(JSC::DFG::Validate::validateSSA):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationPopulateObjectInOSR):
(JSC::FTL::operationMaterializeObjectInOSR):
* tests/stress/generator-function-create-optimized.js: Added.
(shouldBe):
(g):
(test.return.gen):
(test):
(test2.gen):
(test2):
* tests/stress/generator-function-declaration-sinking-no-double-allocate.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(call):
(f):
(sink):
* tests/stress/generator-function-declaration-sinking-osrexit.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(g):
(f):
(sink):
* tests/stress/generator-function-declaration-sinking-put.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(g):
(f):
(sink):
* tests/stress/generator-function-expression-sinking-no-double-allocate.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(call):
(f):
(sink):
* tests/stress/generator-function-expression-sinking-osrexit.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(g):
(sink):
* tests/stress/generator-function-expression-sinking-put.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(g):
(sink):
2015-12-16 Michael Saboff <msaboff@apple.com>
ARM64 MacroAssembler improperly reuses data temp register in test32() and test8() calls
https://bugs.webkit.org/show_bug.cgi?id=152370
Reviewed by Benjamin Poulain.
Changed the test8/32(Address, Register) flavors to use the memoryTempRegister for loading the value
att Address so that it doesn't collide with the subsequent use of dataTempRegister by the
test32(Register, Register) function.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::test32):
(JSC::MacroAssemblerARM64::test8):
2015-12-16 Filip Pizlo <fpizlo@apple.com>
FTL B3 should support switches
https://bugs.webkit.org/show_bug.cgi?id=152360
Reviewed by Geoffrey Garen.
I implemented this because I was hoping it would less us run V8/crypto, but instead it just led
me to file a fun bug: https://bugs.webkit.org/show_bug.cgi?id=152365.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::check):
(JSC::FTL::Output::switchInstruction):
(JSC::FTL::Output::ret):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::ftlUnreachable):
(JSC::FTL::DFG::LowerDFGToLLVM::crash):
2015-12-16 Alex Christensen <achristensen@webkit.org>
Fix internal Windows build
https://bugs.webkit.org/show_bug.cgi?id=152364
Reviewed by Tim Horton.
* JavaScriptCore.vcxproj/JavaScriptCore.proj:
2015-12-16 Filip Pizlo <fpizlo@apple.com>
Improve JSObject::put performance
https://bugs.webkit.org/show_bug.cgi?id=152347
Reviewed by Geoffrey Garen.
This adds a new benchmark called dynbench, which just uses the C++ API to create, modify, and
query objects. This also adds some optimizations to make the JSObject::put code faster by making
it inlinable in places that really need the performance, like JITOperations and LLIntSlowPaths.
Inlining it is optional because the put() method is large. If you want it inlined, call
putInline(). There's a putInline() variant of both JSObject::put() and JSValue::put().
This is up to a 20% improvement for JSObject::put calls that get inlined all the way (like from
JITOperations and the new benchmark) and it's also a speed-up, albeit a smaller one, for
JSObject::put calls that don't get inlined (i.e. those from the DOM and the JSC C++ library code).
Specific speed-ups are as follows. Note that "dynamic context" means that we told PutPropertySlot
that we're not a static put_by_id, which turns off some type inference.
Get By Id: 2% faster
Put By Id Replace: 23% faster
Put By Id Transition + object allocation: 11% faster
Get By Id w/ dynamic context: 5% faster
Put By Id Replace w/ dynamic context: 25% faster
Put By Id Transition + object allocation w/ dynamic context: 10% faster
* JavaScriptCore.xcodeproj/project.pbxproj:
* dynbench.cpp: Added.
(JSC::benchmarkImpl):
(main):
* jit/CallFrameShuffler32_64.cpp:
* jit/CallFrameShuffler64.cpp:
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/ClassInfo.h:
(JSC::ClassInfo::hasStaticProperties):
* runtime/ConsoleClient.cpp:
* runtime/CustomGetterSetter.h:
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
(JSC::addErrorInfoAndGetBytecodeOffset): Deleted.
* runtime/GetterSetter.h:
(JSC::asGetterSetter):
* runtime/JSCInlines.h:
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::put):
(JSC::JSValue::putInternal):
(JSC::JSValue::putByIndex):
* runtime/JSObject.cpp:
(JSC::JSObject::put):
(JSC::JSObject::putByIndex):
* runtime/JSObject.h:
(JSC::JSObject::getVectorLength):
(JSC::JSObject::inlineGetOwnPropertySlot):
(JSC::JSObject::get):
(JSC::JSObject::putDirectInternal):
2015-12-16 Filip Pizlo <fpizlo@apple.com>
Work around a bug in LLVM by flipping the unification order
https://bugs.webkit.org/show_bug.cgi?id=152341
rdar://problem/23920749
Reviewed by Mark Lam.
* dfg/DFGUnificationPhase.cpp:
(JSC::DFG::UnificationPhase::run):
2015-12-16 Saam barati <sbarati@apple.com>
Add "explicit operator bool" to ScratchRegisterAllocator::PreservedState
https://bugs.webkit.org/show_bug.cgi?id=152337
Reviewed by Mark Lam.
If we have a default constructor, we should also have a way
to tell if a PreservedState is invalid.
* jit/ScratchRegisterAllocator.cpp:
(JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
(JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
* jit/ScratchRegisterAllocator.h:
(JSC::ScratchRegisterAllocator::PreservedState::PreservedState):
(JSC::ScratchRegisterAllocator::PreservedState::operator bool):
2015-12-16 Caitlin Potter <caitp@igalia.com>
[JSC] fix error message for eval/arguments CoverInitializedName in strict code
https://bugs.webkit.org/show_bug.cgi?id=152304
Reviewed by Darin Adler.
Because the error was originally classified as indicating a Pattern, the
error in AssignmentPattern parsing causes the reported message to revert to
the original Expression error message, which in this case is incorrect.
This change modifies the implementation of the strict code
error slightly, and reclassifies the error to prevent the message revert,
which improves the clarity of the message overall.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentElement):
(JSC::Parser<LexerType>::parseDestructuringPattern):
* parser/Parser.h:
(JSC::Parser::ExpressionErrorClassifier::reclassifyExpressionError):
(JSC::Parser::reclassifyExpressionError):
* tests/stress/destructuring-assignment-syntax.js:
2015-12-16 Joseph Pecoraro <pecoraro@apple.com>
Builtin source should be minified more
https://bugs.webkit.org/show_bug.cgi?id=152290
Reviewed by Darin Adler.
* Scripts/builtins/builtins_model.py:
(BuiltinFunction.fromString):
Remove primarily empty lines that would just introduce clutter.
We only do the minification in non-Debug configurations, which
is determined by the CONFIGURATION environment variable. You can
see how tests would generate differently, like so:
shell> CONFIGURATION=Release ./Tools/Scripts/run-builtins-generator-tests
2015-12-16 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r194135.
https://bugs.webkit.org/show_bug.cgi?id=152333
due to missing OSR exit materialization support in FTL
(Requested by yusukesuzuki on #webkit).
Reverted changeset:
"[ES6] Handle new_generator_func / new_generator_func_exp in
DFG / FTL"
https://bugs.webkit.org/show_bug.cgi?id=152227
http://trac.webkit.org/changeset/194135
2015-12-16 Youenn Fablet <youenn.fablet@crf.canon.fr>
[Fetch API] Add fetch API compile time flag
https://bugs.webkit.org/show_bug.cgi?id=152254
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
2015-12-16 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Handle new_generator_func / new_generator_func_exp in DFG / FTL
https://bugs.webkit.org/show_bug.cgi?id=152227
Reviewed by Saam Barati.
This patch introduces new_generator_func / new_generator_func_exp into DFG and FTL.
We add a new DFG Node, NewGeneratorFunction. It will construct a function with GeneratorFunction's structure.
The structure of GeneratorFunction is different from one of Function because GeneratorFunction has the different __proto__.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToPhantomNewFunction):
(JSC::DFG::Node::hasCellOperand):
(JSC::DFG::Node::isFunctionAllocation):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunction):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
* tests/stress/generator-function-create-optimized.js: Added.
(shouldBe):
(g):
(test.return.gen):
(test):
(test2.gen):
(test2):
* tests/stress/generator-function-declaration-sinking-no-double-allocate.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(call):
(f):
(sink):
* tests/stress/generator-function-declaration-sinking-osrexit.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(g):
(f):
(sink):
* tests/stress/generator-function-declaration-sinking-put.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(g):
(f):
(sink):
* tests/stress/generator-function-expression-sinking-no-double-allocate.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(call):
(f):
(sink):
* tests/stress/generator-function-expression-sinking-osrexit.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(g):
(sink):
* tests/stress/generator-function-expression-sinking-put.js: Added.
(shouldBe):
(GeneratorFunctionPrototype):
(g):
(sink):
2015-12-15 Mark Lam <mark.lam@apple.com>
Gardening: fix broken 32-bit JSC tests. Just need to assign a scratch register.
https://bugs.webkit.org/show_bug.cgi?id=152191
Not reviewed.
* jit/JITArithmetic.cpp:
(JSC::JIT::emitBitBinaryOpFastPath):
2015-12-15 Mark Lam <mark.lam@apple.com>
Introducing ScratchRegisterAllocator::PreservedState.
https://bugs.webkit.org/show_bug.cgi?id=152315
Reviewed by Geoffrey Garen.
restoreReusedRegistersByPopping() should always be called with 2 values that
matches the expectation of preserveReusedRegistersByPushing(). Those 2 values
are the number of bytes preserved and the ExtraStackSpace requirement. By
encapsulating them in a ScratchRegisterAllocator::PreservedState, we can make
it less error prone when calling restoreReusedRegistersByPopping(). Now, we only
need to pass it the appropriate PreservedState that its matching
preserveReusedRegistersByPushing() returned.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::restoreScratch):
(JSC::AccessCase::generate):
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
(JSC::AccessGenerationState::AccessGenerationState):
* ftl/FTLCompileBinaryOp.cpp:
(JSC::FTL::generateBinaryBitOpFastPath):
(JSC::FTL::generateRightShiftFastPath):
(JSC::FTL::generateBinaryArithOpFastPath):
* ftl/FTLLazySlowPath.cpp:
(JSC::FTL::LazySlowPath::generate):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
* jit/ScratchRegisterAllocator.cpp:
(JSC::ScratchRegisterAllocator::allocateScratchGPR):
(JSC::ScratchRegisterAllocator::allocateScratchFPR):
(JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
(JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
* jit/ScratchRegisterAllocator.h:
(JSC::ScratchRegisterAllocator::usedRegisters):
(JSC::ScratchRegisterAllocator::PreservedState::PreservedState):
2015-12-15 Mark Lam <mark.lam@apple.com>
Polymorphic operand types for DFG and FTL bit operators.
https://bugs.webkit.org/show_bug.cgi?id=152191
Reviewed by Saam Barati.
* bytecode/SpeculatedType.h:
(JSC::isUntypedSpeculationForBitOps):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateUntypedForBitOps):
- Added check for types not supported by ValueToInt32, and therefore should be
treated as untyped for bitops.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
- Handled untyped operands.
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
- Added DFG slow path functions for bitops.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
(JSC::DFG::SpeculativeJIT::compileBitwiseOp):
(JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
(JSC::DFG::SpeculativeJIT::compileShiftOp):
* dfg/DFGSpeculativeJIT.h:
- Added DFG backend support untyped operands for bitops.
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
- Limit bitops strength reduction only to when we don't have untyped operands.
This is because values that are not int32s need to be converted to int32.
Without untyped operands, the ValueToInt32 node takes care of this.
With untyped operands, we cannot use ValueToInt32, and need to do the conversion
in the code emitted for the bitop node itself. For example:
5.5 | 0; // yields 5 because ValueToInt32 converts the 5.5 to a 5.
"abc" | 0; // would yield "abc" instead of the expected 0 if we let
// strength reduction do its thing.
* ftl/FTLCompileBinaryOp.cpp:
(JSC::FTL::generateBinaryBitOpFastPath):
(JSC::FTL::generateRightShiftFastPath):
(JSC::FTL::generateBinaryOpFastPath):
* ftl/FTLInlineCacheDescriptor.h:
(JSC::FTL::BitAndDescriptor::BitAndDescriptor):
(JSC::FTL::BitAndDescriptor::icSize):
(JSC::FTL::BitAndDescriptor::nodeType):
(JSC::FTL::BitAndDescriptor::opName):
(JSC::FTL::BitAndDescriptor::slowPathFunction):
(JSC::FTL::BitAndDescriptor::nonNumberSlowPathFunction):
(JSC::FTL::BitOrDescriptor::BitOrDescriptor):
(JSC::FTL::BitOrDescriptor::icSize):
(JSC::FTL::BitOrDescriptor::nodeType):
(JSC::FTL::BitOrDescriptor::opName):
(JSC::FTL::BitOrDescriptor::slowPathFunction):
(JSC::FTL::BitOrDescriptor::nonNumberSlowPathFunction):
(JSC::FTL::BitXorDescriptor::BitXorDescriptor):
(JSC::FTL::BitXorDescriptor::icSize):
(JSC::FTL::BitXorDescriptor::nodeType):
(JSC::FTL::BitXorDescriptor::opName):
(JSC::FTL::BitXorDescriptor::slowPathFunction):
(JSC::FTL::BitXorDescriptor::nonNumberSlowPathFunction):
(JSC::FTL::BitLShiftDescriptor::BitLShiftDescriptor):
(JSC::FTL::BitLShiftDescriptor::icSize):
(JSC::FTL::BitLShiftDescriptor::nodeType):
(JSC::FTL::BitLShiftDescriptor::opName):
(JSC::FTL::BitLShiftDescriptor::slowPathFunction):
(JSC::FTL::BitLShiftDescriptor::nonNumberSlowPathFunction):
(JSC::FTL::BitRShiftDescriptor::BitRShiftDescriptor):
(JSC::FTL::BitRShiftDescriptor::icSize):
(JSC::FTL::BitRShiftDescriptor::nodeType):
(JSC::FTL::BitRShiftDescriptor::opName):
(JSC::FTL::BitRShiftDescriptor::slowPathFunction):
(JSC::FTL::BitRShiftDescriptor::nonNumberSlowPathFunction):
(JSC::FTL::BitURShiftDescriptor::BitURShiftDescriptor):
(JSC::FTL::BitURShiftDescriptor::icSize):
(JSC::FTL::BitURShiftDescriptor::nodeType):
(JSC::FTL::BitURShiftDescriptor::opName):
(JSC::FTL::BitURShiftDescriptor::slowPathFunction):
(JSC::FTL::BitURShiftDescriptor::nonNumberSlowPathFunction):
- Added support for bitop ICs.
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfBitAnd):
(JSC::FTL::sizeOfBitOr):
(JSC::FTL::sizeOfBitXor):
(JSC::FTL::sizeOfBitLShift):
(JSC::FTL::sizeOfBitRShift):
(JSC::FTL::sizeOfBitURShift):
* ftl/FTLInlineCacheSize.h:
- Added new bitop IC sizes. These are just estimates for now that work adequately,
and are shown to not impact performance on benchmarks. We will re-tune these
sizes values later in another patch once all snippet ICs have been added.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitAnd):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitOr):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitXor):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitRShift):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitLShift):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBitURShift):
- Added support for bitop ICs.
* jit/JITLeftShiftGenerator.cpp:
(JSC::JITLeftShiftGenerator::generateFastPath):
* jit/JITLeftShiftGenerator.h:
(JSC::JITLeftShiftGenerator::JITLeftShiftGenerator):
* jit/JITRightShiftGenerator.cpp:
(JSC::JITRightShiftGenerator::generateFastPath):
- The shift MASM operatons need to ensure that the shiftAmount is not in the same
register as the destination register. With the baselineJIT and DFG, this is
ensured in how we allocate these registers, and hence, the bug does not manifest.
With the FTL, these registers are not guaranteed to be unique. Hence, we need
to fix the shift op snippet code to compensate for this.
2015-12-15 Caitlin Potter <caitp@igalia.com>
[JSC] SyntaxError if AssignmentElement is `eval` or `arguments` in strict code
https://bugs.webkit.org/show_bug.cgi?id=152302
Reviewed by Mark Lam.
`eval` and `arguments` must not be assigned to in strict code. This
change fixes `language/expressions/assignment/destructuring/obj-id-simple-strict.js`
in Test262, as well as a variety of other similar tests.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentElement):
(JSC::Parser<LexerType>::parseDestructuringPattern):
* tests/stress/destructuring-assignment-syntax.js:
2015-12-15 Csaba Osztrogonác <ossy@webkit.org>
URTBF after 194062.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::supportsFloatingPointCeil): Added.
(JSC::MacroAssemblerARM::ceilDouble): Added.
2015-12-14 Filip Pizlo <fpizlo@apple.com>
FTL B3 should account for localsOffset
https://bugs.webkit.org/show_bug.cgi?id=152288
Reviewed by Saam Barati.
The DFG will build up some data structures that expect to know about offsets from FP. Those data
structures may slide by some offset when the low-level compiler (either LLVM or B3) does stack
allocation. So, the LLVM FTL modifies those data structures based on the real offset that it gets
from LLVM's stackmaps. The B3 code needs to do the same.
I had previously vowed to never put more stuff into FTLB3Compile.cpp, because I didn't want it to
look like FTLCompile.cpp. Up until now, I was successful because I used lambdas installed by
FTLLower. But in this case, I actually think that having code that just does this explicitly in
FTLB3Compile.cpp is least confusing. There is no particular place in FTLLower that would want to
care about this, and we need to ensure that we do this fixup before we run any of the stackmap
generators. In other words, it needs to happen before we call B3::generate(). The ordering
constraints seem like a good reason to have this done explicitly rather than through lambdas.
I wrote a test. The test was failing in trunk because the B3 meaning of anchor().value() is
different from the LLVM meaning. This caused breakage when we used this idiom:
ValueFromBlock foo = m_out.anchor(things);
...(foo.value()) // we were expecting that foo.value() == things
I never liked this idiom to begin with, so instead of trying to change B3's anchor(), I changed
the idiom to:
LValue fooValue = things;
ValueFromBlock foo = m_out.anchor(fooValue);
...(fooValue)
This is probably a good idea, since eventually we want B3's anchor() to just return the
UpsilonValue*. To get there, we want to eliminate any situations where code assumes that
ValueFromBlock is an actual object and not just a typedef for a pointer.
* ftl/FTLB3Compile.cpp:
(JSC::FTL::compile):
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::appendTo):
(JSC::FTL::Output::lockedStackSlot):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::framePointer):
(JSC::FTL::Output::constBool):
(JSC::FTL::Output::constInt32):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCreateDirectArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToLLVM::compileForwardVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileHasIndexedProperty):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateJSArray):
(JSC::FTL::DFG::LowerDFGToLLVM::sensibleDoubleToInt32):
* ftl/FTLState.h:
(JSC::FTL::verboseCompilationEnabled):
* tests/stress/ftl-function-dot-arguments-with-callee-saves.js: Added.
2015-12-14 Yusuke Suzuki <utatane.tea@gmail.com>
Math.random should have an intrinsic thunk and it should be later handled as a DFG Node
https://bugs.webkit.org/show_bug.cgi?id=152133
Reviewed by Geoffrey Garen.
In this patch, we implement new RandomIntrinsic. It emits a machine code to generate random numbers efficiently.
And later it will be recognized by DFG and converted to ArithRandom node.
It provides type information SpecDoubleReal since Math.random only generates a number within [0, 1.0).
Currently, only 64bit version is supported. On 32bit environment, ArithRandom will be converted to callOperation.
While it emits a function call, ArithRandom node on 32bit still represents SpecDoubleReal as a result type.
* dfg/DFGAbstractHeap.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileArithRandom):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileArithRandom):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithRandom):
* jit/AssemblyHelpers.cpp:
(JSC::emitRandomThunkImpl):
(JSC::AssemblyHelpers::emitRandomThunk):
* jit/AssemblyHelpers.h:
* jit/JITOperations.h:
* jit/ThunkGenerators.cpp:
(JSC::randomThunkGenerator):
* jit/ThunkGenerators.h:
* runtime/Intrinsic.h:
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::weakRandomOffset):
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
* runtime/VM.cpp:
(JSC::thunkGeneratorForIntrinsic):
* tests/stress/random-53bit.js: Added.
(test):
* tests/stress/random-in-range.js: Added.
(test):
2015-12-14 Benjamin Poulain <benjamin@webkit.org>
Rename FTL::Output's ceil64() to doubleCeil()
Rubber-stamped by Filip Pizlo.
ceil64() was a bad name, that's the name convention we use for integers.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doubleCeil):
(JSC::FTL::Output::ceil64): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithRound):
2015-12-14 Filip Pizlo <fpizlo@apple.com>
FTL B3 should be able to run n-body.js
https://bugs.webkit.org/show_bug.cgi?id=152281
Reviewed by Benjamin Poulain.
Fix a bug where m_captured was pointing to the start of the captured vars slot rather than the
end, like the rest of the FTL expected.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
2015-12-14 Benjamin Poulain <bpoulain@apple.com>
Fix bad copy-paste in r194062
* ftl/FTLB3Output.h:
(JSC::FTL::Output::ceil64):
2015-12-14 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix cloop build.
* jit/GPRInfo.cpp:
2015-12-14 Filip Pizlo <fpizlo@apple.com>
FTL B3 should do PutById
https://bugs.webkit.org/show_bug.cgi?id=152268
Reviewed by Saam Barati.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createGenericCompare): I realized that we were missing some useful matching rules.
* b3/testb3.cpp: Added a bunch of tests.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById): Do the things.
* jit/GPRInfo.cpp: Added. I had to do this yucky thing because clang was having issues compiling references to this from deeply nested lambdas.
* jit/GPRInfo.h: Added a comment about how patchpointScratchRegister is bizarre and should probably die.
2015-12-14 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add ceil() support for x86 and expose it to B3
https://bugs.webkit.org/show_bug.cgi?id=152231
Reviewed by Geoffrey Garen.
Most x86 CPUs we care about support ceil() natively
with the round instruction.
This patch expose that behind a runtime flag, use it
in the Math.ceil() thunk and expose it to B3.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::supportsFloatingPointCeil):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::supportsFloatingPointCeil):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::supportsFloatingPointCeil):
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::supportsFloatingPointCeil):
* assembler/MacroAssemblerX86Common.cpp:
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::ceilDouble):
(JSC::MacroAssemblerX86Common::ceilFloat):
(JSC::MacroAssemblerX86Common::supportsFloatingPointCeil):
(JSC::MacroAssemblerX86Common::supportsLZCNT):
* assembler/X86Assembler.h:
(JSC::X86Assembler::roundss_rr):
(JSC::X86Assembler::roundss_mr):
(JSC::X86Assembler::roundsd_rr):
(JSC::X86Assembler::roundsd_mr):
(JSC::X86Assembler::mfence):
(JSC::X86Assembler::X86InstructionFormatter::threeByteOp):
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::ceilConstant):
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.cpp:
(JSC::B3::ConstFloatValue::ceilConstant):
* b3/B3ConstFloatValue.h:
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3ReduceDoubleToFloat.cpp:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::ceilConstant):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testCeilArg):
(JSC::B3::testCeilImm):
(JSC::B3::testCeilMem):
(JSC::B3::testCeilCeilArg):
(JSC::B3::testCeilIToD64):
(JSC::B3::testCeilIToD32):
(JSC::B3::testCeilArgWithUselessDoubleConversion):
(JSC::B3::testCeilArgWithEffectfulDoubleConversion):
(JSC::B3::populateWithInterestingValues):
(JSC::B3::run):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::ceil64):
* jit/ThunkGenerators.cpp:
(JSC::ceilThunkGenerator):
2015-12-14 Andreas Kling <akling@apple.com>
ResourceUsageOverlay should show GC timers.
<https://webkit.org/b/152151>
Reviewed by Darin Adler.
Expose the next fire time (in WTF timestamp style) of a GCActivityCallback.
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::scheduleTimer):
(JSC::GCActivityCallback::cancelTimer):
* heap/GCActivityCallback.h:
2015-12-14 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix merge issue in a test.
* b3/testb3.cpp:
(JSC::B3::testCheckTwoMegaCombos):
(JSC::B3::testCheckTwoNonRedundantMegaCombos):
2015-12-14 Filip Pizlo <fpizlo@apple.com>
B3 should not give ValueReps for the non-stackmap children of a CheckValue to the generator callback
https://bugs.webkit.org/show_bug.cgi?id=152224
Reviewed by Geoffrey Garen.
Previously, a stackmap generator for a Check had to know how many children the B3 value for the
Check had at the time of code generation. That meant that B3 could not change the kind of Check
that it was - for example it cannot turn a Check into a Patchpoint and it cannot turn a CheckAdd
into a Check. But just changing the contract so that the stackmap generation params only get the
stackmap children of the check means that B3 can transform Checks as it likes.
This is meant to aid sinking values into checks.
Also, I found that the effects of a Check did not include HeapRange::top(). I think it's best if
exitsSideways does not imply reading top, the way that it does in DFG. In the DFG, that makes
sense because the exit analysis is orthogonal, so the clobber analysis tells you about the reads
not counting OSR exit - if you need to you can conditionally merge that with World based on a
separate exit analysis. But in B3, the Effects object tells you about both exiting and reading,
and it's computed by one analysis. Prior to this change, Check was not setting reads to top() so
we were effectively saying that Effects::reads is meaningless when exitsSideways is true. It
seems more sensible to instead force the analysis to set reads to top() when setting
exitsSideways to true, not least because we only have one such analysis and many users. But it
also makes sense for another reason: it allows us to bound the set of things that the program
will read after it exits. That might not be useful to us now, but it's a nice feature to get for
free. I've seen language features that have behave like exitsSideways that don't also read top,
like an array bounds check that causes sudden termination without making any promises about how
pretty the crash dump will look.
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::generate):
* b3/B3Opcode.h:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
* b3/testb3.cpp:
(JSC::B3::testSimpleCheck):
(JSC::B3::testCheckLessThan):
(JSC::B3::testCheckMegaCombo):
(JSC::B3::testCheckAddImm):
(JSC::B3::testCheckAddImmCommute):
(JSC::B3::testCheckAddImmSomeRegister):
(JSC::B3::testCheckAdd):
(JSC::B3::testCheckAdd64):
(JSC::B3::testCheckSubImm):
(JSC::B3::testCheckSubBadImm):
(JSC::B3::testCheckSub):
(JSC::B3::testCheckSub64):
(JSC::B3::testCheckNeg):
(JSC::B3::testCheckNeg64):
(JSC::B3::testCheckMul):
(JSC::B3::testCheckMulMemory):
(JSC::B3::testCheckMul2):
(JSC::B3::testCheckMul64):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
2015-12-14 Filip Pizlo <fpizlo@apple.com>
Air: Support Architecture-specific forms and Opcodes
https://bugs.webkit.org/show_bug.cgi?id=151736
Reviewed by Benjamin Poulain.
This adds really awesome architecture selection to the AirOpcode.opcodes file. If an opcode or
opcode form is unavailable on some architecture, you can still mention its name in C++ code (it'll
still be a member of the enum) but isValidForm() and all other reflective queries will tell you
that it doesn't exist. This will make the instruction selector steer clear of it, and it will
also ensure that the spiller doesn't try to use any unavailable architecture-specific address
forms.
The new capability is documented extensively in a comment in AirOpcode.opcodes.
* b3/air/AirOpcode.opcodes:
* b3/air/opcode_generator.rb:
2015-12-14 Mark Lam <mark.lam@apple.com>
Misc. small fixes in snippet related code.
https://bugs.webkit.org/show_bug.cgi?id=152259
Reviewed by Saam Barati.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithMul):
- When loading a constant JSValue for a node, use the one that the node already
provides instead of reconstructing it. This is not a bug, but the fix makes
the code cleaner.
* jit/JITBitAndGenerator.cpp:
(JSC::JITBitAndGenerator::generateFastPath):
- No need to do a bitand with a constant int 0xffffffff operand.
* jit/JITBitOrGenerator.cpp:
(JSC::JITBitOrGenerator::generateFastPath):
- Fix comments: bitor is '|', not '&'.
- No need to do a bitor with a constant int 0 operand.
* jit/JITBitXorGenerator.cpp:
(JSC::JITBitXorGenerator::generateFastPath):
- Fix comments: bitxor is '^', not '&'.
* jit/JITRightShiftGenerator.cpp:
(JSC::JITRightShiftGenerator::generateFastPath):
- Renamed a jump target name to be clearer about its purpose.
2015-12-14 Mark Lam <mark.lam@apple.com>
We should not employ the snippet code in the DFG if no OSR exit was previously encountered.
https://bugs.webkit.org/show_bug.cgi?id=152255
Reviewed by Saam Barati.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2015-12-14 Filip Pizlo <fpizlo@apple.com>
B3->Air compare-branch fusion should fuse even if the result of the comparison is used more than once
https://bugs.webkit.org/show_bug.cgi?id=152198
Reviewed by Benjamin Poulain.
If we have a comparison operation that is branched on from multiple places, then we were
previously executing the comparison to get a boolean result in a register and then we were
testing/branching on that register in multiple places. This is actually less efficient than
just fusing the compare/branch multiple times, even though this means that the comparison
executes multiple times. This would only be bad if the comparison fused loads multiple times,
since duplicating loads is both wrong and inefficient. So, this adds the notion of sharing to
compare/branch fusion. If a compare is shared by multiple branches, then we refuse to fuse
the load.
To write the test, I needed to zero-extend 8 to 32. In the process of thinking about how to
do this, I realized that we needed lowerings for SExt8/SExt16. And I realized that the
lowerings for the other extension operations were not fully fleshed out; for example they
were incapable of load fusion. This patch fixes this and also adds some smart strength
reductions for BitAnd(@x, 0xff/0xffff/0xffffffff) - all of which should be lowered to a zero
extension.
This is a big win on asm.js code. It's not enough to bridge the gap to LLVM, but it's a huge
step in that direction.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::load8SignedExtendTo32):
(JSC::MacroAssemblerX86Common::zeroExtend8To32):
(JSC::MacroAssemblerX86Common::signExtend8To32):
(JSC::MacroAssemblerX86Common::load16):
(JSC::MacroAssemblerX86Common::load16SignedExtendTo32):
(JSC::MacroAssemblerX86Common::zeroExtend16To32):
(JSC::MacroAssemblerX86Common::signExtend16To32):
(JSC::MacroAssemblerX86Common::store32WithAddressOffsetPatch):
* assembler/X86Assembler.h:
(JSC::X86Assembler::movzbl_rr):
(JSC::X86Assembler::movsbl_rr):
(JSC::X86Assembler::movzwl_rr):
(JSC::X86Assembler::movswl_rr):
(JSC::X86Assembler::cmovl_rr):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createGenericCompare):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3ReduceStrength.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testCheckMegaCombo):
(JSC::B3::testCheckTwoMegaCombos):
(JSC::B3::testCheckTwoNonRedundantMegaCombos):
(JSC::B3::testCheckAddImm):
(JSC::B3::testTruncSExt32):
(JSC::B3::testSExt8):
(JSC::B3::testSExt8Fold):
(JSC::B3::testSExt8SExt8):
(JSC::B3::testSExt8SExt16):
(JSC::B3::testSExt8BitAnd):
(JSC::B3::testBitAndSExt8):
(JSC::B3::testSExt16):
(JSC::B3::testSExt16Fold):
(JSC::B3::testSExt16SExt16):
(JSC::B3::testSExt16SExt8):
(JSC::B3::testSExt16BitAnd):
(JSC::B3::testBitAndSExt16):
(JSC::B3::testSExt32BitAnd):
(JSC::B3::testBitAndSExt32):
(JSC::B3::testBasicSelect):
(JSC::B3::run):
2015-12-14 Chris Dumez <cdumez@apple.com>
Roll out r193974 and follow-up fixes as it caused JSC crashes
https://bugs.webkit.org/show_bug.cgi?id=152256
Unreviewed, Roll out r193974 and follow-up fixes as it caused JSC crashes.
* API/JSCallbackObject.h:
* builtins/FunctionPrototype.js:
* bytecode/BytecodeBasicBlock.cpp:
(JSC::isBranch):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/ExitKind.cpp:
(JSC::exitKindToString): Deleted.
* bytecode/ExitKind.h:
* bytecode/PreciseJumpTargets.cpp:
(JSC::getJumpTargetsForBytecodeOffset):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCheckHasInstance):
(JSC::BytecodeGenerator::emitGetById): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitTypeOf): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::InstanceOfNode::emitBytecode):
(JSC::LogicalOpNode::emitBytecode): Deleted.
(JSC::LogicalOpNode::emitBytecodeInConditionContext): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCellOperand): Deleted.
(JSC::DFG::Node::hasTransition): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileInstanceOf): Deleted.
(JSC::DFG::SpeculativeJIT::compileArithAdd): Deleted.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation): Deleted.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckHasInstance):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInstanceOf): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::compileHasIndexedProperty): Deleted.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArguments): Deleted.
(JSC::CCallHelpers::setupArgumentsWithExecState): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperationNoExceptionCheck): Deleted.
(JSC::JIT::callOperation): Deleted.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_check_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_check_has_instance):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emit_op_is_undefined): Deleted.
(JSC::JIT::emitSlow_op_to_number): Deleted.
(JSC::JIT::emitSlow_op_to_string): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_check_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_check_has_instance):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emit_op_is_undefined): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions): Deleted.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonIdentifiers.h:
* runtime/ExceptionHelpers.cpp:
(JSC::invalidParameterInstanceofSourceAppender):
(JSC::createInvalidInstanceofParameterError):
(JSC::createError): Deleted.
(JSC::createNotAFunctionError): Deleted.
(JSC::createNotAnObjectError): Deleted.
* runtime/ExceptionHelpers.h:
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::addFunctionProperties):
* runtime/FunctionPrototype.h:
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::create): Deleted.
(JSC::JSBoundFunction::customHasInstance): Deleted.
* runtime/JSBoundFunction.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::throwTypeErrorGetterSetter): Deleted.
* runtime/JSObject.cpp:
(JSC::JSObject::hasInstance):
(JSC::JSObject::defaultHasInstance): Deleted.
(JSC::JSObject::getPropertyNames): Deleted.
(JSC::JSObject::getOwnPropertyNames): Deleted.
* runtime/JSObject.h:
(JSC::JSFinalObject::create): Deleted.
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::TypeInfo):
(JSC::TypeInfo::overridesHasInstance):
* runtime/WriteBarrier.h:
(JSC::WriteBarrierBase<Unknown>::slot):
* tests/es6.yaml:
* tests/stress/instanceof-custom-hasinstancesymbol.js: Removed.
* tests/stress/symbol-hasInstance.js: Removed.
2015-12-13 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove FTL::Output's doubleEqualOrUnordered()
https://bugs.webkit.org/show_bug.cgi?id=152234
Reviewed by Sam Weinig.
It is unused, one less thing to worry about.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doubleEqualOrUnordered): Deleted.
* ftl/FTLOutput.h:
(JSC::FTL::Output::doubleEqualOrUnordered): Deleted.
2015-12-13 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Should not emit get_by_id for indexed property access
https://bugs.webkit.org/show_bug.cgi?id=151354
Reviewed by Darin Adler.
Before this patch, `a["1"]` is converted to `a.1` get_by_id operation in the bytecode compiler.
get_by_id emits IC. IC rely on the fact that Structure transition occur when adding / removing object's properties.
However, it's not true for indexed element properties. They are stored in the element storage and Structure transition does not occur.
For example, in the following case,
function getOne(a) { return a['1']; }
for (var i = 0; i < 36; ++i)
getOne({2: true});
if (!getOne({1: true}))
throw new Error("OUT");
In this case, `a['1']` creates get_by_id. `getOne({2: true})` calls makes getOne's get_by_id to create IC says that,
"when comming this structure chain, there is no property in "1", so we should return `undefined`".
After that, we call `getOne({1: true})`. But in this case, `{2: true}` and `{1: true}` have the same structure chain,
because indexed property addition does not occur structure transition.
So previous IC fast path is used and return `undefined`. But the correct answer is returning `true`.
This patch fixes the above issue. When there is string bracket access, we only emits get_by_id if the given string is not an index.
There are bugs in get_by_id, put_by_id, put_by_id (direct). But only get_by_id poses user observable issue.
Because in the put_by_id case, the generic path just says "this put is uncacheable".
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGetById):
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
* bytecompiler/NodesCodegen.cpp:
(JSC::isNonIndexStringElement):
(JSC::BracketAccessorNode::emitBytecode):
(JSC::FunctionCallBracketNode::emitBytecode):
(JSC::AssignBracketNode::emitBytecode):
(JSC::ObjectPatternNode::bindValue):
* tests/stress/element-property-get-should-not-handled-with-get-by-id.js: Added.
(getOne):
2015-12-13 Andreas Kling <akling@apple.com>
CachedScript could have a copy-free path for all-ASCII scripts.
<https://webkit.org/b/152203>
Reviewed by Antti Koivisto.
Make SourceProvider vend a StringView instead of a String.
This relaxes the promises that providers have to make about string lifetimes.
This means that on the WebCore side, CachedScript is free to cache a String
internally, while only ever exposing it as a temporary StringView.
A few extra copies (CPU, not memory) are introduced, none of them on hot paths.
* API/JSScriptRef.cpp:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::dumpSource):
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::dispatchDidParseSource):
(Inspector::ScriptDebugServer::dispatchFailedToParseSource):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* jsc.cpp:
(functionFindTypeForExpression):
(functionHasBasicBlockExecuted):
(functionBasicBlockExecutionCount):
* parser/Lexer.cpp:
(JSC::Lexer<T>::setCode):
* parser/Lexer.h:
(JSC::Lexer<LChar>::setCodeStart):
(JSC::Lexer<UChar>::setCodeStart):
* parser/Parser.h:
(JSC::Parser::getToken):
* parser/SourceCode.cpp:
(JSC::SourceCode::toUTF8):
* parser/SourceCode.h:
(JSC::SourceCode::hash):
(JSC::SourceCode::view):
(JSC::SourceCode::toString): Deleted.
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::string):
* parser/SourceProvider.h:
(JSC::SourceProvider::getRange):
* runtime/Completion.cpp:
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
* runtime/ErrorInstance.cpp:
(JSC::appendSourceToError):
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* tools/FunctionOverrides.cpp:
(JSC::initializeOverrideInfo):
(JSC::FunctionOverrides::initializeOverrideFor):
2015-12-12 Benjamin Poulain <benjamin@webkit.org>
[JSC] Add lowering for B3's Store8 opcode
https://bugs.webkit.org/show_bug.cgi?id=152208
Reviewed by Geoffrey Garen.
B3 has an opcode to store 8bit values but it had
no lowering.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createStore):
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testStore8Arg):
(JSC::B3::testStore8Imm):
(JSC::B3::testStorePartial8BitRegisterOnX86):
(JSC::B3::run):
2015-12-12 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Add the missing setupArgumentsWithExecState functions after r193974
https://bugs.webkit.org/show_bug.cgi?id=152214
Reviewed by Mark Lam.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
2015-12-11 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Too many derefs when RemoteInspectorXPCConnection fails to validate connection
https://bugs.webkit.org/show_bug.cgi?id=152213
Rubber-stamped by Ryosuke Niwa.
* inspector/remote/RemoteInspectorXPCConnection.mm:
(Inspector::RemoteInspectorXPCConnection::handleEvent):
We should just close the XPC connection triggering XPC_ERROR_CONNECTION_INVALID
which will then graceful teardown the connection as expected.
2015-12-11 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add Floating Point Abs() to B3
https://bugs.webkit.org/show_bug.cgi?id=152176
Reviewed by Geoffrey Garen.
This patch adds an Abs() operation for floating point.
On x86, Abs() is implemented by masking the top bit
of the floating point value. On ARM64, there is a builtin
abs opcode.
To account for those differences, B3 use "Abs" as
the cannonical operation. When we are about to lower
to Air, Abs is extended on x86 to get a clean handling
of the mask constants.
This patch has one cool thing related to FTL.
If you do:
@1 = unboxDouble(@0)
@2 = abs(@1)
@3 = boxDouble(@2)
B3ReduceStrength completely eliminate the Double-Integer
conversion.
The strength reduction of Abs is aware that it can do a bit
mask over the bitcast used by unboxing.
If even works if you use floats by forcing fround: reduceDoubleToFloat()
elminiates the useless conversions, followed by ReduceStrength
that removes the switch from GP to FP.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::andDouble):
(JSC::MacroAssemblerX86Common::andFloat):
* assembler/X86Assembler.h:
(JSC::X86Assembler::andps_rr):
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::bitAndConstant):
(JSC::B3::ConstDoubleValue::absConstant):
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.cpp:
(JSC::B3::ConstFloatValue::bitAndConstant):
(JSC::B3::ConstFloatValue::absConstant):
* b3/B3ConstFloatValue.h:
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3LowerMacrosAfterOptimizations.cpp: Added.
(JSC::B3::lowerMacrosAfterOptimizations):
* b3/B3LowerMacrosAfterOptimizations.h: Added.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3ReduceDoubleToFloat.cpp:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::absConstant):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::bitAndDouble):
(JSC::B3::testBitAndArgDouble):
(JSC::B3::testBitAndArgsDouble):
(JSC::B3::testBitAndArgImmDouble):
(JSC::B3::testBitAndImmsDouble):
(JSC::B3::bitAndFloat):
(JSC::B3::testBitAndArgFloat):
(JSC::B3::testBitAndArgsFloat):
(JSC::B3::testBitAndArgImmFloat):
(JSC::B3::testBitAndImmsFloat):
(JSC::B3::testBitAndArgsFloatWithUselessDoubleConversion):
(JSC::B3::testAbsArg):
(JSC::B3::testAbsImm):
(JSC::B3::testAbsMem):
(JSC::B3::testAbsAbsArg):
(JSC::B3::testAbsBitwiseCastArg):
(JSC::B3::testBitwiseCastAbsBitwiseCastArg):
(JSC::B3::testAbsArgWithUselessDoubleConversion):
(JSC::B3::testAbsArgWithEffectfulDoubleConversion):
(JSC::B3::run):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doubleAbs):
2015-12-11 Mark Lam <mark.lam@apple.com>
Removed some dead code, and simplified some code in the baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=152199
Reviewed by Benjamin Poulain.
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emit_op_bitand):
(JSC::JIT::emitSlow_op_lshift):
(JSC::JIT::emitRightShiftFastPath):
(JSC::JIT::emit_op_rshift):
(JSC::JIT::emitSlow_op_rshift):
(JSC::JIT::emit_op_urshift):
(JSC::JIT::emitSlow_op_urshift):
2015-12-11 Filip Pizlo <fpizlo@apple.com>
B3::reduceStrength should remove redundant Phi's
https://bugs.webkit.org/show_bug.cgi?id=152184
Reviewed by Benjamin Poulain.
This adds redundant Phi removal using Aycock and Horspools SSA simplification algorithm. This
is needed because even in simple asm.js code, we see a lot of CFG simplification that leaves
behind totally useless Phi's.
* b3/B3PhiChildren.cpp:
(JSC::B3::PhiChildren::PhiChildren):
* b3/B3PhiChildren.h:
(JSC::B3::PhiChildren::at):
(JSC::B3::PhiChildren::operator[]):
(JSC::B3::PhiChildren::phis):
* b3/B3ReduceStrength.cpp:
2015-12-11 Benjamin Poulain <benjamin@webkit.org>
[JSC] Add an implementation of pow() taking an integer exponent to B3
https://bugs.webkit.org/show_bug.cgi?id=152165
Reviewed by Mark Lam.
LLVM has this really neat optimized opcode for
raising the power of something by an integer exponent.
There is no such native instruction so we need to extend
the existing FTLOutput API to something efficient.
DFG has a pretty competitive implementation. In this patch,
I added a version of it to B3.
I created powDoubleInt32() instead of putting the code directly
in FTL for easier testing and optimization.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3MathExtras.cpp: Added.
(JSC::B3::powDoubleInt32):
* b3/B3MathExtras.h: Added.
* b3/B3MemoryValue.h:
* b3/testb3.cpp:
(JSC::B3::testPowDoubleByIntegerLoop):
(JSC::B3::run):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::compileArithPowIntegerFastPath):
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::doublePowi):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doublePowi): Deleted.
2015-12-11 Filip Pizlo <fpizlo@apple.com>
B3 should have CSE
https://bugs.webkit.org/show_bug.cgi?id=150961
Reviewed by Benjamin Poulain.
This implements a very simple CSE for pure values. I need this as a prerequisite for other
optimizations that I'm implementing. For now, this is neutral on imaging-gaussian-blur but a
slow-down on asm.js code. I suspect that the asm.js slow-down is because of other things that are
still going wrong, and anyway, I need CSE to be able to do even the most basic asm.js strength
reductions.
* b3/B3ReduceStrength.cpp:
* b3/B3ReduceStrength.h:
* b3/B3Value.cpp:
(JSC::B3::Value::replaceWithIdentity):
(JSC::B3::Value::key):
2015-12-11 Mark Lam <mark.lam@apple.com>
Refactoring to reduce potential cut-paste errors with the FTL ICs.
https://bugs.webkit.org/show_bug.cgi?id=152185
Reviewed by Saam Barati.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLCompile.cpp:
- ICs now have their own names. GetById and PutByID fast path ICs no longer just
say "inline cache fast path".
* ftl/FTLCompileBinaryOp.cpp:
(JSC::FTL::generateBinaryArithOpFastPath):
- Fixed an indentation.
* ftl/FTLInlineCacheDescriptor.h:
(JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
(JSC::FTL::InlineCacheDescriptor::name):
(JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
(JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
(JSC::FTL::CheckInDescriptor::CheckInDescriptor):
(JSC::FTL::BinaryOpDescriptor::nodeType):
(JSC::FTL::BinaryOpDescriptor::size):
(JSC::FTL::BinaryOpDescriptor::slowPathFunction):
(JSC::FTL::BinaryOpDescriptor::leftOperand):
(JSC::FTL::BinaryOpDescriptor::BinaryOpDescriptor):
(JSC::FTL::ArithDivDescriptor::ArithDivDescriptor):
(JSC::FTL::ArithDivDescriptor::icSize):
(JSC::FTL::ArithDivDescriptor::nodeType):
(JSC::FTL::ArithDivDescriptor::opName):
(JSC::FTL::ArithDivDescriptor::slowPathFunction):
(JSC::FTL::ArithDivDescriptor::nonNumberSlowPathFunction):
(JSC::FTL::ArithMulDescriptor::ArithMulDescriptor):
(JSC::FTL::ArithMulDescriptor::icSize):
(JSC::FTL::ArithMulDescriptor::nodeType):
(JSC::FTL::ArithMulDescriptor::opName):
(JSC::FTL::ArithMulDescriptor::slowPathFunction):
(JSC::FTL::ArithMulDescriptor::nonNumberSlowPathFunction):
(JSC::FTL::ArithSubDescriptor::ArithSubDescriptor):
(JSC::FTL::ArithSubDescriptor::icSize):
(JSC::FTL::ArithSubDescriptor::nodeType):
(JSC::FTL::ArithSubDescriptor::opName):
(JSC::FTL::ArithSubDescriptor::slowPathFunction):
(JSC::FTL::ArithSubDescriptor::nonNumberSlowPathFunction):
(JSC::FTL::ValueAddDescriptor::ValueAddDescriptor):
(JSC::FTL::ValueAddDescriptor::icSize):
(JSC::FTL::ValueAddDescriptor::nodeType):
(JSC::FTL::ValueAddDescriptor::opName):
(JSC::FTL::ValueAddDescriptor::slowPathFunction):
(JSC::FTL::ValueAddDescriptor::nonNumberSlowPathFunction):
(JSC::FTL::LazySlowPathDescriptor::LazySlowPathDescriptor):
(JSC::FTL::ProbeDescriptor::ProbeDescriptor):
(JSC::FTL::BinaryOpDescriptor::name): Deleted.
(JSC::FTL::BinaryOpDescriptor::fastPathICName): Deleted.
* ftl/FTLInlineCacheDescriptorInlines.h: Removed.
- Consolidate the number of places where we have to fill in a data about new
snippet ICs. It is all done in FTLInlineCacheDescriptor.h now.
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileUntypedBinaryOp):
(JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
- Introduced a compileUntypedBinaryOp() template and use that at all the FTL
places that need to use a snippet. This reduces the amount of cut and paste
code.
* ftl/FTLState.h:
- Removed a bad #include.
2015-12-11 Keith Miller <keith_miller@apple.com>
Overrides has instance should not move ValueFalse to a register then immediately to the stack in the LLInt.
https://bugs.webkit.org/show_bug.cgi?id=152188
Reviewed by Mark Lam.
This fixes a minor issue with the code for the overrides_has_instance in the LLInt. Old code had an extra move,
which is both slow and breaks the build on cloop.
* llint/LowLevelInterpreter64.asm:
2015-12-11 Keith Miller <keith_miller@apple.com>
[ES6] Add support for Symbol.hasInstance
https://bugs.webkit.org/show_bug.cgi?id=151839
Reviewed by Saam Barati.
This patch adds support for Symbol.hasInstance, unfortunately in order to prevent
regressions several new bytecodes and DFG IR nodes were necessary. Before, Symbol.hasInstance
when executing an instanceof expression we would emit three bytecodes: overrides_has_instance, get_by_id,
then instanceof. As the spec has changed, we emit a more complicated set of bytecodes in addition to some
new ones. First the role of overrides_has_instance and its corresponding DFG node have changed. Now it returns
a js-boolean indicating whether the RHS of the instanceof expression (from here on called the constructor for simplicity)
needs non-default behavior for resolving the expression. i.e. The constructor has a Symbol.hasInstance that differs from the one on
Function.prototype[Symbol.hasInstance] or is a bound/C-API function. Once we get to the DFG this node is generally eliminated as
we can prove the value of Symbol.hasInstance is a constant. The second new bytecode is instanceof_custom. insntanceof_custom, just
emits a call to slow path code that computes the result.
In the DFG, there is also a new node, CheckTypeInfoFlags, which checks the type info flags are consistent with the ones provided and
OSR exits if the flags are not. Additionally, we attempt to prove that the result of CheckHasValue will be a constant and transform
it into a CheckTypeInfoFlags followed by a JSConstant.
* API/JSCallbackObject.h:
* builtins/FunctionPrototype.js:
(symbolHasInstance):
* bytecode/BytecodeBasicBlock.cpp:
(JSC::isBranch): Deleted.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* bytecode/PreciseJumpTargets.cpp:
(JSC::getJumpTargetsForBytecodeOffset): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitOverridesHasInstance):
(JSC::BytecodeGenerator::emitInstanceOfCustom):
(JSC::BytecodeGenerator::emitCheckHasInstance): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::InstanceOfNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCellOperand):
(JSC::DFG::Node::hasTypeInfoOperand):
(JSC::DFG::Node::typeInfoOperand):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags):
(JSC::DFG::SpeculativeJIT::compileInstanceOfCustom):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileOverridesHasInstance):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckTypeInfoFlags):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInstanceOfCustom):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckHasInstance): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emit_op_instanceof_custom):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_check_has_instance): Deleted.
(JSC::JIT::emitSlow_op_check_has_instance): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emit_op_instanceof_custom):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_check_has_instance): Deleted.
(JSC::JIT::emitSlow_op_check_has_instance): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonIdentifiers.h:
* runtime/ExceptionHelpers.cpp:
(JSC::invalidParameterInstanceofSourceAppender):
(JSC::invalidParameterInstanceofNotFunctionSourceAppender):
(JSC::invalidParameterInstanceofhasInstanceValueNotFunctionSourceAppender):
(JSC::createInvalidInstanceofParameterErrorNotFunction):
(JSC::createInvalidInstanceofParameterErrorhasInstanceValueNotFunction):
(JSC::createInvalidInstanceofParameterError): Deleted.
* runtime/ExceptionHelpers.h:
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::addFunctionProperties):
* runtime/FunctionPrototype.h:
* runtime/JSBoundFunction.cpp:
(JSC::isBoundFunction):
(JSC::hasInstanceBoundFunction):
* runtime/JSBoundFunction.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
* runtime/JSObject.cpp:
(JSC::JSObject::hasInstance):
(JSC::objectPrivateFuncInstanceOf):
* runtime/JSObject.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::TypeInfo):
(JSC::TypeInfo::overridesHasInstance):
* runtime/WriteBarrier.h:
(JSC::WriteBarrierBase<Unknown>::slot):
* tests/es6.yaml:
* tests/stress/instanceof-custom-hasinstancesymbol.js: Added.
(Constructor):
(value):
(instanceOf):
(body):
* tests/stress/symbol-hasInstance.js: Added.
(Constructor):
(value):
(ObjectClass.Symbol.hasInstance):
(NumberClass.Symbol.hasInstance):
2015-12-11 Joseph Pecoraro <pecoraro@apple.com>
check-for-inappropriate-objc-class-names should check all class names, not just externally visible ones
https://bugs.webkit.org/show_bug.cgi?id=152156
Reviewed by Dan Bernstein.
* llvm/InitializeLLVMMac.cpp:
Remove stale comment. The ObjC class this comment referenced
has already been removed.
2015-12-11 Benjamin Poulain <benjamin@webkit.org>
[JSC] Little cleanup of FTLOutput type casts and conversions
https://bugs.webkit.org/show_bug.cgi?id=152166
Reviewed by Geoffrey Garen.
Clean up:
-Change fpCast() to explicit conversion doubleToFloat() and floatToDouble()
to match B3's opcodes.
-Remove unused conversion functions.
-Use the most specific cast function when possible.
-Functions that are only used inside FTLOutput are made private.
In FTLB3Output, those functions were removed.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doubleToFloat):
(JSC::FTL::Output::floatToDouble):
(JSC::FTL::Output::fround):
(JSC::FTL::Output::fpToInt): Deleted.
(JSC::FTL::Output::fpToUInt): Deleted.
(JSC::FTL::Output::intToFP): Deleted.
(JSC::FTL::Output::unsignedToFP): Deleted.
(JSC::FTL::Output::intCast): Deleted.
(JSC::FTL::Output::fpCast): Deleted.
(JSC::FTL::Output::intToPtr): Deleted.
(JSC::FTL::Output::ptrToInt): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutByVal):
* ftl/FTLOutput.h:
(JSC::FTL::Output::doubleToFloat):
(JSC::FTL::Output::floatToDouble):
(JSC::FTL::Output::intCast):
(JSC::FTL::Output::fpToInt):
(JSC::FTL::Output::fpToUInt):
(JSC::FTL::Output::fpCast):
(JSC::FTL::Output::intToFP):
(JSC::FTL::Output::unsignedToFP):
2015-12-10 Youenn Fablet <youenn.fablet@crf.canon.fr>
Binding and builtin generators should lowercase RTCXX as rtcXX and not rTCXX
https://bugs.webkit.org/show_bug.cgi?id=152121
Reviewed by Darin Adler.
* Scripts/builtins/builtins_generator.py:
(WK_lcfirst): Added RTC special rule.
2015-12-09 Filip Pizlo <fpizlo@apple.com>
FTL B3 should be able to run quicksort asm.js test
https://bugs.webkit.org/show_bug.cgi?id=152105
Reviewed by Geoffrey Garen.
This covers making all of the changes needed to run quicksort.js from AsmBench.
- Reintroduced float types to FTLLower since we now have B3::Float.
- Gave FTL::Output the ability to speak of load types and store types separately from LValue
types. This dodges the problem that B3 doesn't have types for Int8 and Int16 but supports loads
and stores of that type.
- Implemented Mod in B3 and wrote tests.
I also fixed a pre-existing bug in a test that appeared to only manifest in release builds.
Currently, B3's performance on asm.js tests is not good. It should be easy to fix:
- B3 should strength-reduce the shifting madness that happens in asm.js memory accesses
https://bugs.webkit.org/show_bug.cgi?id=152106
- B3 constant hoisting should have a story for the asm.js heap constant
https://bugs.webkit.org/show_bug.cgi?id=152107
* b3/B3CCallValue.h:
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::divConstant):
(JSC::B3::Const32Value::modConstant):
(JSC::B3::Const32Value::bitAndConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::divConstant):
(JSC::B3::Const64Value::modConstant):
(JSC::B3::Const64Value::bitAndConstant):
* b3/B3Const64Value.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::divConstant):
(JSC::B3::Value::modConstant):
(JSC::B3::Value::bitAndConstant):
* b3/B3Value.h:
* b3/testb3.cpp:
(JSC::B3::testChillDiv64):
(JSC::B3::testMod):
(JSC::B3::testSwitch):
(JSC::B3::run):
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::load16ZeroExt32):
(JSC::FTL::Output::store):
(JSC::FTL::Output::store32As8):
(JSC::FTL::Output::store32As16):
(JSC::FTL::Output::loadFloatToDouble): Deleted.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::mul):
(JSC::FTL::Output::div):
(JSC::FTL::Output::chillDiv):
(JSC::FTL::Output::rem):
(JSC::FTL::Output::neg):
(JSC::FTL::Output::load32):
(JSC::FTL::Output::load64):
(JSC::FTL::Output::loadPtr):
(JSC::FTL::Output::loadFloat):
(JSC::FTL::Output::loadDouble):
(JSC::FTL::Output::store32):
(JSC::FTL::Output::store64):
(JSC::FTL::Output::storePtr):
(JSC::FTL::Output::storeFloat):
(JSC::FTL::Output::storeDouble):
(JSC::FTL::Output::addPtr):
(JSC::FTL::Output::extractValue):
(JSC::FTL::Output::call):
(JSC::FTL::Output::operation):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutByVal):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArrayPush):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArrayPop):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::Output):
(JSC::FTL::Output::store):
(JSC::FTL::Output::check):
(JSC::FTL::Output::load):
* ftl/FTLOutput.h:
(JSC::FTL::Output::load32):
(JSC::FTL::Output::load64):
(JSC::FTL::Output::loadPtr):
(JSC::FTL::Output::loadFloat):
(JSC::FTL::Output::loadDouble):
(JSC::FTL::Output::store32As8):
(JSC::FTL::Output::store32As16):
(JSC::FTL::Output::store32):
(JSC::FTL::Output::store64):
(JSC::FTL::Output::storePtr):
(JSC::FTL::Output::storeFloat):
(JSC::FTL::Output::storeDouble):
(JSC::FTL::Output::addPtr):
(JSC::FTL::Output::loadFloatToDouble): Deleted.
(JSC::FTL::Output::store16): Deleted.
2015-12-10 Filip Pizlo <fpizlo@apple.com>
Consider still matching an address expression even if B3 has already assigned a Tmp to it
https://bugs.webkit.org/show_bug.cgi?id=150777
Reviewed by Geoffrey Garen.
We need some heuristic for when an address should be computed as a separate instruction. It's
usually profitable to sink the address into the memory access. The previous heuristic meant that
the address would get separate instructions if it was in a separate block from the memory access.
This was messing up codegen of things like PutByVal out-of-bounds, where the address is computed
in one block and then used in another. I don't think that which block owns the address
computation should factor into any heuristic here, since it's so fragile: the compiler may lower
something by splitting blocks and we don't want this to ruin performance.
So, this replaces that heuristic with a more sensible one: the address computation gets its own
instruction if it has a lot of uses. In practice this means that we always sink the address
computation into the memory access.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::effectiveAddr):
2015-12-10 Daniel Bates <dabates@apple.com>
[CSP] eval() is not blocked for stringified literals
https://bugs.webkit.org/show_bug.cgi?id=152158
<rdar://problem/15775625>
Reviewed by Saam Barati.
Fixes an issue where stringified literals can be eval()ed despite being disallowed by
Content Security Policy of the page.
* interpreter/Interpreter.cpp:
(JSC::eval): Throw a JavaScript EvalError exception if eval() is disallowed for the page
and return undefined.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval): Ditto.
2015-12-10 Joseph Pecoraro <pecoraro@apple.com>
Fix jsc symlink creation on iOS
https://bugs.webkit.org/show_bug.cgi?id=152155
Reviewed by Dan Bernstein.
* JavaScriptCore.xcodeproj/project.pbxproj:
Switch from INSTALL_PATH_ACTUAL to just INSTALL_PATH.
Remove now unnecessary INSTALL_PATH_PREFIX use as well.
2015-12-10 Joseph Pecoraro <pecoraro@apple.com>
Remote Inspector: Verify the identity of the other side of XPC connections
https://bugs.webkit.org/show_bug.cgi?id=152153
Reviewed by Brian Burg.
* JavaScriptCore.xcodeproj/project.pbxproj:
Link with the Security framework.
* inspector/remote/RemoteInspectorXPCConnection.h:
* inspector/remote/RemoteInspectorXPCConnection.mm:
(auditTokenHasEntitlement):
(Inspector::RemoteInspectorXPCConnection::handleEvent):
(Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection): Deleted.
When receiving the first message, verify the XPC connection
is connected to who we thought we were connected to and
Bail if it isn't.
2015-12-10 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add a Modulo operator to B3, and a chill variant
https://bugs.webkit.org/show_bug.cgi?id=152110
Reviewed by Geoffrey Garen.
It is basically refactoring the Div and ChillDiv
code to be used by both opcodes.
* b3/B3Common.h:
(JSC::B3::chillDiv):
(JSC::B3::chillMod):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::modConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::modConstant):
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::modConstant):
* b3/B3ConstDoubleValue.h:
* b3/B3LowerMacros.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::lowerX86Div):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::modConstant):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/testb3.cpp:
(JSC::B3::testModArgDouble):
(JSC::B3::testModArgsDouble):
(JSC::B3::testModArgImmDouble):
(JSC::B3::testModImmArgDouble):
(JSC::B3::testModImmsDouble):
(JSC::B3::testModArgFloat):
(JSC::B3::testModArgsFloat):
(JSC::B3::testModArgImmFloat):
(JSC::B3::testModImmArgFloat):
(JSC::B3::testModImmsFloat):
(JSC::B3::testModArg):
(JSC::B3::testModArgs):
(JSC::B3::testModImms):
(JSC::B3::testModArg32):
(JSC::B3::testModArgs32):
(JSC::B3::testModImms32):
(JSC::B3::testChillModArg):
(JSC::B3::testChillModArgs):
(JSC::B3::testChillModImms):
(JSC::B3::testChillModArg32):
(JSC::B3::testChillModArgs32):
(JSC::B3::testChillModImms32):
(JSC::B3::run):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::mod):
(JSC::FTL::Output::chillMod):
(JSC::FTL::Output::doubleMod):
(JSC::FTL::Output::rem): Deleted.
(JSC::FTL::Output::doubleRem): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMod):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::chillMod):
* ftl/FTLOutput.h:
(JSC::FTL::Output::mod):
(JSC::FTL::Output::doubleMod):
(JSC::FTL::Output::rem): Deleted.
(JSC::FTL::Output::doubleRem): Deleted.
2015-12-10 Csaba Osztrogonác <ossy@webkit.org>
[B3] Add new files to the cmake build system
https://bugs.webkit.org/show_bug.cgi?id=152120
Reviewed by Filip Pizlo.
* CMakeLists.txt:
2015-12-10 Csaba Osztrogonác <ossy@webkit.org>
[B3] Use mark pragmas only if it is supported
https://bugs.webkit.org/show_bug.cgi?id=152123
Reviewed by Mark Lam.
* ftl/FTLB3Output.h:
2015-12-10 Csaba Osztrogonác <ossy@webkit.org>
[B3] Typo fix in testb3.cpp
https://bugs.webkit.org/show_bug.cgi?id=152126
Reviewed by Mark Lam.
* b3/testb3.cpp:
(JSC::B3::populateWithInterestingValues):
2015-12-10 Csaba Osztrogonác <ossy@webkit.org>
[B3] Fix unused-but-set-variable warning
https://bugs.webkit.org/show_bug.cgi?id=152122
Reviewed by Mark Lam.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
2015-12-10 Csaba Osztrogonác <ossy@webkit.org>
[B3] Make GCC ignore warnings in FTLB3Output.h
https://bugs.webkit.org/show_bug.cgi?id=152124
Reviewed by Mark Lam.
* ftl/FTLB3Output.h:
2015-12-10 Csaba Osztrogonác <ossy@webkit.org>
[EFL] Remove the unused IncrementalSweeper::m_isTimerFrozen member after r193749
https://bugs.webkit.org/show_bug.cgi?id=152127
Reviewed by Mark Lam.
* heap/IncrementalSweeper.h:
2015-12-10 Csaba Osztrogonác <ossy@webkit.org>
Source/JavaScriptCore/create_hash_table shouldn't be too verbose
https://bugs.webkit.org/show_bug.cgi?id=151861
Reviewed by Darin Adler.
* create_hash_table:
2015-12-10 Youenn Fablet <youenn.fablet@crf.canon.fr>
JSC Builtins should use safe array methods
https://bugs.webkit.org/show_bug.cgi?id=151501
Reviewed by Darin Adler.
Adding @push and @shift to Array prototype.
Using @push in TypedArray built-in.
Covered by added test in LayoutTests/js/builtins
* builtins/TypedArray.prototype.js:
(filter):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* runtime/CommonIdentifiers.h:
2015-12-08 Filip Pizlo <fpizlo@apple.com>
FTL B3 should have basic GetById support
https://bugs.webkit.org/show_bug.cgi?id=152035
Reviewed by Saam Barati.
Adds basic GetById support. This was so easy to do. Unlike the LLVM code for this, the B3 code is
entirely self-contained within the getById() method in LowerDFG.
I discovered that we weren't folding Check(NotEqual(x, 0)) to Check(x). This was preventing us
from generating good code for Check(NotEqual(BitAnd(x, tagMask), 0)), since the BitAnd was
concealed. This was an easy strength reduction rule to add.
Finally, I found it easier to say append(value, rep) than append(ConstrainedValue(value, rep)), so
I added that API. The old ConstrainedValue form is still super useful in other places, like
compileCallOrConstruct(), where the two-argument form would be awkward. It's great to have both
APIs to pick from.
* b3/B3ReduceStrength.cpp:
* b3/B3StackmapValue.cpp:
(JSC::B3::StackmapValue::~StackmapValue):
(JSC::B3::StackmapValue::append):
* b3/B3StackmapValue.h:
* dfg/DFGCommon.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
2015-12-09 Saam barati <sbarati@apple.com>
Update generators' features.json to indicate that we have a spec compliant implementation
https://bugs.webkit.org/show_bug.cgi?id=152085
Reviewed by Joseph Pecoraro.
* features.json:
2015-12-09 Saam barati <sbarati@apple.com>
Update features.json w.r.t tail calls
https://bugs.webkit.org/show_bug.cgi?id=152072
Reviewed by Michael Saboff.
* features.json:
2015-12-09 Saam barati <sbarati@apple.com>
we should emit op_watchdog after op_enter
https://bugs.webkit.org/show_bug.cgi?id=151972
Reviewed by Mark Lam.
This also solves the issue of watchdog not being
observed when we loop purely through tail calls.
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitProfiledOpcode):
(JSC::BytecodeGenerator::emitEnter):
(JSC::BytecodeGenerator::emitLoopHint):
* bytecompiler/BytecodeGenerator.h:
2015-12-08 Benjamin Poulain <bpoulain@apple.com>
[JSC] Improve how B3 lowers Add() and Sub() on x86
https://bugs.webkit.org/show_bug.cgi?id=152026
Reviewed by Geoffrey Garen.
The assembler was missing some important x86 forms of
ADD and SUB that were making our lowering
unfriendly with register allocation.
First, we were missing a 3 operand version of Add
implement with LEA. As a result, an Add would
be lowered as:
Move op1->srcDest
Add op2, srcDest
The problem with such code is that op2 and srcDest
interferes. It is impossible to assign them the same
machine register.
With the new Add form, we have:
Add op1, op2, dest
without interferences between any of those values.
The add is implement by a LEA without scaling or displacement.
This patch also adds missing forms of Add and Sub with
direct addressing for arguments. This avoids dealing with Tmps
that only exist for those operations.
Finally, the lowering of adding something to itself was updated accordingly.
Such operation is transformed in Shl by 2. The lowering of Shl
was adding an explicit Move, preventing the use of LEA when it
is useful.
Instead of having an explicit move, I changed the direct addressing
forms to only be selected if the two operands are different.
A Move is then added by appendBinOp() if needed.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::add32):
(JSC::MacroAssemblerX86Common::x86Lea32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::add64):
(JSC::MacroAssemblerX86_64::x86Lea64):
(JSC::MacroAssemblerX86_64::sub64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::addq_rm):
(JSC::X86Assembler::subq_mr):
(JSC::X86Assembler::subq_rm):
(JSC::X86Assembler::subq_im):
(JSC::X86Assembler::leal_mr):
(JSC::X86Assembler::leaq_mr):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testAddArgMem):
(JSC::B3::testAddMemArg):
(JSC::B3::testAddImmMem):
(JSC::B3::testAddArg32):
(JSC::B3::testAddArgMem32):
(JSC::B3::testAddMemArg32):
(JSC::B3::testAddImmMem32):
(JSC::B3::testSubArgMem):
(JSC::B3::testSubMemArg):
(JSC::B3::testSubImmMem):
(JSC::B3::testSubMemImm):
(JSC::B3::testSubMemArg32):
(JSC::B3::testSubArgMem32):
(JSC::B3::testSubImmMem32):
(JSC::B3::testSubMemImm32):
(JSC::B3::run):
2015-12-08 Mark Lam <mark.lam@apple.com>
Factoring out common DFG code for bitwise and shift operators.
https://bugs.webkit.org/show_bug.cgi?id=152019
Reviewed by Michael Saboff.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileBitwiseOp):
(JSC::DFG::SpeculativeJIT::compileShiftOp):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2015-12-08 Mark Lam <mark.lam@apple.com>
DFG and FTL should be resilient against cases where both snippet operands are constant.
https://bugs.webkit.org/show_bug.cgi?id=152017
Reviewed by Michael Saboff.
The DFG front end may not always constant fold cases where both operands are
constant. As a result, the DFG and FTL back ends needs to be resilient against
this when using snippet generators since the generators do not support the case
where both operands are constant. The strategy for handling this 2 const operands
case is to treat at least one of them as a variable if both are constant.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
- Also remove the case for folding 2 constant operands. It is the front end's
job to do so, not the back end here.
(JSC::DFG::SpeculativeJIT::compileArithSub):
(JSC::DFG::SpeculativeJIT::compileArithMul):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
2015-12-08 Mark Lam <mark.lam@apple.com>
Snippefy shift operators for the baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=151875
Reviewed by Geoffrey Garen.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emitBitBinaryOpFastPath):
- Don't need GPRInfo:: qualifiers. Removed them to reduce verbosity.
- Also removed the emitStoreInt32() case for storing the result on 32-bit ports.
This is because:
1. The client should not make assumptions about whether the snippet fast path
only include cases where the result tag already contain the IntTag.
2. The "(op1 == result || op2 == result)" condition for skipping the IntTag
storage, is only valid for the bitand, bitor, and bitxor implementations.
It is invalid for the lshift implementation that uses this code now.
Instead, we'll always unconditionally store what the result tag that the
snippet computed for us.
(JSC::JIT::emit_op_lshift):
(JSC::JIT::emitSlow_op_lshift):
(JSC::JIT::emitRightShiftFastPath):
(JSC::JIT::emit_op_rshift):
(JSC::JIT::emitSlow_op_rshift):
(JSC::JIT::emit_op_urshift):
(JSC::JIT::emitSlow_op_urshift):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_op_lshift): Deleted.
(JSC::JIT::emitSlow_op_lshift): Deleted.
(JSC::JIT::emitRightShift): Deleted.
(JSC::JIT::emitRightShiftSlowCase): Deleted.
(JSC::JIT::emit_op_rshift): Deleted.
(JSC::JIT::emitSlow_op_rshift): Deleted.
(JSC::JIT::emit_op_urshift): Deleted.
(JSC::JIT::emitSlow_op_urshift): Deleted.
* jit/JITLeftShiftGenerator.cpp: Added.
(JSC::JITLeftShiftGenerator::generateFastPath):
* jit/JITLeftShiftGenerator.h: Added.
(JSC::JITLeftShiftGenerator::JITLeftShiftGenerator):
* jit/JITRightShiftGenerator.cpp: Added.
(JSC::JITRightShiftGenerator::generateFastPath):
* jit/JITRightShiftGenerator.h: Added.
(JSC::JITRightShiftGenerator::JITRightShiftGenerator):
* tests/stress/op_lshift.js:
* tests/stress/op_rshift.js:
* tests/stress/op_urshift.js:
- Fixed some values and added others that are meaningful for testing shifts.
* tests/stress/resources/binary-op-test.js:
(stringifyIfNeeded):
(generateBinaryTests):
- Fixed the test generator to give unique names to all the generated test
functions. Without this, multiple tests may end up using the same global
test function. As a result, with enough test values to test, the function may
get prematurely JITted, and the computed expected result which is supposed to
be computed by the LLINT, may end up being computed by a JIT instead.
2015-12-08 Joseph Pecoraro <pecoraro@apple.com>
Create a Sandbox SPI header
https://bugs.webkit.org/show_bug.cgi?id=151981
Reviewed by Andy Estes.
* inspector/remote/RemoteInspector.mm:
2015-12-08 Filip Pizlo <fpizlo@apple.com>
DFG::UnificationPhase should merge isProfitableToUnbox, since this may have been set in ByteCodeParser
https://bugs.webkit.org/show_bug.cgi?id=152011
rdar://problem/23777875
Reviewed by Michael Saboff.
Previously UnificationPhase did not merge this because we used to only set this in FixupPhase, which runs after unification. But now
ByteCodeParser may set isProfitableToUnbox as part of how it handles the ArgumentCount of an inlined varargs call, so UnificationPhase
needs to merge it after unifying.
Also changed the order of unification since this makes the bug more obvious and easier to test.
* dfg/DFGUnificationPhase.cpp:
(JSC::DFG::UnificationPhase::run):
* tests/stress/varargs-with-unused-count.js: Added.
2015-12-08 Mark Lam <mark.lam@apple.com>
Polymorphic operand types for DFG and FTL div.
https://bugs.webkit.org/show_bug.cgi?id=151747
Reviewed by Geoffrey Garen.
Perf on benchmarks is neutral. The new JSRegress ftl-object-div test shows
a speed up not from the div operator itself, but from the fact that the
polymorphic operand types support now allow the test function to run without OSR
exiting, thereby realizing the DFG and FTL's speed up on other work that the test
function does.
This patch has passed the layout tests on x86_64 with a debug build.
It passed the JSC tests with x86 and x86_64 debug builds.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithDiv):
* ftl/FTLCompileBinaryOp.cpp:
(JSC::FTL::generateBinaryArithOpFastPath):
(JSC::FTL::generateBinaryOpFastPath):
* ftl/FTLInlineCacheDescriptor.h:
* ftl/FTLInlineCacheDescriptorInlines.h:
(JSC::FTL::ArithDivDescriptor::ArithDivDescriptor):
(JSC::FTL::ArithDivDescriptor::icSize):
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfArithDiv):
* ftl/FTLInlineCacheSize.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
- Fixed a cut-paste bug where the op_mul IC was using the op_sub IC size.
This bug is benign because the op_sub IC size turns out to be larger
than op_mul needs.
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_div):
- Fixed a bug where the scratchFPR was not allocated for the 64bit port.
This bug is benign because the scratchFPR is only needed if we are
using scratchGPR register (used for branchConvertDoubleToInt32()) is
>= X86Registers::r8. Since we're always using regT2 for the scratchT2,
the scratchFPR is never needed. However, we should fix this anyway to
be correct.
* tests/stress/op_div.js:
- Fixed some test values.
2015-12-05 Aleksandr Skachkov <gskachkov@gmail.com>
[ES6] "super" and "this" should be lexically bound inside an arrow function and should live in a JSLexicalEnvironment
https://bugs.webkit.org/show_bug.cgi?id=149338
Reviewed by Saam Barati.
Implemented new version of the lexically bound 'this' in arrow function. In current version
'this' is stored inside of the lexical environment of the function. To store and load we use
op_get_from_scope and op_put_to_scope operations. Also new implementation prevent raising TDZ
error for arrow functions that are declared before super() but invoke after.
* builtins/BuiltinExecutables.cpp:
(JSC::createExecutableInternal):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::getSlow):
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::isDerivedConstructorContext):
(JSC::ExecutableInfo::isArrowFunctionContext):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::isArrowFunction):
(JSC::UnlinkedCodeBlock::isDerivedConstructorContext):
(JSC::UnlinkedCodeBlock::isArrowFunctionContext):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
(JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
(JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
(JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::isDerivedConstructorContext):
(JSC::BytecodeGenerator::usesArrowFunction):
(JSC::BytecodeGenerator::needsToUpdateArrowFunctionContext):
(JSC::BytecodeGenerator::usesEval):
(JSC::BytecodeGenerator::usesThis):
(JSC::BytecodeGenerator::newTarget):
(JSC::BytecodeGenerator::makeFunction):
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
(JSC::SuperNode::emitBytecode):
(JSC::EvalFunctionCallNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluate):
* dfg/DFGAbstractInterpreterInlines.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
* dfg/DFGClobberize.h:
* dfg/DFGDoesGC.cpp:
* dfg/DFGFixupPhase.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGPromotedHeapLocation.cpp:
* dfg/DFGPromotedHeapLocation.h:
* dfg/DFGSafeToExecute.h:
* dfg/DFGSpeculativeJIT.cpp:
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
* dfg/DFGSpeculativeJIT64.cpp:
* ftl/FTLCapabilities.cpp:
* ftl/FTLLowerDFGToLLVM.cpp:
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* interpreter/Interpreter.cpp:
(JSC::eval):
* jit/JIT.cpp:
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emitNewFuncExprCommon):
* jit/JITOpcodes32_64.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createArrowFunctionExpr):
(JSC::ASTBuilder::usesArrowFunction):
* parser/Nodes.h:
(JSC::ScopeNode::usesArrowFunction):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/ParserModes.h:
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getModuleProgramCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/CommonIdentifiers.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::EvalExecutable::create):
(JSC::EvalExecutable::EvalExecutable):
(JSC::ProgramExecutable::ProgramExecutable):
(JSC::ModuleProgramExecutable::ModuleProgramExecutable):
(JSC::FunctionExecutable::FunctionExecutable):
* runtime/Executable.h:
(JSC::ScriptExecutable::isArrowFunctionContext):
(JSC::ScriptExecutable::isDerivedConstructorContext):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createEvalCodeBlock):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* tests/es6.yaml:
* tests/stress/arrowfunction-activation-sink-osrexit.js:
* tests/stress/arrowfunction-activation-sink.js:
* tests/stress/arrowfunction-lexical-bind-newtarget.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-1.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-2.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-3.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-4.js: Added.
* tests/stress/arrowfunction-lexical-bind-this-1.js:
* tests/stress/arrowfunction-lexical-bind-this-7.js: Added.
* tests/stress/arrowfunction-tdz-1.js: Added.
* tests/stress/arrowfunction-tdz-2.js: Added.
* tests/stress/arrowfunction-tdz-3.js: Added.
* tests/stress/arrowfunction-tdz-4.js: Added.
* tests/stress/arrowfunction-tdz.js: Removed.
2015-12-08 Csaba Osztrogonác <ossy@webkit.org>
Fix the !ENABLE(DFG_JIT) build after r193649
https://bugs.webkit.org/show_bug.cgi?id=151985
Reviewed by Saam Barati.
* jit/JITOpcodes.cpp:
(JSC::JIT::emitSlow_op_loop_hint):
2015-12-08 Alberto Garcia <berto@igalia.com>
Unreviewed. Remove unnecessary check for 0 in commitSize().
Change suggested by Darin Adler in bug #130237.
* interpreter/JSStack.cpp:
(JSC::commitSize):
2015-12-08 Ryuan Choi <ryuan.choi@navercorp.com>
[EFL] Remove the flag to check timer state in IncrementalSweeper
https://bugs.webkit.org/show_bug.cgi?id=151988
Reviewed by Gyuyoung Kim.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::scheduleTimer):
(JSC::IncrementalSweeper::IncrementalSweeper):
(JSC::IncrementalSweeper::cancelTimer):
2015-12-08 Philippe Normand <pnormand@igalia.com>
[Mac][GTK] Fix JSC FTL build
https://bugs.webkit.org/show_bug.cgi?id=151915
Reviewed by Csaba Osztrogonác.
* CMakeLists.txt: Don't pass version-script option to ld on Darwin because this platform's linker
doesn't support this option.
2015-12-08 Alberto Garcia <berto@igalia.com>
Unreviewed. Use pageSize() instead of getpagesize() after r193648
* interpreter/JSStack.cpp:
(JSC::commitSize):
2015-12-07 Filip Pizlo <fpizlo@apple.com>
Small style fixes in B3MoveConstants.cpp
https://bugs.webkit.org/show_bug.cgi?id=151980
Reviewed by Benjamin Poulain.
* b3/B3MoveConstants.cpp:
2015-12-07 Benjamin Poulain <bpoulain@apple.com>
[JSC] On x86, we should XOR registers instead of moving a zero immediate
https://bugs.webkit.org/show_bug.cgi?id=151977
Reviewed by Filip Pizlo.
It is smaller and the frontend has special support
for xor.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::move):
(JSC::MacroAssemblerX86Common::signExtend32ToPtr):
2015-12-07 Benjamin Poulain <bpoulain@apple.com>
Fix a typo from r193683
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
2015-12-07 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add Float support to B3
https://bugs.webkit.org/show_bug.cgi?id=151974
Reviewed by Filip Pizlo.
This patch adds comprehensive float support to B3.
The new phase reduceDoubleToFloat() gives us a primitive
version of what LLVM was giving us on floats.
It needs to support conversions accross Phis but that can
be added later.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::moveDoubleConditionallyFloat):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::sqrtFloat):
(JSC::MacroAssemblerX86Common::loadFloat):
(JSC::MacroAssemblerX86Common::storeFloat):
(JSC::MacroAssemblerX86Common::convertDoubleToFloat):
(JSC::MacroAssemblerX86Common::convertFloatToDouble):
(JSC::MacroAssemblerX86Common::addFloat):
(JSC::MacroAssemblerX86Common::divFloat):
(JSC::MacroAssemblerX86Common::subFloat):
(JSC::MacroAssemblerX86Common::mulFloat):
(JSC::MacroAssemblerX86Common::branchDouble):
(JSC::MacroAssemblerX86Common::branchFloat):
(JSC::MacroAssemblerX86Common::moveConditionallyDouble):
(JSC::MacroAssemblerX86Common::moveConditionallyFloat):
(JSC::MacroAssemblerX86Common::jumpAfterFloatingPointCompare):
(JSC::MacroAssemblerX86Common::moveConditionallyAfterFloatingPointCompare):
* assembler/X86Assembler.h:
(JSC::X86Assembler::addss_rr):
(JSC::X86Assembler::addss_mr):
(JSC::X86Assembler::cvtsd2ss_mr):
(JSC::X86Assembler::cvtss2sd_mr):
(JSC::X86Assembler::movss_rm):
(JSC::X86Assembler::movss_mr):
(JSC::X86Assembler::mulss_rr):
(JSC::X86Assembler::mulss_mr):
(JSC::X86Assembler::subss_rr):
(JSC::X86Assembler::subss_mr):
(JSC::X86Assembler::ucomiss_rr):
(JSC::X86Assembler::ucomiss_mr):
(JSC::X86Assembler::divss_rr):
(JSC::X86Assembler::divss_mr):
(JSC::X86Assembler::sqrtss_rr):
(JSC::X86Assembler::sqrtss_mr):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::bitwiseCastConstant):
* b3/B3Const32Value.h:
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::doubleToFloatConstant):
(JSC::B3::ConstDoubleValue::sqrtConstant):
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.cpp: Added.
(JSC::B3::ConstFloatValue::~ConstFloatValue):
(JSC::B3::ConstFloatValue::negConstant):
(JSC::B3::ConstFloatValue::addConstant):
(JSC::B3::ConstFloatValue::subConstant):
(JSC::B3::ConstFloatValue::mulConstant):
(JSC::B3::ConstFloatValue::bitwiseCastConstant):
(JSC::B3::ConstFloatValue::floatToDoubleConstant):
(JSC::B3::ConstFloatValue::sqrtConstant):
(JSC::B3::ConstFloatValue::divConstant):
(JSC::B3::ConstFloatValue::equalConstant):
(JSC::B3::ConstFloatValue::notEqualConstant):
(JSC::B3::ConstFloatValue::lessThanConstant):
(JSC::B3::ConstFloatValue::greaterThanConstant):
(JSC::B3::ConstFloatValue::lessEqualConstant):
(JSC::B3::ConstFloatValue::greaterEqualConstant):
(JSC::B3::ConstFloatValue::dumpMeta):
* b3/B3ConstFloatValue.h: Copied from Source/JavaScriptCore/b3/B3ConstDoubleValue.h.
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tryOpcodeForType):
(JSC::B3::Air::LowerToAir::opcodeForType):
(JSC::B3::Air::LowerToAir::appendUnOp):
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::appendShift):
(JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::moveForType):
(JSC::B3::Air::LowerToAir::relaxedMoveForType):
(JSC::B3::Air::LowerToAir::createGenericCompare):
(JSC::B3::Air::LowerToAir::createBranch):
(JSC::B3::Air::LowerToAir::createCompare):
(JSC::B3::Air::LowerToAir::createSelect):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3MemoryValue.cpp:
(JSC::B3::MemoryValue::accessByteSize): Deleted.
* b3/B3MemoryValue.h:
* b3/B3MoveConstants.cpp:
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addIntConstant):
* b3/B3ReduceDoubleToFloat.cpp: Added.
(JSC::B3::reduceDoubleToFloat):
* b3/B3ReduceDoubleToFloat.h: Copied from Source/JavaScriptCore/b3/B3Type.cpp.
* b3/B3ReduceStrength.cpp:
* b3/B3Type.cpp:
(WTF::printInternal):
* b3/B3Type.h:
(JSC::B3::isFloat):
(JSC::B3::sizeofType):
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::doubleToFloatConstant):
(JSC::B3::Value::floatToDoubleConstant):
(JSC::B3::Value::sqrtConstant):
(JSC::B3::Value::asTriState):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::checkOpcode):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/B3ValueInlines.h:
(JSC::B3::Value::isConstant):
(JSC::B3::Value::hasFloat):
(JSC::B3::Value::asFloat):
(JSC::B3::Value::hasNumber):
(JSC::B3::Value::isNegativeZero):
(JSC::B3::Value::representableAs):
(JSC::B3::Value::asNumber):
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::materialize):
* b3/B3ValueKey.h:
(JSC::B3::ValueKey::ValueKey):
(JSC::B3::ValueKey::floatValue):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::typeForB3Type):
(JSC::B3::Air::Arg::widthForB3Type):
* b3/air/AirFixPartialRegisterStalls.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testAddArgFloat):
(JSC::B3::testAddArgsFloat):
(JSC::B3::testAddArgImmFloat):
(JSC::B3::testAddImmArgFloat):
(JSC::B3::testAddImmsFloat):
(JSC::B3::testAddArgFloatWithUselessDoubleConversion):
(JSC::B3::testAddArgsFloatWithUselessDoubleConversion):
(JSC::B3::testAddArgsFloatWithEffectfulDoubleConversion):
(JSC::B3::testMulArgFloat):
(JSC::B3::testMulArgsFloat):
(JSC::B3::testMulArgImmFloat):
(JSC::B3::testMulImmArgFloat):
(JSC::B3::testMulImmsFloat):
(JSC::B3::testMulArgFloatWithUselessDoubleConversion):
(JSC::B3::testMulArgsFloatWithUselessDoubleConversion):
(JSC::B3::testMulArgsFloatWithEffectfulDoubleConversion):
(JSC::B3::testDivArgFloat):
(JSC::B3::testDivArgsFloat):
(JSC::B3::testDivArgImmFloat):
(JSC::B3::testDivImmArgFloat):
(JSC::B3::testDivImmsFloat):
(JSC::B3::testDivArgFloatWithUselessDoubleConversion):
(JSC::B3::testDivArgsFloatWithUselessDoubleConversion):
(JSC::B3::testDivArgsFloatWithEffectfulDoubleConversion):
(JSC::B3::testSubArgFloat):
(JSC::B3::testSubArgsFloat):
(JSC::B3::testSubArgImmFloat):
(JSC::B3::testSubImmArgFloat):
(JSC::B3::testSubImmsFloat):
(JSC::B3::testSubArgFloatWithUselessDoubleConversion):
(JSC::B3::testSubArgsFloatWithUselessDoubleConversion):
(JSC::B3::testSubArgsFloatWithEffectfulDoubleConversion):
(JSC::B3::testClzMem32):
(JSC::B3::testSqrtArg):
(JSC::B3::testSqrtImm):
(JSC::B3::testSqrtMem):
(JSC::B3::testSqrtArgWithUselessDoubleConversion):
(JSC::B3::testSqrtArgWithEffectfulDoubleConversion):
(JSC::B3::testDoubleArgToInt64BitwiseCast):
(JSC::B3::testDoubleImmToInt64BitwiseCast):
(JSC::B3::testTwoBitwiseCastOnDouble):
(JSC::B3::testBitwiseCastOnDoubleInMemory):
(JSC::B3::testInt64BArgToDoubleBitwiseCast):
(JSC::B3::testInt64BImmToDoubleBitwiseCast):
(JSC::B3::testTwoBitwiseCastOnInt64):
(JSC::B3::testBitwiseCastOnInt64InMemory):
(JSC::B3::testFloatImmToInt32BitwiseCast):
(JSC::B3::testBitwiseCastOnFloatInMemory):
(JSC::B3::testInt32BArgToFloatBitwiseCast):
(JSC::B3::testInt32BImmToFloatBitwiseCast):
(JSC::B3::testTwoBitwiseCastOnInt32):
(JSC::B3::testBitwiseCastOnInt32InMemory):
(JSC::B3::testConvertDoubleToFloatArg):
(JSC::B3::testConvertDoubleToFloatImm):
(JSC::B3::testConvertDoubleToFloatMem):
(JSC::B3::testConvertFloatToDoubleArg):
(JSC::B3::testConvertFloatToDoubleImm):
(JSC::B3::testConvertFloatToDoubleMem):
(JSC::B3::testConvertDoubleToFloatToDoubleToFloat):
(JSC::B3::testLoadFloatConvertDoubleConvertFloatStoreFloat):
(JSC::B3::testFroundArg):
(JSC::B3::testFroundMem):
(JSC::B3::testStore32):
(JSC::B3::modelLoad):
(JSC::B3::float>):
(JSC::B3::double>):
(JSC::B3::testLoad):
(JSC::B3::testStoreFloat):
(JSC::B3::testReturnFloat):
(JSC::B3::simpleFunctionFloat):
(JSC::B3::testCallSimpleFloat):
(JSC::B3::functionWithHellaFloatArguments):
(JSC::B3::testCallFunctionWithHellaFloatArguments):
(JSC::B3::testSelectCompareFloat):
(JSC::B3::testSelectCompareFloatToDouble):
(JSC::B3::testSelectDoubleCompareFloat):
(JSC::B3::testSelectFloatCompareFloat):
(JSC::B3::populateWithInterestingValues):
(JSC::B3::floatingPointOperands):
(JSC::B3::int64Operands):
(JSC::B3::run):
(JSC::B3::testStore): Deleted.
(JSC::B3::posInfinity): Deleted.
(JSC::B3::negInfinity): Deleted.
(JSC::B3::doubleOperands): Deleted.
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::loadFloatToDouble):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::fround):
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
* ftl/FTLCommonValues.h:
2015-12-07 Filip Pizlo <fpizlo@apple.com>
FTL B3 should be able to flag the tag constants as being super important so that B3 can hoist them and Air can force them into registers
https://bugs.webkit.org/show_bug.cgi?id=151955
Reviewed by Geoffrey Garen.
Taught B3 about the concept of "fast constants". A client of B3 can now tell B3 which
constants are super important. B3 will not spill the constant in that case and will ensure
that the constant is materialized only once: statically once, and dynamically once per
procedure execution. The hoistFastConstants() algorithm in B3MoveConstants.cpp achieves this
by first picking the lowest common dominator of all uses of each fast constant, and then
picking the materialization point by finding the lowest dominator of that dominator that is
tied for lowest block frequency. In practice, the second step ensures that this is the lowest
point in the program that is not in a loop (i.e. executes no more than once dynamically per
procedure invocation).
Taught Air about the concept of "fast tmps". B3 tells Air that a tmp is fast if it is used to
hold the materialization of a fast constant. IRC will use the lowest possible spill score for
fast tmps. In practice, this ensures that fast constants are never spilled.
Added a small snippet of code to FTL::LowerDFGToLLVM that makes both of the tag constants
into fast constants.
My hope is that this very brute-force heuristic is good enough that we don't have to think
about constants for a while. Based on my experience with how LLVM's constant hoisting works
out, the heuristic in this patch is going to be tough to beat. LLVM's constant hoisting does
good things when it hoists the tags, and usually causes nothing but problems when it hoists
anything else. This is because there is no way a low-level compiler to really understand how
a constant materialization impacts some operation's contribution to the overall execution
time of a procedure. But, in the FTL we know that constant materializations for type checks
are a bummer because we are super comfortable placing type checks on the hottest of paths. So
those are the last paths where extra instructions should be added by the compiler. On the
other hand, all other large constant uses are on relatively cold paths, or paths that are
already expensive for other reasons. For example, global variable accesses have to
materialize a pointer to the global. But that's not really a big deal, since a load from a
global involves first the load itself and then type checks on the result - so probably the
constant materialization is just not interesting. A store to a global often involves a store
barrier, so the constant materialization is really not interesting. This patch codifies this
heuristic in a pact between Air, B3, and the FTL: FTL demands that B3 pin the two tags in
registers, and B3 relays the demand to Air.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3CFG.h: Added.
(JSC::B3::CFG::CFG):
(JSC::B3::CFG::root):
(JSC::B3::CFG::newMap):
(JSC::B3::CFG::successors):
(JSC::B3::CFG::predecessors):
(JSC::B3::CFG::index):
(JSC::B3::CFG::node):
(JSC::B3::CFG::numNodes):
(JSC::B3::CFG::dump):
* b3/B3Dominators.h: Added.
(JSC::B3::Dominators::Dominators):
* b3/B3IndexMap.h:
(JSC::B3::IndexMap::resize):
(JSC::B3::IndexMap::size):
(JSC::B3::IndexMap::operator[]):
* b3/B3LowerMacros.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tmp):
* b3/B3MoveConstants.cpp:
* b3/B3Opcode.h:
(JSC::B3::constPtrOpcode):
(JSC::B3::isConstant):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::Procedure):
(JSC::B3::Procedure::resetReachability):
(JSC::B3::Procedure::invalidateCFG):
(JSC::B3::Procedure::dump):
(JSC::B3::Procedure::deleteValue):
(JSC::B3::Procedure::dominators):
(JSC::B3::Procedure::addFastConstant):
(JSC::B3::Procedure::isFastConstant):
(JSC::B3::Procedure::addDataSection):
* b3/B3Procedure.h:
(JSC::B3::Procedure::size):
(JSC::B3::Procedure::cfg):
(JSC::B3::Procedure::setLastPhaseName):
* b3/B3ReduceStrength.cpp:
* b3/B3ValueInlines.h:
(JSC::B3::Value::isConstant):
(JSC::B3::Value::isInteger):
* b3/B3ValueKey.h:
(JSC::B3::ValueKey::canMaterialize):
(JSC::B3::ValueKey::isConstant):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::findNextBlock):
(JSC::B3::Air::Code::addFastTmp):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::specials):
(JSC::B3::Air::Code::isFastTmp):
(JSC::B3::Air::Code::setLastPhaseName):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* dfg/DFGDominators.h:
* dfg/DFGSSACalculator.cpp:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
2015-12-07 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement String.prototype.toLocaleUpperCase in ECMA-402
https://bugs.webkit.org/show_bug.cgi?id=147609
Reviewed by Benjamin Poulain.
Refactor most of toLocaleLowerCase to static function used by both
toLocaleUpperCase and toLocaleLowerCase.
Add toLocaleUpperCase using icu u_strToUpper.
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::toLocaleCase):
(JSC::stringProtoFuncToLocaleLowerCase):
(JSC::stringProtoFuncToLocaleUpperCase):
2015-12-07 Michael Saboff <msaboff@apple.com>
CRASH: CodeBlock::setOptimizationThresholdBasedOnCompilationResult + 567
https://bugs.webkit.org/show_bug.cgi?id=151892
Reviewed by Geoffrey Garen.
Reverted the change made in change set r193491.
The updated change is to finish all concurrent compilations and install the resulting
code blocks before we make any state changes due to debugger activity. After all code
blocks have been installed, we make the debugger state changes, including jettisoning
all optimized code blocks.
This means that we will discard the optimized code blocks we just installed,
but we won't do that while on the install code block path.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult): Reverted r193491.
* debugger/Debugger.cpp:
(JSC::Debugger::setSteppingMode):
(JSC::Debugger::registerCodeBlock):
(JSC::Debugger::toggleBreakpoint):
(JSC::Debugger::clearBreakpoints):
(JSC::Debugger::clearDebuggerRequests):
Call Heap::completeAllDFGPlans() before updating code blocks for debugging changes.
* heap/Heap.h: Made completeAllDFGPlans() public.
2015-12-07 Filip Pizlo <fpizlo@apple.com>
FTL lowering should tell B3 the right block frequencies
https://bugs.webkit.org/show_bug.cgi?id=151531
Reviewed by Geoffrey Garen.
This glues together the DFG's view of basic block execution counts and B3's block frequencies.
This further improves our performance on imaging-gaussian-blur. It appears to improve the steady
state throughput by almost 4%.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::setFrequency):
(JSC::FTL::Output::newBlock):
(JSC::FTL::Output::insertNewBlocksBefore):
(JSC::FTL::Output::callWithoutSideEffects):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBlock):
* ftl/FTLOutput.h:
(JSC::FTL::Output::setFrequency):
(JSC::FTL::Output::insertNewBlocksBefore):
2015-12-07 Saam barati <sbarati@apple.com>
Update JSC feature list for rest parameters and generators
https://bugs.webkit.org/show_bug.cgi?id=151740
Reviewed by Joseph Pecoraro.
* features.json:
2015-12-07 Filip Pizlo <fpizlo@apple.com>
DFG ASSERTION FAILED: m_plan.weakReferences.contains(structure).
https://bugs.webkit.org/show_bug.cgi?id=151952
Reviewed by Mark Lam.
Fix a bug revealed by the new ftl-has-a-bad-time.js test. It turns out that our handling of
structures reachable from the compiler wasn't accounting for having a bad time.
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
2015-12-07 Saam barati <sbarati@apple.com>
Add op_watchdog opcode that is generated when VM has a watchdog
https://bugs.webkit.org/show_bug.cgi?id=151954
Reviewed by Mark Lam.
This patch also makes watchdog a private member
of VM and adds a getter function.
* API/JSContextRef.cpp:
(JSContextGroupClearExecutionTimeLimit):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitLoopHint):
(JSC::BytecodeGenerator::emitWatchdog):
(JSC::BytecodeGenerator::retrieveLastBinaryOp):
* bytecompiler/BytecodeGenerator.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emit_op_watchdog):
(JSC::JIT::emitSlow_op_watchdog):
(JSC::JIT::emit_op_new_regexp):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* runtime/VM.cpp:
(JSC::VM::ensureWatchdog):
* runtime/VM.h:
(JSC::VM::watchdog):
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
(JSC::VMEntryScope::~VMEntryScope):
* runtime/VMInlines.h:
(JSC::VM::shouldTriggerTermination):
2015-12-07 Alberto Garcia <berto@igalia.com>
Crashes on PPC64 due to mprotect() on address not aligned to the page size
https://bugs.webkit.org/show_bug.cgi?id=130237
Reviewed by Mark Lam.
Make sure that commitSize is at least as big as the page size.
* interpreter/JSStack.cpp:
(JSC::commitSize):
(JSC::JSStack::JSStack):
(JSC::JSStack::growSlowCase):
* interpreter/JSStack.h:
2015-12-06 Filip Pizlo <fpizlo@apple.com>
FTL B3 should be able to make JS->JS calls
https://bugs.webkit.org/show_bug.cgi?id=151901
Reviewed by Saam Barati.
This adds support for the Call and InvalidationPoint opcodes in DFG IR. This required doing some
clean-up in the OSR exit code. We don't want the B3 FTL to use a bunch of vectors to hold
side-state, so the use of OSRExitDescriptorImpl is not right. It makes sense in the LLVM FTL
because that code needs some way of saving some state from LowerDFGToLLVM to compile(), but
that's not how B3 FTL works. It turns out that for B3 FTL, there isn't anything in
OSRExitDescriptorImpl that the code in LowerDFGToLLVM can't just capture in a lambda.
This also simplifies some stackmap-related APIs, since I got tired of writing boilerplate.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::replaceWithAddressComputation):
(JSC::AbstractMacroAssembler::addLinkTask):
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::generate):
* b3/B3Effects.h:
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::generate):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addDataSection):
(JSC::B3::Procedure::callArgAreaSize):
(JSC::B3::Procedure::requestCallArgAreaSize):
(JSC::B3::Procedure::frameSize):
* b3/B3Procedure.h:
(JSC::B3::Procedure::releaseByproducts):
(JSC::B3::Procedure::code):
* b3/B3StackmapGenerationParams.cpp: Added.
(JSC::B3::StackmapGenerationParams::usedRegisters):
(JSC::B3::StackmapGenerationParams::proc):
(JSC::B3::StackmapGenerationParams::StackmapGenerationParams):
* b3/B3StackmapGenerationParams.h: Added.
(JSC::B3::StackmapGenerationParams::value):
(JSC::B3::StackmapGenerationParams::reps):
(JSC::B3::StackmapGenerationParams::size):
(JSC::B3::StackmapGenerationParams::at):
(JSC::B3::StackmapGenerationParams::operator[]):
(JSC::B3::StackmapGenerationParams::begin):
(JSC::B3::StackmapGenerationParams::end):
(JSC::B3::StackmapGenerationParams::context):
(JSC::B3::StackmapGenerationParams::addLatePath):
* b3/B3StackmapValue.h:
* b3/B3ValueRep.h:
(JSC::B3::ValueRep::doubleValue):
(JSC::B3::ValueRep::withOffset):
* b3/air/AirGenerationContext.h:
* b3/testb3.cpp:
(JSC::B3::testSimplePatchpoint):
(JSC::B3::testSimplePatchpointWithoutOuputClobbersGPArgs):
(JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
(JSC::B3::testSimplePatchpointWithoutOuputClobbersFPArgs):
(JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
(JSC::B3::testPatchpointWithEarlyClobber):
(JSC::B3::testPatchpointCallArg):
(JSC::B3::testPatchpointFixedRegister):
(JSC::B3::testPatchpointAny):
(JSC::B3::testPatchpointLotsOfLateAnys):
(JSC::B3::testPatchpointAnyImm):
(JSC::B3::testPatchpointManyImms):
(JSC::B3::testPatchpointWithRegisterResult):
(JSC::B3::testPatchpointWithStackArgumentResult):
(JSC::B3::testPatchpointWithAnyResult):
(JSC::B3::testSimpleCheck):
(JSC::B3::testCheckLessThan):
(JSC::B3::testCheckMegaCombo):
(JSC::B3::testCheckAddImm):
(JSC::B3::testCheckAddImmCommute):
(JSC::B3::testCheckAddImmSomeRegister):
(JSC::B3::testCheckAdd):
(JSC::B3::testCheckAdd64):
(JSC::B3::testCheckSubImm):
(JSC::B3::testCheckSubBadImm):
(JSC::B3::testCheckSub):
(JSC::B3::testCheckSub64):
(JSC::B3::testCheckNeg):
(JSC::B3::testCheckNeg64):
(JSC::B3::testCheckMul):
(JSC::B3::testCheckMulMemory):
(JSC::B3::testCheckMul2):
(JSC::B3::testCheckMul64):
(JSC::B3::genericTestCompare):
* ftl/FTLExceptionHandlerManager.cpp:
* ftl/FTLExceptionHandlerManager.h:
* ftl/FTLJSCall.cpp:
* ftl/FTLJSCall.h:
* ftl/FTLJSCallBase.cpp:
(JSC::FTL::JSCallBase::emit):
* ftl/FTLJSCallBase.h:
* ftl/FTLJSCallVarargs.cpp:
* ftl/FTLJSCallVarargs.h:
* ftl/FTLJSTailCall.cpp:
(JSC::FTL::DFG::getRegisterWithAddend):
(JSC::FTL::JSTailCall::emit):
(JSC::FTL::JSTailCall::JSTailCall): Deleted.
* ftl/FTLJSTailCall.h:
(JSC::FTL::JSTailCall::stackmapID):
(JSC::FTL::JSTailCall::estimatedSize):
(JSC::FTL::JSTailCall::operator<):
(JSC::FTL::JSTailCall::patchpoint): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBranchToOSRExitIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
(JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
(JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
(JSC::FTL::OSRExitDescriptor::emitOSRExit):
(JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
(JSC::FTL::OSRExit::OSRExit):
(JSC::FTL::OSRExit::codeLocationForRepatch):
(JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
(JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
(JSC::FTL::OSRExit::needsRegisterRecoveryOnGenericUnwindOSRExitPath):
* ftl/FTLOSRExit.h:
(JSC::FTL::OSRExitDescriptorImpl::OSRExitDescriptorImpl):
(JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLState.h:
2015-12-07 Saam barati <sbarati@apple.com>
Rename Watchdog::didFire to Watchdog::shouldTerminate because that's what didFire really meant
https://bugs.webkit.org/show_bug.cgi?id=151944
Reviewed by Mark Lam.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* runtime/VMInlines.h:
(JSC::VM::shouldTriggerTermination):
* runtime/Watchdog.cpp:
(JSC::Watchdog::terminateSoon):
(JSC::Watchdog::shouldTerminateSlow):
(JSC::Watchdog::didFireSlow): Deleted.
* runtime/Watchdog.h:
(JSC::Watchdog::shouldTerminate):
(JSC::Watchdog::didFire): Deleted.
2015-12-07 Mark Lam <mark.lam@apple.com>
Rename JITBitwiseBinaryOpGenerator to JITBitBinaryOpGenerator.
https://bugs.webkit.org/show_bug.cgi?id=151945
Reviewed by Saam Barati.
The lshift operator also need to inherit from JITBitBinaryOpGenerator. Calling
it "BitBinaryOp" makes more sense than "BitwiseBinaryOp" in that case, and still
makes sense for the bitand, bitor, and bitxor operators.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emit_op_bitand):
(JSC::JIT::emitSlow_op_bitand):
(JSC::JIT::emit_op_bitor):
(JSC::JIT::emitSlow_op_bitor):
(JSC::JIT::emit_op_bitxor):
(JSC::JIT::emitSlow_op_bitxor):
(JSC::JIT::emitBitwiseBinaryOpFastPath): Deleted.
* jit/JITBitAndGenerator.h:
(JSC::JITBitAndGenerator::JITBitAndGenerator):
* jit/JITBitBinaryOpGenerator.h: Copied from Source/JavaScriptCore/jit/JITBitwiseBinaryOpGenerator.h.
(JSC::JITBitBinaryOpGenerator::JITBitBinaryOpGenerator):
(JSC::JITBitwiseBinaryOpGenerator::JITBitwiseBinaryOpGenerator): Deleted.
* jit/JITBitOrGenerator.h:
(JSC::JITBitOrGenerator::JITBitOrGenerator):
* jit/JITBitXorGenerator.h:
(JSC::JITBitXorGenerator::JITBitXorGenerator):
* jit/JITBitwiseBinaryOpGenerator.h: Removed.
2015-12-07 Csaba Osztrogonác <ossy@webkit.org>
[B3] Typo fix after r193386 to fix the build
https://bugs.webkit.org/show_bug.cgi?id=151860
Reviewed by Filip Pizlo.
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::isArgValidForValue):
2015-12-07 Gyuyoung Kim <gyuyoung.kim@webkit.org>
[EFL] Implement scheduleTimer and cancelTimer in IncrementalSweeper class
https://bugs.webkit.org/show_bug.cgi?id=151656
Reviewed by Csaba Osztrogonác.
Support IncremntalSweeper using Ecore_Timer.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::IncrementalSweeper):
(JSC::IncrementalSweeper::scheduleTimer):
(JSC::IncrementalSweeper::cancelTimer):
* heap/IncrementalSweeper.h:
2015-12-06 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement String.prototype.toLocaleLowerCase in ECMA-402
https://bugs.webkit.org/show_bug.cgi?id=147608
Reviewed by Benjamin Poulain.
Add toLocaleLowerCase using icu u_strToLower.
* runtime/IntlObject.cpp:
(JSC::defaultLocale): Expose.
(JSC::bestAvailableLocale): Expose.
(JSC::removeUnicodeLocaleExtension): Expose.
* runtime/IntlObject.h:
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::stringProtoFuncToLocaleLowerCase): Add.
2015-12-06 David Kilzer <ddkilzer@apple.com>
REGRESSION(r193584): Causes heap use-after-free crashes in Web Inspector tests with AddressSanitizer (Requested by ddkilzer on #webkit).
https://bugs.webkit.org/show_bug.cgi?id=151929
Reverted changeset:
"[ES6] "super" and "this" should be lexically bound inside an
arrow function and should live in a JSLexicalEnvironment"
https://bugs.webkit.org/show_bug.cgi?id=149338
http://trac.webkit.org/changeset/193584
2015-12-06 Skachkov Oleksandr <gskachkov@gmail.com>
[es6] Arrow function syntax. Fix tests after 149338 landing
https://bugs.webkit.org/show_bug.cgi?id=151927
Reviewed by Saam Barati.
After landing patch for 149338 errors appear in for ES6 Generator. Current fix is removed assert
that was removed by patch with implemenation of ES6 Generator.
* runtime/CommonSlowPaths.cpp:
2015-12-05 Aleksandr Skachkov <gskachkov@gmail.com>
[ES6] "super" and "this" should be lexically bound inside an arrow function and should live in a JSLexicalEnvironment
https://bugs.webkit.org/show_bug.cgi?id=149338
Reviewed by Saam Barati.
Implemented new version of the lexically bound 'this' in arrow function. In current version
'this' is stored inside of the lexical environment of the function. To store and load we use
op_get_from_scope and op_put_to_scope operations. Also new implementation prevent raising TDZ
error for arrow functions that are declared before super() but invoke after.
* builtins/BuiltinExecutables.cpp:
(JSC::createExecutableInternal):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::getSlow):
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::isDerivedConstructorContext):
(JSC::ExecutableInfo::isArrowFunctionContext):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::isArrowFunction):
(JSC::UnlinkedCodeBlock::isDerivedConstructorContext):
(JSC::UnlinkedCodeBlock::isArrowFunctionContext):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
(JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
(JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
(JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::isDerivedConstructorContext):
(JSC::BytecodeGenerator::usesArrowFunction):
(JSC::BytecodeGenerator::needsToUpdateArrowFunctionContext):
(JSC::BytecodeGenerator::usesEval):
(JSC::BytecodeGenerator::usesThis):
(JSC::BytecodeGenerator::newTarget):
(JSC::BytecodeGenerator::makeFunction):
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
(JSC::SuperNode::emitBytecode):
(JSC::EvalFunctionCallNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluate):
* dfg/DFGAbstractInterpreterInlines.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
* dfg/DFGClobberize.h:
* dfg/DFGDoesGC.cpp:
* dfg/DFGFixupPhase.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGPromotedHeapLocation.cpp:
* dfg/DFGPromotedHeapLocation.h:
* dfg/DFGSafeToExecute.h:
* dfg/DFGSpeculativeJIT.cpp:
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
* dfg/DFGSpeculativeJIT64.cpp:
* ftl/FTLCapabilities.cpp:
* ftl/FTLLowerDFGToLLVM.cpp:
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* interpreter/Interpreter.cpp:
(JSC::eval):
* jit/JIT.cpp:
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emitNewFuncExprCommon):
* jit/JITOpcodes32_64.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createArrowFunctionExpr):
(JSC::ASTBuilder::usesArrowFunction):
* parser/Nodes.h:
(JSC::ScopeNode::usesArrowFunction):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/ParserModes.h:
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getModuleProgramCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/CommonIdentifiers.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::EvalExecutable::create):
(JSC::EvalExecutable::EvalExecutable):
(JSC::ProgramExecutable::ProgramExecutable):
(JSC::ModuleProgramExecutable::ModuleProgramExecutable):
(JSC::FunctionExecutable::FunctionExecutable):
* runtime/Executable.h:
(JSC::ScriptExecutable::isArrowFunctionContext):
(JSC::ScriptExecutable::isDerivedConstructorContext):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createEvalCodeBlock):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* tests/es6.yaml:
* tests/stress/arrowfunction-activation-sink-osrexit.js:
* tests/stress/arrowfunction-activation-sink.js:
* tests/stress/arrowfunction-lexical-bind-newtarget.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-1.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-2.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-3.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-4.js: Added.
* tests/stress/arrowfunction-lexical-bind-this-1.js:
* tests/stress/arrowfunction-lexical-bind-this-7.js: Added.
* tests/stress/arrowfunction-tdz-1.js: Added.
* tests/stress/arrowfunction-tdz-2.js: Added.
* tests/stress/arrowfunction-tdz-3.js: Added.
* tests/stress/arrowfunction-tdz-4.js: Added.
* tests/stress/arrowfunction-tdz.js: Removed.
2015-12-05 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove FTLOutput's fence support
https://bugs.webkit.org/show_bug.cgi?id=151909
Reviewed by Sam Weinig.
Unused code is unused.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::fence): Deleted.
(JSC::FTL::Output::fenceAcqRel): Deleted.
* ftl/FTLOutput.h:
(JSC::FTL::Output::fence): Deleted.
(JSC::FTL::Output::fenceAcqRel): Deleted.
2015-12-04 Benjamin Poulain <bpoulain@apple.com>
[JSC] Some more cleanup of FTLB3Output
https://bugs.webkit.org/show_bug.cgi?id=151834
Reviewed by Filip Pizlo.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::trap):
(JSC::FTL::Output::stackmapIntrinsic): Deleted.
(JSC::FTL::Output::frameAddressIntrinsic): Deleted.
(JSC::FTL::Output::patchpointInt64Intrinsic): Deleted.
(JSC::FTL::Output::patchpointVoidIntrinsic): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::probe):
2015-12-04 Benjamin Poulain <bpoulain@apple.com>
[JSC] Fix Value::returnsBool() after r193436
https://bugs.webkit.org/show_bug.cgi?id=151902
Reviewed by Saam Barati.
I forgot to carry a test from Branch and Select :(
* b3/B3Value.cpp:
(JSC::B3::Value::returnsBool):
2015-12-04 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement Number.prototype.toLocaleString in ECMA-402
https://bugs.webkit.org/show_bug.cgi?id=147610
Reviewed by Benjamin Poulain.
Add toLocaleString in builtin JavaScript that delegates formatting to Intl.NumberFormat.
Keep exisiting native implementation for use if INTL flag is disabled.
* CMakeLists.txt: Add NumberPrototype.js.
* DerivedSources.make: Add NumberPrototype.js.
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/NumberPrototype.js: Added.
(toLocaleString):
* runtime/CommonIdentifiers.h: Add private names for Intl constructors.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Expose Intl constructors to builtin js.
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation): Replace toLocaleString implementation.
2015-12-04 Michael Saboff <msaboff@apple.com>
CRASH: CodeBlock::setOptimizationThresholdBasedOnCompilationResult + 567
https://bugs.webkit.org/show_bug.cgi?id=151892
Reviewed by Mark Lam.
When the debugger is in the process of attaching and it recompiles functions
for debugging, there can also be a DFG compilation running concurrently.
When we go to update the optimization threshold and find that the replacement
is also baseline code, we shouldn't update the threshold.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
2015-12-04 Jonathan Davis <jond@apple.com>
Update feature status for up-to-date status information.
https://bugs.webkit.org/show_bug.cgi?id=151821
Reviewed by Timothy Hatcher.
* features.json:
2015-12-04 Saam barati <sbarati@apple.com>
OSR exits that are exception handlers should emit less code eagerly in the thunk generator, and instead, should defer as much code generation as possible to be lazily generated in the exit itself
https://bugs.webkit.org/show_bug.cgi?id=151406
Reviewed by Filip Pizlo.
We no longer emit any extra code eagerly for an OSRExit that
is an exception handler. We emit all code lazily in the exit
itself. This has one interesting consequence which is that the
actual C call to compile the exit goes through an OSR exit generation
thunk that must now be aware of resetting the call frame and the stack
pointer to their proper values before making the compileOSRExit C
call. This has one interesting consequence in the FTL because the
FTL will do a pushToSaveImmediateWithoutTouchingRegisters with the
OSR exit index. We must take care to preserve this exit index when
we reset the stack pointer by re-pushing it onto the stack.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::jitCode):
(JSC::CodeBlock::jitCodeOffset):
(JSC::CodeBlock::jitType):
* dfg/DFGCommonData.h:
(JSC::DFG::CommonData::frameRegisterCountOffset):
* dfg/DFGJITCode.h:
(JSC::DFG::JITCode::setOSREntryBlock):
(JSC::DFG::JITCode::clearOSREntryBlock):
(JSC::DFG::JITCode::commonDataOffset):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompilerCommon.h:
(JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExitThunkGenerator.cpp:
(JSC::FTL::ExitThunkGenerator::~ExitThunkGenerator):
(JSC::FTL::ExitThunkGenerator::emitThunk):
(JSC::FTL::ExitThunkGenerator::emitThunks):
* ftl/FTLExitThunkGenerator.h:
(JSC::FTL::ExitThunkGenerator::didThings):
* ftl/FTLJITCode.h:
(JSC::FTL::JITCode::commonDataOffset):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
(JSC::FTL::osrExitGenerationThunkGenerator):
(JSC::FTL::lazySlowPathGenerationThunkGenerator):
(JSC::FTL::registerClobberCheck):
2015-12-04 Filip Pizlo <fpizlo@apple.com>
Having a bad time has a really awful time when it runs at the same time as the JIT
https://bugs.webkit.org/show_bug.cgi?id=151882
rdar://problem/23547038
Unreviewed, really adding the test this time.
* tests/stress/ftl-has-a-bad-time.js: Added.
(foo):
2015-12-04 Mark Lam <mark.lam@apple.com>
Snippefy bitwise operators for the baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=151680
Reviewed by Geoffrey Garen.
This patch has passed the JSC tests on x86 and x86_64. It has also passed the
layout tests on x86_64.
With the DFG enabled, perf is neutral on x86_64 and x86.
With the DFG disabled on x86_64, some AsmBench tests are showing progressions e.g.
gcc-loops.cpp 1.0269x faster
stepanov_container.cpp 1.0180x faster
With the DFG disabled on x86, perf is neutral.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::moveValueRegs):
(JSC::AssemblyHelpers::branchIfNotInt32):
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emitBitwiseBinaryOpFastPath):
- Template for the bitwise operations.
(JSC::JIT::emit_op_bitand):
(JSC::JIT::emit_op_bitor):
(JSC::JIT::emit_op_bitxor):
- Specializes emitBitwiseBinaryOpFastPath() with the respective snippet generators.
(JSC::JIT::emitSlow_op_bitand):
(JSC::JIT::emitSlow_op_bitor):
(JSC::JIT::emitSlow_op_bitxor):
- Implement respective slow paths.
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_op_bitand): Deleted.
(JSC::JIT::emitSlow_op_bitand): Deleted.
(JSC::JIT::emit_op_bitor): Deleted.
(JSC::JIT::emitSlow_op_bitor): Deleted.
(JSC::JIT::emit_op_bitxor): Deleted.
(JSC::JIT::emitSlow_op_bitxor): Deleted.
- Now unified with the 64-bit version using snippets.
* jit/JITBitAndGenerator.cpp: Added.
(JSC::JITBitAndGenerator::generateFastPath):
* jit/JITBitAndGenerator.h: Added.
(JSC::JITBitAndGenerator::JITBitAndGenerator):
* jit/JITBitOrGenerator.cpp: Added.
(JSC::JITBitOrGenerator::generateFastPath):
* jit/JITBitOrGenerator.h: Added.
(JSC::JITBitOrGenerator::JITBitOrGenerator):
* jit/JITBitXorGenerator.cpp: Added.
(JSC::JITBitXorGenerator::generateFastPath):
* jit/JITBitXorGenerator.h: Added.
(JSC::JITBitXorGenerator::JITBitXorGenerator):
* jit/JITBitwiseBinaryOpGenerator.h: Added.
(JSC::JITBitwiseBinaryOpGenerator::JITBitwiseBinaryOpGenerator):
(JSC::JITBitwiseBinaryOpGenerator::didEmitFastPath):
(JSC::JITBitwiseBinaryOpGenerator::endJumpList):
(JSC::JITBitwiseBinaryOpGenerator::slowPathJumpList):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_bitxor): Deleted.
(JSC::JIT::emit_op_bitor): Deleted.
(JSC::JIT::emitSlow_op_bitxor): Deleted.
(JSC::JIT::emitSlow_op_bitor): Deleted.
* jit/SnippetOperand.h:
(JSC::SnippetOperand::SnippetOperand):
* tests/stress/op_bitand.js:
* tests/stress/op_bitor.js:
* tests/stress/op_bitxor.js:
- Fix a test value typo: it's supposed to be 0x7fffffff, not 0x7ffffff.
2015-12-04 Filip Pizlo <fpizlo@apple.com>
Having a bad time has a really awful time when it runs at the same time as the JIT
https://bugs.webkit.org/show_bug.cgi?id=151882
rdar://problem/23547038
Reviewed by Geoffrey Garen.
The DFG's use of watchpoints for havingABadTime goes back a long time. We introduced this feature
when we first introduced watchpoints. That left it open to a lot of bitrot. On top of that, this
code doesn't get tested much because having a bad time is not something that is really supposed to
happen.
Well, now I've got reports that it does happen - or at least, we know that it is because of
crashes in an assertion that could only be triggered if a bad time was had. In the meantime, we
added two new features without adequately testing havingABadTime: concurrent JIT and FTL.
Concurrency means that we have to worry about the havingABadTime watchpoint triggering during
compilation. FTL means that we have new code and new optimizations that needs to deal with this
feature correctly.
The bug can arise via race condition or just goofy profiling. As in the newly added test, we could
first profile an allocation thinking that it will allocate sane arrays. Then we might have a bad
time, and then compile that function with the FTL. The ByteCodeParser will represent the
allocation with a NewArray node that has a sane indexingType(). But when we go to lower the Node,
we observe that the Structure* that the JSGlobalObject tells us to use has a different indexing
type. This is a feature of havingABadTime that the DFG knew about, but the FTL didn't. The FTL
didn't know about it because we didn't have adequate tests, and this code rarely gets triggered in
the wild. So, the FTL had a silly assertion that the indexing types match. They absolutely don't
have to match.
There is another bug, a race condition, that remains even if we remove the bad assertion. We set
the havingABadTime watchpoint late in compilation, and we do it based on whether the watchpoint is
still OK. This means that we could parse a function before we have a bad time and then do
optimizations (for example in AbstractInterpreter) like proving that the structure set associated
with the value returned by the NewArray is the one with a sane indexing type. Then, after those
optimizations have already been done, we will go to set the watchpoint. But just as we are doing
this, we could haveABadTime on the main thread. Currently this sort of almost works because
having a bad time requires doing a GC, and we can't GC until the watchpoint collection phase. But
that feels too fragile. So, this phase moves the setting of the watchpoint to the FixupPhase. This
is consistent with our long-term goal of removing the WatchpointCollectionPhase. Moving this to
FixupPhase means that we set the watchpoint before doing any optimizations. So, if having a bad
time happens before the FixupPhase then all optimizations will agree that we're having a bad time
and so everything is fine; if we have a bad time after FixupPhase then we will cancel the
compilation anyway.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::watchHavingABadTime):
(JSC::DFG::FixupPhase::createToString):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasIndexingType):
(JSC::DFG::Node::indexingType):
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::WatchpointCollectionPhase::handle):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewArray):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayBuffer):
* tests/stress/ftl-has-a-bad-time.js: Added.
2015-12-04 Benjamin Poulain <bpoulain@apple.com>
[JSC] Use Div and ChillDiv in FTL(B3)Output
https://bugs.webkit.org/show_bug.cgi?id=151844
Reviewed by Geoffrey Garen.
I copied part of the code of compileArithDiv()
to create a new function FTLOutput::childDiv().
With childDiv() being a concept of FTLOutput,
FTLB3Output was updated accordingly.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::div):
(JSC::FTL::Output::chillDiv):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::chillDiv):
* ftl/FTLOutput.h:
2015-12-04 Benjamin Poulain <bpoulain@apple.com>
[JSC] Extend the strength reduction of B3's BitAnd with booleans
https://bugs.webkit.org/show_bug.cgi?id=151852
Reviewed by Saam Barati.
1) Masking a boolean with any pattern that has the lsb set
remains a boolean.
2) ReduceStrength on that particular pattern of BitAnd.
* b3/B3ReduceStrength.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::returnsBool):
* b3/testb3.cpp:
(JSC::B3::testBitAndWithMaskReturnsBooleans):
(JSC::B3::run):
2015-12-04 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add doubleRem() to FTLB3Output
https://bugs.webkit.org/show_bug.cgi?id=151851
Reviewed by Geoffrey Garen.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doubleRem):
2015-12-04 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add signExt() to FTLB3Output
https://bugs.webkit.org/show_bug.cgi?id=151853
Reviewed by Geoffrey Garen.
Rename signExt() to signExt32To64(). This is just to separate
it explicitly from the remaining signExt() used inside FTLOutput.
Then use the SExt32 for implementing that in B3.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::signExt32To64):
(JSC::FTL::Output::signExt): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileInt52Rep):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetDirectPname):
(JSC::FTL::DFG::LowerDFGToLLVM::strictInt52ToInt32):
(JSC::FTL::DFG::LowerDFGToLLVM::strictInt52ToJSValue):
(JSC::FTL::DFG::LowerDFGToLLVM::jsValueToStrictInt52):
* ftl/FTLOutput.h:
(JSC::FTL::Output::signExt32To64):
(JSC::FTL::Output::signExt):
2015-12-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Unskip many inspector/debugger tests
https://bugs.webkit.org/show_bug.cgi?id=151843
Reviewed by Timothy Hatcher.
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
Ignore TerminationExceptions, as those aren't real execution
exceptions and may be seen on Workers that have closed.
2015-12-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove untested and unused Worker inspection
https://bugs.webkit.org/show_bug.cgi?id=151848
Reviewed by Brian Burg.
* CMakeLists.txt:
* DerivedSources.make:
* debugger/Debugger.cpp:
(JSC::Debugger::Debugger):
(JSC::Debugger::willExecuteProgram):
* debugger/Debugger.h:
* inspector/JSGlobalObjectScriptDebugServer.cpp:
(Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::ScriptDebugServer):
* inspector/ScriptDebugServer.h:
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::run): Deleted.
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/JSGlobalObjectConsoleAgent.h:
* inspector/protocol/Runtime.json:
* inspector/protocol/Worker.json: Removed.
2015-12-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Specifically Identify the Global Lexical Environment Scope
https://bugs.webkit.org/show_bug.cgi?id=151828
Reviewed by Brian Burg.
* inspector/InjectedScriptSource.js:
Include the new scope type.
* inspector/JSJavaScriptCallFrame.h:
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::scopeType):
Set the new value for the new scope type.
* inspector/JSJavaScriptCallFramePrototype.cpp:
(Inspector::JSJavaScriptCallFramePrototype::finishCreation): Deleted.
(Inspector::jsJavaScriptCallFrameConstantGLOBAL_SCOPE): Deleted.
(Inspector::jsJavaScriptCallFrameConstantLOCAL_SCOPE): Deleted.
(Inspector::jsJavaScriptCallFrameConstantWITH_SCOPE): Deleted.
(Inspector::jsJavaScriptCallFrameConstantCLOSURE_SCOPE): Deleted.
(Inspector::jsJavaScriptCallFrameConstantCATCH_SCOPE): Deleted.
(Inspector::jsJavaScriptCallFrameConstantFUNCTION_NAME_SCOPE): Deleted.
Remove unused constants on the JavaScriptCallFrame object.
Currently they are just hardcoded in InjectedScriptSource
and they don't make sense on instances anyways.
2015-12-04 Keith Miller <keith_miller@apple.com>
Add an option to emit instructions validating exceptions in the DFG rather than always emiting them.
https://bugs.webkit.org/show_bug.cgi?id=151841
Reviewed by Saam Barati.
Add a new option that validates the DFG execption checking. The default value for the option is
true in Debug builds and false in Release builds. Additionally, renamed jitAssertNoException to
jitReleaseAssertNoException for consistency with our ASSERT naming convention.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::jitReleaseAssertNoException):
(JSC::AssemblyHelpers::jitAssertNoException): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::jitAssertNoException): Deleted.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2015-12-04 Csaba Osztrogonác <ossy@webkit.org>
Fix the !ENABLE(DFG_JIT) build after r190735
https://bugs.webkit.org/show_bug.cgi?id=151617
Reviewed by Filip Pizlo.
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
2015-12-04 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Fix the B3 build after r192946
https://bugs.webkit.org/show_bug.cgi?id=151857
Reviewed by Michael Saboff.
* CMakeLists.txt:
2015-12-04 Csaba Osztrogonác <ossy@webkit.org>
[AArch64] Typo fix after r189575
https://bugs.webkit.org/show_bug.cgi?id=151855
Reviewed by Michael Saboff.
* ftl/FTLUnwindInfo.cpp:
(JSC::FTL::parseUnwindInfo):
2015-12-03 Filip Pizlo <fpizlo@apple.com>
B3 Patchpoint and Check opcodes should be able to specify WarmAny, ColdAny, and LateColdAny
https://bugs.webkit.org/show_bug.cgi?id=151335
Reviewed by Geoffrey Garen.
This removes ValueRep::Any and replaces it with ValueRep::WarmAny, ValueRep::ColdAny, and
ValueRep::LateColdAny. I think that conceptually the most obvious users of patchpoints are inline
caches, which would use WarmAny for their non-OSR inputs. For this reason, I make WarmAny the
default.
However, the StackmapValue optimization that provides a default ValueRep for any that are missing
was meant for OSR. So, this optimization now uses ColdAny.
This patch wires this change through the whole compiler and adds some tests.
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::Key::Key):
(JSC::B3::CheckSpecial::Key::dump):
(JSC::B3::CheckSpecial::CheckSpecial):
* b3/B3CheckSpecial.h:
(JSC::B3::CheckSpecial::Key::Key):
(JSC::B3::CheckSpecial::Key::opcode):
(JSC::B3::CheckSpecial::Key::numArgs):
(JSC::B3::CheckSpecial::Key::stackmapRole):
* b3/B3CheckValue.cpp:
(JSC::B3::CheckValue::CheckValue):
* b3/B3ConstrainedValue.h:
(JSC::B3::ConstrainedValue::ConstrainedValue):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::fillStackmap):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3MoveConstants.cpp:
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::forEachArg):
(JSC::B3::PatchpointSpecial::isValid):
(JSC::B3::PatchpointSpecial::admitsStack):
* b3/B3PatchpointValue.cpp:
(JSC::B3::PatchpointValue::PatchpointValue):
* b3/B3PatchpointValue.h:
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
(JSC::B3::StackmapSpecial::admitsStackImpl):
(JSC::B3::StackmapSpecial::isArgValidForRep):
(WTF::printInternal):
* b3/B3StackmapSpecial.h:
* b3/B3StackmapValue.cpp:
(JSC::B3::StackmapValue::append):
(JSC::B3::StackmapValue::setConstraint):
* b3/B3StackmapValue.h:
* b3/B3Validate.cpp:
* b3/B3ValueRep.cpp:
(JSC::B3::ValueRep::dump):
(WTF::printInternal):
* b3/B3ValueRep.h:
(JSC::B3::ValueRep::ValueRep):
(JSC::B3::ValueRep::reg):
(JSC::B3::ValueRep::operator!=):
(JSC::B3::ValueRep::operator bool):
(JSC::B3::ValueRep::isAny):
(JSC::B3::ValueRep::isSomeRegister):
* b3/testb3.cpp:
(JSC::B3::compileAndRun):
(JSC::B3::add32):
(JSC::B3::test42):
(JSC::B3::testSimplePatchpoint):
(JSC::B3::testPatchpointWithEarlyClobber):
(JSC::B3::testPatchpointFixedRegister):
(JSC::B3::testPatchpointAny):
(JSC::B3::testPatchpointLotsOfLateAnys):
(JSC::B3::testPatchpointAnyImm):
(JSC::B3::testPatchpointManyImms):
(JSC::B3::testPatchpointWithRegisterResult):
(JSC::B3::testPatchpointWithAnyResult):
(JSC::B3::run):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
2015-12-03 Filip Pizlo <fpizlo@apple.com>
B3 patchpoints should allow specifying output constraints
https://bugs.webkit.org/show_bug.cgi?id=151809
Reviewed by Benjamin Poulain.
JS call patchpoints should put their result into the result register, while most other patchpoints
should put their results into some register. I think that it's best if we just allow arbitrary
constraints on the result of a patchpoint. And by "arbitrary" I mean allowing the same kinds of
constraints as we allow on the stackmap children.
This also adds a large comment in B3StackmapValue.h that lays out the philosophy of our stackmaps
and patchpoints. I found it useful to write down the plan since it's pretty subtle.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::isValid):
(JSC::B3::PatchpointSpecial::admitsStack):
* b3/B3PatchpointValue.cpp:
(JSC::B3::PatchpointValue::~PatchpointValue):
(JSC::B3::PatchpointValue::dumpMeta):
(JSC::B3::PatchpointValue::PatchpointValue):
* b3/B3PatchpointValue.h:
(JSC::B3::PatchpointValue::accepts):
* b3/B3Procedure.h:
(JSC::B3::Procedure::code):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::isValidImpl):
(JSC::B3::StackmapSpecial::appendRepsImpl):
(JSC::B3::StackmapSpecial::isArgValidForValue):
(JSC::B3::StackmapSpecial::isArgValidForRep):
(JSC::B3::StackmapSpecial::repForArg):
* b3/B3StackmapSpecial.h:
* b3/B3StackmapValue.h:
* b3/B3Validate.cpp:
* b3/B3ValueRep.h:
(JSC::B3::ValueRep::doubleValue):
* b3/testb3.cpp:
(JSC::B3::testPatchpointManyImms):
(JSC::B3::testPatchpointWithRegisterResult):
(JSC::B3::testPatchpointWithStackArgumentResult):
(JSC::B3::testPatchpointWithAnyResult):
(JSC::B3::testSimpleCheck):
(JSC::B3::run):
* jit/RegisterSet.h:
2015-12-03 Anders Carlsson <andersca@apple.com>
Remove Objective-C GC support
https://bugs.webkit.org/show_bug.cgi?id=151819
rdar://problem/23746991
Reviewed by Dan Bernstein.
* Configurations/Base.xcconfig:
* Configurations/ToolExecutable.xcconfig:
2015-12-03 Benjamin Poulain <bpoulain@apple.com>
Attempt to fix GTK again after r193125
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::supportsLZCNT):
2015-12-03 Benjamin Poulain <bpoulain@apple.com>
Attempt to fix GTK after r193125
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::supportsLZCNT):
GCC is unable to handle EBX correctly when clobbered by inline asm.
2015-12-03 Saam barati <sbarati@apple.com>
FTL::OSRExitDescriptor should use less memory by having a companion object that dies after compilation
https://bugs.webkit.org/show_bug.cgi?id=151795
Reviewed by Geoffrey Garen.
There were a few fields on FTL::OSRExitDescriptor that are only
needed during compilation. This patch introduces OSRExitDescriptorImpl
which is a struct that we create for each OSRExitDescriptor. The difference is
that OSRExitDescriptorImpl lives off of FTL::State so it dies after we compile.
This way no unnecessary fields persist after the compilation.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExceptionHandlerManager.cpp:
(JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
(JSC::FTL::ExceptionHandlerManager::getCallOSRExitCommon):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
(JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
(JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
(JSC::FTL::OSRExitDescriptor::validateReferences):
(JSC::FTL::OSRExitDescriptor::emitOSRExit):
(JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
(JSC::FTL::OSRExit::OSRExit):
(JSC::FTL::OSRExit::codeLocationForRepatch):
(JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
(JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
(JSC::FTL::exceptionTypeWillArriveAtOSRExitFromGenericUnwind):
(JSC::FTL::OSRExit::willArriveAtOSRExitFromGenericUnwind):
(JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
(JSC::FTL::OSRExitDescriptor::isExceptionHandler): Deleted.
* ftl/FTLOSRExit.h:
(JSC::FTL::OSRExitDescriptorImpl::OSRExitDescriptorImpl):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLState.h:
2015-12-03 Alex Christensen <achristensen@webkit.org>
Fix 64-bit Windows build after r193125.
https://bugs.webkit.org/show_bug.cgi?id=151799
Reviewed by Michael Saboff.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::supportsLZCNT):
Use __cpuid intrinsic instead of inline assembly.
2015-12-02 Filip Pizlo <fpizlo@apple.com>
FTL B3 should support OSR exit
https://bugs.webkit.org/show_bug.cgi?id=151710
Reviewed by Saam Barati.
This adds OSR exit support using the same style that I established with lazy slow paths. All of
the work is driven by FTL::LowerDFGToLLVM, and from there any work that needs to be deferred
until after B3 finishes is attached to the stackmap generator. In order to make it easy to port
all of the different forms of OSR exit - invalidation points, exceptions, etc. - the logic for
registering an OSR exit is abstracted behind OSRExitDescriptor and OSRExitHandle.
An issue that I encountered repeatedly in this patch is OSRExitDescriptor being passed as a
reference (&) rather than pointer (*). The new code uses a lot of lambdas that run after the
current frame pops, so the capture list cannot be [&]. I believe that always listing all of the
captured variables is not scalable considering how sophisticated our use of lambdas is. So, it
makes sense to use [=]. But anytime we captured a variable whose type was OSRExitDescriptor&, it
would be captured by value, because that's how references work. One has to be mindful of these
things whenever using [=]. Note that it's not enough to say that we should have listed the
captured variables explicitly - in that case, we still could have made the mistake by forgetting
to put & in front of the variant. The pattern that worked for me to reason about whether I'm
capturing an object or a pointer to an object is to always use pointer types for pointers: either
RefPtr<> when we also want the lambda to prolong the object's life, or * if we are confident that
the object will stay alive. For this reason, this patch changes all code that references
OSRExitDescriptor to use * instead of &. Consistency makes the code easier to grok, and it made
it easier to introduce the required uses of * in places where there were lambdas.
I tested this by running imaging-gaussian-blur, and running some tests that reqiure OSR exit. I'm
not promising that all kinds of exits work, but we have to begin somewhere.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Compilation.cpp:
(JSC::B3::Compilation::Compilation):
(JSC::B3::Compilation::~Compilation):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addDataSection):
(JSC::B3::Procedure::frameSize):
(JSC::B3::Procedure::calleeSaveRegisters):
* b3/B3Procedure.h:
(JSC::B3::Procedure::releaseByproducts):
(JSC::B3::Procedure::code):
(JSC::B3::Procedure::takeByproducts): Deleted.
* b3/air/AirCode.h:
(JSC::B3::Air::Code::setFrameSize):
(JSC::B3::Air::Code::calleeSaveRegisters):
* b3/air/AirGenerationContext.h:
* ftl/FTLB3Compile.cpp:
(JSC::FTL::compile):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExceptionHandlerManager.cpp:
(JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
(JSC::FTL::ExceptionHandlerManager::getCallOSRExitCommon):
* ftl/FTLExitThunkGenerator.cpp:
* ftl/FTLExitThunkGenerator.h:
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::JITCode):
(JSC::FTL::JITCode::initializeB3Code):
(JSC::FTL::JITCode::initializeB3Byproducts):
(JSC::FTL::JITCode::initializeExitThunks):
(JSC::FTL::JITCode::validateReferences):
(JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
* ftl/FTLJITCode.h:
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLJITFinalizer.h:
* ftl/FTLJSCall.cpp:
(JSC::FTL::JSCall::emit):
* ftl/FTLJSCallBase.cpp:
(JSC::FTL::JSCallBase::emit):
* ftl/FTLJSTailCall.cpp:
(JSC::FTL::JSTailCall::JSTailCall):
(JSC::FTL::JSTailCall::emit):
(JSC::FTL::DFG::getRegisterWithAddend): Deleted.
(JSC::FTL::m_instructionOffset): Deleted.
* ftl/FTLJSTailCall.h:
(JSC::FTL::JSTailCall::patchpoint):
(JSC::FTL::JSTailCall::stackmapID):
(JSC::FTL::JSTailCall::estimatedSize):
(JSC::FTL::JSTailCall::operator<):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
(JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
(JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
(JSC::FTL::lowerDFGToLLVM):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
(JSC::FTL::OSRExitDescriptor::validateReferences):
(JSC::FTL::OSRExitDescriptor::appendOSRExit):
(JSC::FTL::OSRExitDescriptor::appendOSRExitLater):
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
(JSC::FTL::OSRExit::OSRExit):
(JSC::FTL::OSRExit::codeLocationForRepatch):
(JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
(JSC::FTL::OSRExit::spillRegistersToSpillSlot):
(JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
(JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
* ftl/FTLOSRExit.h:
(JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
* ftl/FTLOSRExitCompilationInfo.h:
(JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::reboxAccordingToFormat):
(JSC::FTL::compileRecovery):
(JSC::FTL::compileStub):
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLOSRExitHandle.cpp: Added.
(JSC::FTL::OSRExitHandle::emitExitThunk):
* ftl/FTLOSRExitHandle.h: Added.
(JSC::FTL::OSRExitHandle::OSRExitHandle):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
(JSC::FTL::State::~State):
2015-12-03 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION:(r192753): Remote Web Inspector: RemoteInspector::sendMessageToRemote with null connection
https://bugs.webkit.org/show_bug.cgi?id=151789
Reviewed by Timothy Hatcher.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::sendMessageToRemote):
Bail if the connection is no longer available. It may have
been closed remotely.
2015-12-03 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION:(r192753): Remote Web Inspector: Window immediately closes after opening
https://bugs.webkit.org/show_bug.cgi?id=151788
Reviewed by Timothy Hatcher.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::pushListingsNow):
The key at the outer level was not a string. Ensure it is a
string for backwards compatibility. One day we may use
non-numeric page identifiers as listing keys.
2015-12-03 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION(r192753): Remote Web Inspector: Enabling Remote Inspection on Auto Inspect candidate Debuggable doesn't show up in debuggers
https://bugs.webkit.org/show_bug.cgi?id=151792
Reviewed by Brian Burg.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
When m_debuggablesMap was split into both m_targetMap and m_listingMap
this particular case was missed in updating both the target and listing
when the target is updated. We should match RemoteInspector::updateTarget
and update the listing map as the debuggable may have changed to be
allowed to debug.
2015-12-03 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add CLZ support to B3
https://bugs.webkit.org/show_bug.cgi?id=151799
Reviewed by Michael Saboff.
Previously we were counting on LLVM to select LZCNT
when its available.
Since we have to do that ourself now, I added feature
detection based on the CPUID. The MacroAssembler just
pick the best available lowering based on the platform.
* assembler/MacroAssemblerX86Common.cpp:
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::countLeadingZeros32):
(JSC::MacroAssemblerX86Common::supportsLZCNT):
(JSC::MacroAssemblerX86Common::clz32AfterBsr):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::countLeadingZeros64):
(JSC::MacroAssemblerX86_64::clz64AfterBsr):
* assembler/X86Assembler.h:
(JSC::X86Assembler::lzcnt_rr):
(JSC::X86Assembler::lzcnt_mr):
(JSC::X86Assembler::lzcntq_rr):
(JSC::X86Assembler::lzcntq_mr):
(JSC::X86Assembler::bsr_mr):
(JSC::X86Assembler::bsrq_rr):
(JSC::X86Assembler::bsrq_mr):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::countLeadingZero):
(JSC::B3::testClzArg64):
(JSC::B3::testClzMem64):
(JSC::B3::testClzArg32):
(JSC::B3::testClzMem32):
(JSC::B3::doubleOperands):
(JSC::B3::run):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::ctlz32):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithClz32):
* ftl/FTLOutput.h:
(JSC::FTL::Output::ctlz32):
2015-12-02 Mark Lam <mark.lam@apple.com>
Polymorphic operand types for DFG and FTL mul.
https://bugs.webkit.org/show_bug.cgi?id=151746
Reviewed by Filip Pizlo.
Perf on benchmarks is neutral except for the newly added JSRegress ftl-object-mul
test which shows a 2.16x speed up on x86_64 FTL, 1.27x speed up on x86_64 DFG,
and 1.56x on x86 DFG.
The speed up comes not from the mul operator itself, but from the fact that the
polymorphic operand types support now allow the test function to run without OSR
exiting, thereby realizing the DFG and FTL's speed up on other work that the test
function does.
This patch has passed the layout tests on x86_64 with a debug build.
It passed the JSC tests with x86 and x86_64 debug builds.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithMul):
* ftl/FTLCompile.cpp:
- Changed to call generateBinaryOpFastPath() instead now, and let it dispatch to
the appropriate snippet generator.
* ftl/FTLCompileBinaryOp.cpp:
(JSC::FTL::generateBinaryArithOpFastPath):
(JSC::FTL::generateBinaryOpFastPath):
(JSC::FTL::generateArithSubFastPath): Deleted.
(JSC::FTL::generateValueAddFastPath): Deleted.
- Refactored these functions to eliminate the need for copy-pasting every time
we add support for another binary arithmetic snippet.
* ftl/FTLCompileBinaryOp.h:
* ftl/FTLInlineCacheDescriptor.h:
* ftl/FTLInlineCacheDescriptorInlines.h:
(JSC::FTL::ArithMulDescriptor::ArithMulDescriptor):
(JSC::FTL::ArithMulDescriptor::icSize):
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfArithMul):
* ftl/FTLInlineCacheSize.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
* jit/JITMulGenerator.h:
(JSC::JITMulGenerator::JITMulGenerator):
* tests/stress/op_mul.js:
- Updated a test value: the interesting value for imminent overflow from an
int32 is 0x7fffffff, not 0x7ffffff.
2015-12-02 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION(r192753): Remote Web Inspector: Applications and Debuggables not showing up in debuggers
https://bugs.webkit.org/show_bug.cgi?id=151787
Reviewed by Brian Burg.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::receivedIndicateMessage):
Removed lock that was unnecessarily added in r192753. It was
protecting nothing.
2015-12-02 Saam barati <sbarati@apple.com>
Insert a FIXME comment FTLLazySlowPath.h to remind us to remove/refactor the ScratchRegisterAllocator field.
Rubber-stamped by Filip Pizlo.
* ftl/FTLLazySlowPath.h:
2015-12-02 Benjamin Poulain <benjamin@webkit.org>
[JSC] Remove insertElement() from FTLB3Output
https://bugs.webkit.org/show_bug.cgi?id=151781
Reviewed by Sam Weinig.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::insertElement): Deleted.
That's a LLVM concept.
2015-12-02 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove stuffs related to alloca from FTLB3Output
https://bugs.webkit.org/show_bug.cgi?id=151780
Reviewed by Mark Lam.
We can use the Phis directly with B3 :)
* ftl/FTLB3Output.h:
(JSC::FTL::Output::alloca): Deleted.
(JSC::FTL::Output::get): Deleted.
(JSC::FTL::Output::set): Deleted.
2015-12-02 Benjamin Poulain <benjamin@webkit.org>
[JSC] Add sin(), cos(), pow() and log() to B3
https://bugs.webkit.org/show_bug.cgi?id=151778
Reviewed by Geoffrey Garen.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doubleSin):
(JSC::FTL::Output::doubleCos):
(JSC::FTL::Output::doublePow):
(JSC::FTL::Output::doubleLog):
(JSC::FTL::Output::callWithoutSideEffects):
2015-12-02 Filip Pizlo <fpizlo@apple.com>
Add a few obvious strength-reductions to Air
https://bugs.webkit.org/show_bug.cgi?id=151777
Reviewed by Mark Lam.
The absence of these optimizations was obnoxious.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::add32): lea 1(reg), reg -> add 1, reg.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate): Emit simpler prologue/epilogue if !frameSize.
* b3/air/AirOpcode.opcodes: We have matching for BranchMul32 with immediate, but we forgot to add the instruction form.
* jit/AssemblyHelpers.h: Support for the prologue/epilogue optimizations.
(JSC::AssemblyHelpers::emitFunctionPrologue):
(JSC::AssemblyHelpers::emitFunctionEpilogueWithEmptyFrame):
(JSC::AssemblyHelpers::emitFunctionEpilogue):
2015-12-02 Benjamin Poulain <bpoulain@apple.com>
Update the interface added in r192967
* b3/B3CCallValue.h:
Filip prefers explicit effects.
* b3/testb3.cpp:
(JSC::B3::testCallSimplePure):
2015-12-02 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add a function attribute for Pure functions in B3
https://bugs.webkit.org/show_bug.cgi?id=151741
Reviewed by Geoffrey Garen.
We have plenty of functions without side effects
when lowering DFG.
This patch adds the "PureCall" flag to B3's CCall
to make sure those functions do not prevent optimizations.
* b3/B3CCallValue.h:
* b3/testb3.cpp:
(JSC::B3::testCallSimplePure):
(JSC::B3::run):
2015-12-02 Mark Lam <mark.lam@apple.com>
Removed unnecessary #if USE(JSVALUE64).
https://bugs.webkit.org/show_bug.cgi?id=151733
Not reviewed.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2015-12-02 Mark Lam <mark.lam@apple.com>
Use the JITAddGenerator snippet in the FTL.
https://bugs.webkit.org/show_bug.cgi?id=151519
Reviewed by Geoffrey Garen.
One detail about how we choosing to handle operands to the binary snippets that
may be constant: the slow path call to a C++ function still needs the constant
operand loaded in a register. To simplify things, we're choosing to always tell
LLVM to load the operands into registers even if they may be constant. However,
even though a constant operand is preloaded in a register, the snippet generator
will not be made aware of it. It will continue to load the constant as an
immediate.
* ftl/FTLCompile.cpp:
* ftl/FTLCompileBinaryOp.cpp:
(JSC::FTL::generateArithSubFastPath):
(JSC::FTL::generateValueAddFastPath):
- generateValueAddFastPath() currently is an exact copy of generateArithSubFastPath()
except that it uses JITAddGenerator instead of JITSubGenerator. When we add
support for JITMulGenerator later, the code will start to vary. We'll refactor
these functions then when we have more insight into what needs to vary between
the implementations.
* ftl/FTLCompileBinaryOp.h:
* ftl/FTLInlineCacheDescriptor.h:
* ftl/FTLInlineCacheDescriptorInlines.h:
(JSC::FTL::ValueAddDescriptor::ValueAddDescriptor):
(JSC::FTL::ValueAddDescriptor::icSize):
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfValueAdd):
* ftl/FTLInlineCacheSize.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
2015-12-02 Mark Lam <mark.lam@apple.com>
Teach DFG that ArithSub can now clobber the heap (and other things).
https://bugs.webkit.org/show_bug.cgi?id=151733
Reviewed by Geoffrey Garen.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
2015-12-02 Benjamin Poulain <bpoulain@apple.com>
[JSC] Handle x86 partial register stalls in Air
https://bugs.webkit.org/show_bug.cgi?id=151735
Reviewed by Filip Pizlo.
This patch adds a primitive false-dependency breaking
algorithm to Air. We look for redefinition of the same
variable that is too close to a partial definition.
There is not explicit dependency tracking going on,
but it is pretty fast and the extra xorps added on false-positives
are cheap anyway.
Typically, partial register stalls appear from instructions
interfering with themselves in small loops. Something like:
Label0:
cvtsi2sdq %eax, %xmm0
...
jmp Label0
Those are correctly detected by propagating the local distance
information from block to block until no unsafe chain is found.
The test testInt32ToDoublePartialRegisterStall() checks the kind
of cases we typically find from JavaScript.
The execution time is 20% faster with a register reset (which is
astounding since the very next instruction has a real dependency).
Future tweaks will be needed when we can run more JavaScript:
-Handle function calls differently.
-Anything with a special can have hidden instructions.
We need to take them into account.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::moveZeroToDouble):
* assembler/X86Assembler.h:
(JSC::X86Assembler::xorps_rr):
(JSC::X86Assembler::xorpd_rr):
According to the documentation, starting with Sandy Bridge,
registers reset can be done in the frontend with xorps.
* b3/B3IndexSet.h:
(JSC::B3::IndexSet::remove):
* b3/air/AirFixPartialRegisterStalls.cpp: Added.
(JSC::B3::Air::fixPartialRegisterStalls):
* b3/air/AirFixPartialRegisterStalls.h: Added.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* b3/testb3.cpp:
(JSC::B3::testInt32ToDoublePartialRegisterStall):
(JSC::B3::run):
* jit/FPRInfo.h:
2015-12-01 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement LLInt/Baseline Support for ES6 Generators and enable this feature
https://bugs.webkit.org/show_bug.cgi?id=150792
Reviewed by Saam Barati.
This patch implements basic functionality of ES6 Generators in LLInt and Baseline tiers.
While the implementation has some inefficient part, the implementation covers edge cases.
Later, we will make this efficient.
https://bugs.webkit.org/show_bug.cgi?id=151545
https://bugs.webkit.org/show_bug.cgi?id=151546
https://bugs.webkit.org/show_bug.cgi?id=151547
https://bugs.webkit.org/show_bug.cgi?id=151552
https://bugs.webkit.org/show_bug.cgi?id=151560
https://bugs.webkit.org/show_bug.cgi?id=151586
To encourage DFG / FTL later, we take the following design.
1. Use switch_imm to jump to the save/resume points.
Instead of saving / restoring instruction pointer to resume from it, we use switch_imm to jump to the resume point.
This limits one entry point to a given generator function. This design makes inlining easy.
The generated code becomes the following.
function @generatorNext(@generator, @generatorState, @generatorValue, @generatorResumeMode)
{
switch (@generatorState) {
case Initial:
...
initial sequence.
...
op_save(Yield_0); // op_save contains *virtual* jump to Yield_0.
// CFG shows a jump edge to Yield_0 point, but it won't be actually used.
return ...;
case Yield_0:
op_resume();
if (@generatorResumeMode == Throw)
...
else if (@generatorResumeMode == Return)
...
...
// sentValue is a value sent from a caller by `generator.next(sentValue)`.
sentValue = @generatorValue;
...
op_save(Yield_1);
return ...;
case Yield_1:
op_resume();
if (@generatorResumeMode == Throw)
...
else if (@generatorResumeMode == Return)
...
...
sentValue = @generatorValue;
...
...
}
}
Resume sequence should not be emitted per yield.
This should be done in https://bugs.webkit.org/show_bug.cgi?id=151552.
2. Store live frame registers to GeneratorFrame
To save and resume generator's state, we save all the live registers in GeneratorFrame.
And when resuming, we refill registers with saved ones.
Since saved register contains scope register, |this| etc., the environment including the scope chain will be recovered automatically.
While saving and resuming callee registers, we don't save parameter registers.
These registers will be used to control generator's resume behavior.
We perform BytecodeLivenessAnalysis in CodeBlock to determine actually *def*ined registers at that resume point.
3. GeneratorFunction will evaluate parameters before generating Generator
Generator's parameter should be evaluated before entering Generator's body. For example,
function hello() { ... }
function *gen(a, b = hello())
{
yield b;
}
let g = gen(20); // Now, hello should be called.
To enable this, we evaluate parameters in GeneratorFunction, and after that, we create a Generator and return it.
This can be explained by the following pseudo code.
function *gen(a, b = hello())
{
// This is generator.
return {
@generatorNext: function (@generator, @generatorState, @generatorValue, @generatorResumeMode)
{
...
}
}
}
4. op_save seems similar to conditional jump
We won't jump to elsewhere from op_save actually. But we add a *virtual* jump edge (flow) from op_save to the point so called *merge point*.
We construct the CFG as follows,
(global generator switch) -> (initial sequence) -> (op_save) ----+-> (merge point) -> (next sequence)*
| | |
| v |
| (op_ret) |
| |
+------------------------------------------->(op_resume)--+
By constructing such a graph,
1. Since we have a flow from (op_save) to (merge point), at merge point, we can *use* locals that are defined before (op_save)
2. op_save should claim that it does not define anything. And claim that it *use*s locals that are used in (merge point).
3. at op_resume, we see *use*d locals at merge point and define all of them.
We can do the above things in use-def analysis because use-def analysis is backward analysis.
And after analyzing use-def chains, in op_save / op_resume, we only save / resume live registers at the head of merge point.
* API/JSScriptRef.cpp:
(parseScript):
* CMakeLists.txt:
* Configurations/FeatureDefines.xcconfig:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinExecutables.cpp:
(JSC::createExecutableInternal):
* builtins/GeneratorPrototype.js: Added.
(generatorResume):
(next):
(return):
(throw):
* bytecode/BytecodeBasicBlock.cpp:
(JSC::isBranch):
* bytecode/BytecodeList.json:
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::stepOverInstruction):
(JSC::computeLocalLivenessForBytecodeOffset):
(JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
(JSC::BytecodeLivenessAnalysis::computeFullLiveness):
(JSC::BytecodeLivenessAnalysis::computeKills):
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::shrinkToFit):
(JSC::CodeBlock::validate):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numCalleeLocals):
(JSC::CodeBlock::liveCalleeLocalsAtYield):
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::tryGet):
(JSC::EvalCodeCache::getSlow):
(JSC::EvalCodeCache::isCacheable):
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::generatorThisMode):
(JSC::ExecutableInfo::superBinding):
(JSC::ExecutableInfo::parseMode):
(JSC::ExecutableInfo::isArrowFunction): Deleted.
* bytecode/PreciseJumpTargets.cpp:
(JSC::getJumpTargetsForBytecodeOffset):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::parseMode):
(JSC::UnlinkedCodeBlock::generatorThisMode):
(JSC::UnlinkedCodeBlock::superBinding):
(JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeParameters):
(JSC::BytecodeGenerator::newRegister):
(JSC::BytecodeGenerator::reclaimFreeRegisters):
(JSC::BytecodeGenerator::createVariable):
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewFunctionExpression):
(JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
(JSC::BytecodeGenerator::emitNewFunction):
(JSC::BytecodeGenerator::emitIteratorNextWithValue):
(JSC::BytecodeGenerator::emitYieldPoint):
(JSC::BytecodeGenerator::emitSave):
(JSC::BytecodeGenerator::emitResume):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitGeneratorStateChange):
(JSC::BytecodeGenerator::emitGeneratorStateLabel):
(JSC::BytecodeGenerator::beginGenerator):
(JSC::BytecodeGenerator::endGenerator):
(JSC::BytecodeGenerator::emitNewFunctionInternal): Deleted.
(JSC::BytecodeGenerator::emitNewFunctionCommon): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::generatorThisMode):
(JSC::BytecodeGenerator::superBinding):
(JSC::BytecodeGenerator::generatorRegister):
(JSC::BytecodeGenerator::generatorStateRegister):
(JSC::BytecodeGenerator::generatorValueRegister):
(JSC::BytecodeGenerator::generatorResumeModeRegister):
(JSC::BytecodeGenerator::parseMode):
(JSC::BytecodeGenerator::registerFor):
(JSC::BytecodeGenerator::makeFunction):
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
(JSC::emitHomeObjectForCallee):
(JSC::emitSuperBaseForCallee):
(JSC::ReturnNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
(JSC::YieldExprNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::ByteCodeParser):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKilledOperands):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::forAllLocalsLiveInBytecode):
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::OSREntrypointCreationPhase::run):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct):
* ftl/FTLForOSREntryJITCode.cpp:
(JSC::FTL::ForOSREntryJITCode::initializeEntryBuffer):
* ftl/FTLForOSREntryJITCode.h:
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::isAtom):
(JSC::MarkedBlock::isLiveCell):
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::Interpreter::dumpRegisters):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::frameRegisterCountFor):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emitNewFuncCommon):
(JSC::JIT::emit_op_new_func):
(JSC::JIT::emit_op_new_generator_func):
(JSC::JIT::emitNewFuncExprCommon):
(JSC::JIT::emit_op_new_func_exp):
(JSC::JIT::emit_op_new_generator_func_exp):
(JSC::JIT::emit_op_save):
(JSC::JIT::emit_op_resume):
* jit/JITOperations.cpp:
(JSC::operationNewFunctionCommon):
* jit/JITOperations.h:
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::frameRegisterCountFor):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::traceFunctionPrologue):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createYield):
(JSC::ASTBuilder::createFunctionMetadata):
(JSC::ASTBuilder::propagateArgumentsUse):
* parser/Nodes.cpp:
(JSC::FunctionMetadataNode::FunctionMetadataNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::stringForFunctionMode):
(JSC::Parser<LexerType>::createGeneratorParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseYieldExpression):
(JSC::Parser<LexerType>::parsePropertyMethod):
(JSC::Parser<LexerType>::parseFunctionExpression):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::setSourceParseMode):
(JSC::Scope::hasArguments):
(JSC::Scope::collectFreeVariables):
(JSC::Scope::setIsFunction):
(JSC::Scope::setIsGeneratorFunction):
(JSC::Scope::setIsGenerator):
(JSC::parse):
* parser/ParserModes.h:
(JSC::isFunctionParseMode):
(JSC::isModuleParseMode):
(JSC::isProgramParseMode):
* parser/SourceCodeKey.h: Added.
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::isHashTableDeletedValue):
(JSC::SourceCodeKey::hash):
(JSC::SourceCodeKey::length):
(JSC::SourceCodeKey::isNull):
(JSC::SourceCodeKey::string):
(JSC::SourceCodeKey::operator==):
(JSC::SourceCodeKeyHash::hash):
(JSC::SourceCodeKeyHash::equal):
(JSC::SourceCodeKeyHashTraits::isEmptyValue):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createYield):
(JSC::SyntaxChecker::createFunctionMetadata):
(JSC::SyntaxChecker::operatorStackPop):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
(JSC::SourceCodeKey::SourceCodeKey): Deleted.
(JSC::SourceCodeKey::isHashTableDeletedValue): Deleted.
(JSC::SourceCodeKey::hash): Deleted.
(JSC::SourceCodeKey::length): Deleted.
(JSC::SourceCodeKey::isNull): Deleted.
(JSC::SourceCodeKey::string): Deleted.
(JSC::SourceCodeKey::operator==): Deleted.
(JSC::SourceCodeKeyHash::hash): Deleted.
(JSC::SourceCodeKeyHash::equal): Deleted.
(JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted.
* runtime/CommonIdentifiers.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/Completion.cpp:
(JSC::checkSyntax):
(JSC::checkModuleSyntax):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ProgramExecutable::checkSyntax):
* runtime/Executable.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionConstructor.h:
* runtime/GeneratorFrame.cpp: Added.
(JSC::GeneratorFrame::GeneratorFrame):
(JSC::GeneratorFrame::finishCreation):
(JSC::GeneratorFrame::createStructure):
(JSC::GeneratorFrame::create):
(JSC::GeneratorFrame::save):
(JSC::GeneratorFrame::resume):
(JSC::GeneratorFrame::visitChildren):
* runtime/GeneratorFrame.h: Added.
(JSC::GeneratorFrame::locals):
(JSC::GeneratorFrame::localAt):
(JSC::GeneratorFrame::offsetOfLocals):
(JSC::GeneratorFrame::allocationSizeForLocals):
* runtime/GeneratorFunctionConstructor.cpp: Added.
(JSC::GeneratorFunctionConstructor::GeneratorFunctionConstructor):
(JSC::GeneratorFunctionConstructor::finishCreation):
(JSC::callGeneratorFunctionConstructor):
(JSC::constructGeneratorFunctionConstructor):
(JSC::GeneratorFunctionConstructor::getCallData):
(JSC::GeneratorFunctionConstructor::getConstructData):
* runtime/GeneratorFunctionConstructor.h: Added.
(JSC::GeneratorFunctionConstructor::create):
(JSC::GeneratorFunctionConstructor::createStructure):
* runtime/GeneratorFunctionPrototype.cpp: Added.
(JSC::GeneratorFunctionPrototype::GeneratorFunctionPrototype):
(JSC::GeneratorFunctionPrototype::finishCreation):
* runtime/GeneratorFunctionPrototype.h: Added.
(JSC::GeneratorFunctionPrototype::create):
(JSC::GeneratorFunctionPrototype::createStructure):
* runtime/GeneratorPrototype.cpp: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
(JSC::GeneratorPrototype::finishCreation):
(JSC::GeneratorPrototype::getOwnPropertySlot):
* runtime/GeneratorPrototype.h: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
(JSC::GeneratorPrototype::create):
(JSC::GeneratorPrototype::createStructure):
(JSC::GeneratorPrototype::GeneratorPrototype):
* runtime/GeneratorThisMode.h: Added.
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot):
* runtime/JSGeneratorFunction.cpp: Added.
(JSC::JSGeneratorFunction::JSGeneratorFunction):
(JSC::JSGeneratorFunction::createImpl):
(JSC::JSGeneratorFunction::create):
(JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
* runtime/JSGeneratorFunction.h: Added.
(JSC::JSGeneratorFunction::allocationSize):
(JSC::JSGeneratorFunction::createStructure):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::generatorFunctionPrototype):
(JSC::JSGlobalObject::generatorPrototype):
(JSC::JSGlobalObject::generatorFunctionStructure):
* runtime/ModuleLoaderObject.cpp:
(JSC::moduleLoaderObjectParseModule):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* tests/es6.yaml:
* tests/es6/generators_yield_star_generic_iterables.js:
(iterator.next):
(iterable.Symbol.iterator):
(__createIterableObject):
* tests/es6/generators_yield_star_instances_of_iterables.js:
(iterator.next):
(iterable.Symbol.iterator):
(__createIterableObject):
* tests/es6/generators_yield_star_iterator_closing.js:
(iterator.next):
(iterable.Symbol.iterator):
(__createIterableObject):
* tests/es6/generators_yield_star_iterator_closing_via_throw.js:
(iterator.next):
(iterable.Symbol.iterator):
(__createIterableObject):
* tests/stress/generator-arguments-from-function.js: Added.
(shouldBe):
(test):
* tests/stress/generator-arguments.js: Added.
(shouldBe):
(g1):
* tests/stress/generator-class-methods-syntax.js: Added.
(testSyntax):
(testSyntaxError):
(testSyntaxError.Cocoa):
(testSyntax.Cocoa.prototype.ok):
(testSyntax.Cocoa):
(testSyntax.Cocoa.ok):
* tests/stress/generator-class-methods.js: Added.
(shouldBe):
(prototype.gen):
(staticGen):
(shouldBe.g.next):
* tests/stress/generator-eval-this.js: Added.
(shouldBe):
(shouldThrow):
(B):
(A):
(C.prototype.generator):
(C):
(TypeError):
* tests/stress/generator-function-constructor.js: Added.
(shouldBe):
(generatorFunctionConstructor):
* tests/stress/generator-function-name.js: Added.
(shouldBe):
(ok):
* tests/stress/generator-methods-with-non-generator.js: Added.
(shouldThrow):
* tests/stress/generator-relations.js: Added.
(shouldBe):
(generatorFunction):
* tests/stress/generator-return-before-first-call.js: Added.
(shouldBe):
(shouldBeIteratorResult):
* tests/stress/generator-return.js: Added.
(shouldBe):
(shouldBeIteratorResult):
* tests/stress/generator-this.js: Added.
(shouldBe):
(shouldThrow):
(gen):
(shouldBe.g.next):
* tests/stress/generator-throw-before-first-call.js: Added.
(unreachable):
(gen):
(catch):
* tests/stress/generator-throw.js: Added.
(shouldBe):
(shouldBeIteratorResult):
* tests/stress/generator-with-new-target.js: Added.
(shouldBe):
(gen):
* tests/stress/generator-with-super.js: Added.
(shouldThrow):
(test):
(B.prototype.gen):
(B):
(A.prototype.gen):
(A):
* tests/stress/generator-yield-star.js: Added.
(shouldBe):
(shouldThrow):
(prototype.call):
(Arrays):
(Arrays.prototype.Symbol.iterator):
(Iterator.prototype.next):
(Iterator.prototype.string_appeared_here):
(Iterator.prototype.Symbol.iterator):
(Iterator):
(gen):
2015-12-01 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r192914.
https://bugs.webkit.org/show_bug.cgi?id=151734
JSC tests for this change are failing on 32 and 64-bit bots
(Requested by ryanhaddad on #webkit).
Reverted changeset:
"[ES6] Implement LLInt/Baseline Support for ES6 Generators and
enable this feature"
https://bugs.webkit.org/show_bug.cgi?id=150792
http://trac.webkit.org/changeset/192914
2015-12-01 Caitlin Potter <caitpotter88@gmail.com>
[JSC] support CoverInitializedName in nested AssignmentPatterns
https://bugs.webkit.org/show_bug.cgi?id=151595
Reviewed by Geoffrey Garen.
A regression introduced in bug https://bugs.webkit.org/show_bug.cgi?id=151026
causes the parser to fail when attempting to parse nested
ObjectAssignmentPatterns with CoverInitializedName destructuring targets.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpressionOrPropagateErrorClass):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parseArrayLiteral):
* parser/Parser.h:
(JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
* tests/es6.yaml:
* tests/es6/destructuring_assignment_nested_cover_initialized_name.js: Added.
(test1):
(test2):
2015-12-01 Juergen Ributzka <juergen@apple.com>
Add new library dependency for LLVMForJavaScriptCore dylib
https://bugs.webkit.org/show_bug.cgi?id=151687
Changes on open source LLVM added a new dependency to libLLVMInstrumentation.a.
Adding this dependency should be backwards compatible, since LLVM has built and
shipped this library even before the creation of FTL.
Reviewed by Geoffrey Garen.
* Configurations/LLVMForJSC.xcconfig:
2015-12-01 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement LLInt/Baseline Support for ES6 Generators and enable this feature
https://bugs.webkit.org/show_bug.cgi?id=150792
Reviewed by Saam Barati.
This patch implements basic functionality of ES6 Generators in LLInt and Baseline tiers.
While the implementation has some inefficient part, the implementation covers edge cases.
Later, we will make this efficient.
https://bugs.webkit.org/show_bug.cgi?id=151545
https://bugs.webkit.org/show_bug.cgi?id=151546
https://bugs.webkit.org/show_bug.cgi?id=151547
https://bugs.webkit.org/show_bug.cgi?id=151552
https://bugs.webkit.org/show_bug.cgi?id=151560
https://bugs.webkit.org/show_bug.cgi?id=151586
To encourage DFG / FTL later, we take the following design.
1. Use switch_imm to jump to the save/resume points.
Instead of saving / restoring instruction pointer to resume from it, we use switch_imm to jump to the resume point.
This limits one entry point to a given generator function. This design makes inlining easy.
The generated code becomes the following.
function @generatorNext(@generator, @generatorState, @generatorValue, @generatorResumeMode)
{
switch (@generatorState) {
case Initial:
...
initial sequence.
...
op_save(Yield_0); // op_save contains *virtual* jump to Yield_0.
// CFG shows a jump edge to Yield_0 point, but it won't be actually used.
return ...;
case Yield_0:
op_resume();
if (@generatorResumeMode == Throw)
...
else if (@generatorResumeMode == Return)
...
...
// sentValue is a value sent from a caller by `generator.next(sentValue)`.
sentValue = @generatorValue;
...
op_save(Yield_1);
return ...;
case Yield_1:
op_resume();
if (@generatorResumeMode == Throw)
...
else if (@generatorResumeMode == Return)
...
...
sentValue = @generatorValue;
...
...
}
}
Resume sequence should not be emitted per yield.
This should be done in https://bugs.webkit.org/show_bug.cgi?id=151552.
2. Store live frame registers to GeneratorFrame
To save and resume generator's state, we save all the live registers in GeneratorFrame.
And when resuming, we refill registers with saved ones.
Since saved register contains scope register, |this| etc., the environment including the scope chain will be recovered automatically.
While saving and resuming callee registers, we don't save parameter registers.
These registers will be used to control generator's resume behavior.
We perform BytecodeLivenessAnalysis in CodeBlock to determine actually *def*ined registers at that resume point.
3. GeneratorFunction will evaluate parameters before generating Generator
Generator's parameter should be evaluated before entering Generator's body. For example,
function hello() { ... }
function *gen(a, b = hello())
{
yield b;
}
let g = gen(20); // Now, hello should be called.
To enable this, we evaluate parameters in GeneratorFunction, and after that, we create a Generator and return it.
This can be explained by the following pseudo code.
function *gen(a, b = hello())
{
// This is generator.
return {
@generatorNext: function (@generator, @generatorState, @generatorValue, @generatorResumeMode)
{
...
}
}
}
4. op_save seems similar to conditional jump
We won't jump to elsewhere from op_save actually. But we add a *virtual* jump edge (flow) from op_save to the point so called *merge point*.
We construct the CFG as follows,
(global generator switch) -> (initial sequence) -> (op_save) ----+-> (merge point) -> (next sequence)*
| | |
| v |
| (op_ret) |
| |
+------------------------------------------->(op_resume)--+
By constructing such a graph,
1. Since we have a flow from (op_save) to (merge point), at merge point, we can *use* locals that are defined before (op_save)
2. op_save should claim that it does not define anything. And claim that it *use*s locals that are used in (merge point).
3. at op_resume, we see *use*d locals at merge point and define all of them.
We can do the above things in use-def analysis because use-def analysis is backward analysis.
And after analyzing use-def chains, in op_save / op_resume, we only save / resume live registers at the head of merge point.
* API/JSScriptRef.cpp:
(parseScript):
* CMakeLists.txt:
* Configurations/FeatureDefines.xcconfig:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinExecutables.cpp:
(JSC::createExecutableInternal):
* builtins/GeneratorPrototype.js: Added.
(generatorResume):
(next):
(return):
(throw):
* bytecode/BytecodeBasicBlock.cpp:
(JSC::isBranch):
* bytecode/BytecodeList.json:
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::stepOverInstruction):
(JSC::computeLocalLivenessForBytecodeOffset):
(JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
(JSC::BytecodeLivenessAnalysis::computeFullLiveness):
(JSC::BytecodeLivenessAnalysis::computeKills):
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::shrinkToFit):
(JSC::CodeBlock::validate):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numCalleeLocals):
(JSC::CodeBlock::liveCalleeLocalsAtYield):
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::tryGet):
(JSC::EvalCodeCache::getSlow):
(JSC::EvalCodeCache::isCacheable):
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::generatorThisMode):
(JSC::ExecutableInfo::superBinding):
(JSC::ExecutableInfo::parseMode):
(JSC::ExecutableInfo::isArrowFunction): Deleted.
* bytecode/PreciseJumpTargets.cpp:
(JSC::getJumpTargetsForBytecodeOffset):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::parseMode):
(JSC::UnlinkedCodeBlock::generatorThisMode):
(JSC::UnlinkedCodeBlock::superBinding):
(JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeParameters):
(JSC::BytecodeGenerator::newRegister):
(JSC::BytecodeGenerator::reclaimFreeRegisters):
(JSC::BytecodeGenerator::createVariable):
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewFunctionExpression):
(JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
(JSC::BytecodeGenerator::emitNewFunction):
(JSC::BytecodeGenerator::emitIteratorNextWithValue):
(JSC::BytecodeGenerator::emitYieldPoint):
(JSC::BytecodeGenerator::emitSave):
(JSC::BytecodeGenerator::emitResume):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitGeneratorStateChange):
(JSC::BytecodeGenerator::emitGeneratorStateLabel):
(JSC::BytecodeGenerator::beginGenerator):
(JSC::BytecodeGenerator::endGenerator):
(JSC::BytecodeGenerator::emitNewFunctionInternal): Deleted.
(JSC::BytecodeGenerator::emitNewFunctionCommon): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::generatorThisMode):
(JSC::BytecodeGenerator::superBinding):
(JSC::BytecodeGenerator::generatorRegister):
(JSC::BytecodeGenerator::generatorStateRegister):
(JSC::BytecodeGenerator::generatorValueRegister):
(JSC::BytecodeGenerator::generatorResumeModeRegister):
(JSC::BytecodeGenerator::parseMode):
(JSC::BytecodeGenerator::registerFor):
(JSC::BytecodeGenerator::makeFunction):
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
(JSC::emitHomeObjectForCallee):
(JSC::emitSuperBaseForCallee):
(JSC::ReturnNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
(JSC::YieldExprNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::ByteCodeParser):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKilledOperands):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::forAllLocalsLiveInBytecode):
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::OSREntrypointCreationPhase::run):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct):
* ftl/FTLForOSREntryJITCode.cpp:
(JSC::FTL::ForOSREntryJITCode::initializeEntryBuffer):
* ftl/FTLForOSREntryJITCode.h:
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::isAtom):
(JSC::MarkedBlock::isLiveCell):
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::Interpreter::dumpRegisters):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::frameRegisterCountFor):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emitNewFuncCommon):
(JSC::JIT::emit_op_new_func):
(JSC::JIT::emit_op_new_generator_func):
(JSC::JIT::emitNewFuncExprCommon):
(JSC::JIT::emit_op_new_func_exp):
(JSC::JIT::emit_op_new_generator_func_exp):
(JSC::JIT::emit_op_save):
(JSC::JIT::emit_op_resume):
* jit/JITOperations.cpp:
(JSC::operationNewFunctionCommon):
* jit/JITOperations.h:
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::frameRegisterCountFor):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::traceFunctionPrologue):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createYield):
(JSC::ASTBuilder::createFunctionMetadata):
(JSC::ASTBuilder::propagateArgumentsUse):
* parser/Nodes.cpp:
(JSC::FunctionMetadataNode::FunctionMetadataNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::stringForFunctionMode):
(JSC::Parser<LexerType>::createGeneratorParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseYieldExpression):
(JSC::Parser<LexerType>::parsePropertyMethod):
(JSC::Parser<LexerType>::parseFunctionExpression):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::setSourceParseMode):
(JSC::Scope::hasArguments):
(JSC::Scope::collectFreeVariables):
(JSC::Scope::setIsFunction):
(JSC::Scope::setIsGeneratorFunction):
(JSC::Scope::setIsGenerator):
(JSC::parse):
* parser/ParserModes.h:
(JSC::isFunctionParseMode):
(JSC::isModuleParseMode):
(JSC::isProgramParseMode):
* parser/SourceCodeKey.h: Added.
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::isHashTableDeletedValue):
(JSC::SourceCodeKey::hash):
(JSC::SourceCodeKey::length):
(JSC::SourceCodeKey::isNull):
(JSC::SourceCodeKey::string):
(JSC::SourceCodeKey::operator==):
(JSC::SourceCodeKeyHash::hash):
(JSC::SourceCodeKeyHash::equal):
(JSC::SourceCodeKeyHashTraits::isEmptyValue):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createYield):
(JSC::SyntaxChecker::createFunctionMetadata):
(JSC::SyntaxChecker::operatorStackPop):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
(JSC::SourceCodeKey::SourceCodeKey): Deleted.
(JSC::SourceCodeKey::isHashTableDeletedValue): Deleted.
(JSC::SourceCodeKey::hash): Deleted.
(JSC::SourceCodeKey::length): Deleted.
(JSC::SourceCodeKey::isNull): Deleted.
(JSC::SourceCodeKey::string): Deleted.
(JSC::SourceCodeKey::operator==): Deleted.
(JSC::SourceCodeKeyHash::hash): Deleted.
(JSC::SourceCodeKeyHash::equal): Deleted.
(JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted.
* runtime/CommonIdentifiers.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/Completion.cpp:
(JSC::checkSyntax):
(JSC::checkModuleSyntax):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ProgramExecutable::checkSyntax):
* runtime/Executable.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionConstructor.h:
* runtime/GeneratorFrame.cpp: Added.
(JSC::GeneratorFrame::GeneratorFrame):
(JSC::GeneratorFrame::finishCreation):
(JSC::GeneratorFrame::createStructure):
(JSC::GeneratorFrame::create):
(JSC::GeneratorFrame::save):
(JSC::GeneratorFrame::resume):
(JSC::GeneratorFrame::visitChildren):
* runtime/GeneratorFrame.h: Added.
(JSC::GeneratorFrame::locals):
(JSC::GeneratorFrame::localAt):
(JSC::GeneratorFrame::offsetOfLocals):
(JSC::GeneratorFrame::allocationSizeForLocals):
* runtime/GeneratorFunctionConstructor.cpp: Added.
(JSC::GeneratorFunctionConstructor::GeneratorFunctionConstructor):
(JSC::GeneratorFunctionConstructor::finishCreation):
(JSC::callGeneratorFunctionConstructor):
(JSC::constructGeneratorFunctionConstructor):
(JSC::GeneratorFunctionConstructor::getCallData):
(JSC::GeneratorFunctionConstructor::getConstructData):
* runtime/GeneratorFunctionConstructor.h: Added.
(JSC::GeneratorFunctionConstructor::create):
(JSC::GeneratorFunctionConstructor::createStructure):
* runtime/GeneratorFunctionPrototype.cpp: Added.
(JSC::GeneratorFunctionPrototype::GeneratorFunctionPrototype):
(JSC::GeneratorFunctionPrototype::finishCreation):
* runtime/GeneratorFunctionPrototype.h: Added.
(JSC::GeneratorFunctionPrototype::create):
(JSC::GeneratorFunctionPrototype::createStructure):
* runtime/GeneratorPrototype.cpp: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
(JSC::GeneratorPrototype::finishCreation):
(JSC::GeneratorPrototype::getOwnPropertySlot):
* runtime/GeneratorPrototype.h: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
(JSC::GeneratorPrototype::create):
(JSC::GeneratorPrototype::createStructure):
(JSC::GeneratorPrototype::GeneratorPrototype):
* runtime/GeneratorThisMode.h: Added.
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot):
* runtime/JSGeneratorFunction.cpp: Added.
(JSC::JSGeneratorFunction::JSGeneratorFunction):
(JSC::JSGeneratorFunction::createImpl):
(JSC::JSGeneratorFunction::create):
(JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
* runtime/JSGeneratorFunction.h: Added.
(JSC::JSGeneratorFunction::allocationSize):
(JSC::JSGeneratorFunction::createStructure):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::generatorFunctionPrototype):
(JSC::JSGlobalObject::generatorPrototype):
(JSC::JSGlobalObject::generatorFunctionStructure):
* runtime/ModuleLoaderObject.cpp:
(JSC::moduleLoaderObjectParseModule):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* tests/es6.yaml:
* tests/es6/generators_yield_star_generic_iterables.js:
(iterator.next):
(iterable.Symbol.iterator):
(__createIterableObject):
* tests/es6/generators_yield_star_instances_of_iterables.js:
(iterator.next):
(iterable.Symbol.iterator):
(__createIterableObject):
* tests/es6/generators_yield_star_iterator_closing.js:
(iterator.next):
(iterable.Symbol.iterator):
(__createIterableObject):
* tests/es6/generators_yield_star_iterator_closing_via_throw.js:
(iterator.next):
(iterable.Symbol.iterator):
(__createIterableObject):
* tests/stress/generator-arguments-from-function.js: Added.
(shouldBe):
(test):
* tests/stress/generator-arguments.js: Added.
(shouldBe):
(g1):
* tests/stress/generator-class-methods-syntax.js: Added.
(testSyntax):
(testSyntaxError):
(testSyntaxError.Cocoa):
(testSyntax.Cocoa.prototype.ok):
(testSyntax.Cocoa):
(testSyntax.Cocoa.ok):
* tests/stress/generator-class-methods.js: Added.
(shouldBe):
(prototype.gen):
(staticGen):
(shouldBe.g.next):
* tests/stress/generator-eval-this.js: Added.
(shouldBe):
(shouldThrow):
(B):
(A):
(C.prototype.generator):
(C):
(TypeError):
* tests/stress/generator-function-constructor.js: Added.
(shouldBe):
(generatorFunctionConstructor):
* tests/stress/generator-function-name.js: Added.
(shouldBe):
(ok):
* tests/stress/generator-methods-with-non-generator.js: Added.
(shouldThrow):
* tests/stress/generator-relations.js: Added.
(shouldBe):
(generatorFunction):
* tests/stress/generator-return-before-first-call.js: Added.
(shouldBe):
(shouldBeIteratorResult):
* tests/stress/generator-return.js: Added.
(shouldBe):
(shouldBeIteratorResult):
* tests/stress/generator-this.js: Added.
(shouldBe):
(shouldThrow):
(gen):
(shouldBe.g.next):
* tests/stress/generator-throw-before-first-call.js: Added.
(unreachable):
(gen):
(catch):
* tests/stress/generator-throw.js: Added.
(shouldBe):
(shouldBeIteratorResult):
* tests/stress/generator-with-new-target.js: Added.
(shouldBe):
(gen):
* tests/stress/generator-with-super.js: Added.
(shouldThrow):
(test):
(B.prototype.gen):
(B):
(A.prototype.gen):
(A):
* tests/stress/generator-yield-star.js: Added.
(shouldBe):
(shouldThrow):
(prototype.call):
(Arrays):
(Arrays.prototype.Symbol.iterator):
(Iterator.prototype.next):
(Iterator.prototype.string_appeared_here):
(Iterator.prototype.Symbol.iterator):
(Iterator):
(gen):
2015-12-01 Filip Pizlo <fpizlo@apple.com>
Remove repetitive cruft from FTL OSR exit code in LowerDFGToLLVM
https://bugs.webkit.org/show_bug.cgi?id=151718
Reviewed by Geoffrey Garen.
* b3/B3StackmapValue.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
(JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
(JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
2015-12-01 Caitlin Potter <caitp@igalia.com>
[JSC] add missing RequireObjectCoercible() step in destructuring
https://bugs.webkit.org/show_bug.cgi?id=151596
Reviewed by Darin Adler.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitRequireObjectCoercible):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::bindValue):
* tests/stress/destructuring-assignment-require-object-coercible.js: Added.
(testTypeError):
(testOK):
2015-12-01 Mark Lam <mark.lam@apple.com>
Refactor FTL sub snippet code to support general binary op snippets.
https://bugs.webkit.org/show_bug.cgi?id=151706
Reviewed by Geoffrey Garen.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLCompile.cpp:
- Moved the BinarySnippetRegisterContext to FTLCompileBinaryOp.cpp verbatim.
- Generalize generateArithSubICFastPath() to generateBinaryOpICFastPath().
It now uses snippet specific helpers in FTLCompileBinaryOp.cpp to generate
the fast paths.
* ftl/FTLCompileBinaryOp.cpp: Added.
(JSC::FTL::BinarySnippetRegisterContext::BinarySnippetRegisterContext):
(JSC::FTL::BinarySnippetRegisterContext::initializeRegisters):
(JSC::FTL::BinarySnippetRegisterContext::restoreRegisters):
- Moved here without changed from FTLCompile.cpp.
(JSC::FTL::generateArithSubFastPath):
* ftl/FTLCompileBinaryOp.h: Added.
* ftl/FTLInlineCacheDescriptor.h:
(JSC::FTL::BinaryOpDescriptor::nodeType):
(JSC::FTL::BinaryOpDescriptor::size):
(JSC::FTL::BinaryOpDescriptor::name):
(JSC::FTL::BinaryOpDescriptor::fastPathICName):
(JSC::FTL::BinaryOpDescriptor::slowPathFunction):
(JSC::FTL::BinaryOpDescriptor::leftOperand):
(JSC::FTL::BinaryOpDescriptor::rightOperand):
(JSC::FTL::BinaryOpDescriptor::BinaryOpDescriptor):
(JSC::FTL::ArithSubDescriptor::ArithSubDescriptor): Deleted.
(JSC::FTL::ArithSubDescriptor::leftType): Deleted.
(JSC::FTL::ArithSubDescriptor::rightType): Deleted.
- Refactor ArithSubDescriptor into BinaryOpDescriptor, and re-add a sub-class
ArithSubDescriptor as specializations of BinaryOpDescriptor.
* ftl/FTLInlineCacheDescriptorInlines.h: Added.
(JSC::FTL::ArithSubDescriptor::ArithSubDescriptor):
(JSC::FTL::ArithSubDescriptor::icSize):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
(JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
* ftl/FTLOSRExit.h:
* ftl/FTLState.h:
2015-12-01 Carlos Garcia Campos <cgarcia@igalia.com>
Unreviewed, rolling out r192876.
It broke a lot of JSC and layout tests for GTK and EFL
Reverted changeset:
"[ES6] "super" and "this" should be lexically bound inside an
arrow function and should live in a JSLexicalEnvironment"
https://bugs.webkit.org/show_bug.cgi?id=149338
http://trac.webkit.org/changeset/192876
2015-12-01 Aleksandr Skachkov <gskachkov@gmail.com>
[ES6] "super" and "this" should be lexically bound inside an arrow function and should live in a JSLexicalEnvironment
https://bugs.webkit.org/show_bug.cgi?id=149338
Reviewed by Saam Barati.
Implemented new version of the lexically bound 'this' in arrow function. In current version
'this' is stored inside of the lexical environment of the function. To store and load we use
op_get_from_scope and op_put_to_scope operations. Also new implementation prevent raising TDZ
error for arrow functions that are declared before super() but invoke after.
* builtins/BuiltinExecutables.cpp:
(JSC::createExecutableInternal):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::getSlow):
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::isDerivedConstructorContext):
(JSC::ExecutableInfo::isArrowFunctionContext):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::isDerivedConstructorContext):
(JSC::UnlinkedCodeBlock::isArrowFunctionContext):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
(JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
(JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::isDerivedConstructorContext):
(JSC::BytecodeGenerator::usesArrowFunction):
(JSC::BytecodeGenerator::needsToUpdateArrowFunctionContext):
(JSC::BytecodeGenerator::usesEval):
(JSC::BytecodeGenerator::usesThis):
(JSC::BytecodeGenerator::newTarget):
(JSC::BytecodeGenerator::makeFunction):
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
(JSC::SuperNode::emitBytecode):
(JSC::EvalFunctionCallNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluate):
* dfg/DFGAbstractInterpreterInlines.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
* dfg/DFGClobberize.h:
* dfg/DFGDoesGC.cpp:
* dfg/DFGFixupPhase.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGPromotedHeapLocation.cpp:
* dfg/DFGPromotedHeapLocation.h:
* dfg/DFGSafeToExecute.h:
* dfg/DFGSpeculativeJIT.cpp:
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
* dfg/DFGSpeculativeJIT64.cpp:
* ftl/FTLCapabilities.cpp:
* ftl/FTLLowerDFGToLLVM.cpp:
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* interpreter/Interpreter.cpp:
(JSC::eval):
* jit/JIT.cpp:
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emitNewFuncExprCommon):
* jit/JITOpcodes32_64.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createArrowFunctionExpr):
(JSC::ASTBuilder::usesArrowFunction):
* parser/Nodes.h:
(JSC::ScopeNode::usesArrowFunction):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/ParserModes.h:
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getModuleProgramCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/CommonIdentifiers.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::EvalExecutable::create):
(JSC::EvalExecutable::EvalExecutable):
(JSC::ProgramExecutable::ProgramExecutable):
(JSC::ModuleProgramExecutable::ModuleProgramExecutable):
(JSC::FunctionExecutable::FunctionExecutable):
* runtime/Executable.h:
(JSC::ScriptExecutable::isArrowFunctionContext):
(JSC::ScriptExecutable::isDerivedConstructorContext):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createEvalCodeBlock):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* tests/es6.yaml:
* tests/stress/arrowfunction-activation-sink-osrexit.js:
* tests/stress/arrowfunction-activation-sink.js:
* tests/stress/arrowfunction-lexical-bind-newtarget.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-1.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-2.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-3.js: Added.
* tests/stress/arrowfunction-lexical-bind-supercall-4.js: Added.
* tests/stress/arrowfunction-lexical-bind-this-1.js:
* tests/stress/arrowfunction-lexical-bind-this-7.js: Added.
* tests/stress/arrowfunction-tdz-1.js: Added.
* tests/stress/arrowfunction-tdz-2.js: Added.
* tests/stress/arrowfunction-tdz-3.js: Added.
* tests/stress/arrowfunction-tdz-4.js: Added.
* tests/stress/arrowfunction-tdz.js: Removed.
2015-12-01 Youenn Fablet <youenn.fablet@crf.canon.fr>
[Streams API] streams should not directly use Number and related methods
https://bugs.webkit.org/show_bug.cgi?id=151499
Reviewed by Darin Adler.
* runtime/CommonIdentifiers.h: Adding isNaN as private symbol.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Adding @isNaN function.
2015-12-01 Csaba Osztrogonác <ossy@webkit.org>
Don't hide the argument name inside for block in AirIteratedRegisterCoalescing.cpp
https://bugs.webkit.org/show_bug.cgi?id=151622
Reviewed by Darin Adler.
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):
2015-12-01 Youenn Fablet <youenn.fablet@crf.canon.fr>
[Streams API] Remove use of @catch for exposed promises
https://bugs.webkit.org/show_bug.cgi?id=151625
Reviewed by Darin Adler.
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::addOwnInternalSlots): Removing @catch from the prototype as it is not safe.
2015-11-30 Filip Pizlo <fpizlo@apple.com>
B3::ValueRep::Any should translate into a Arg::ColdUse role in Air
https://bugs.webkit.org/show_bug.cgi?id=151174
Reviewed by Geoffrey Garen and Benjamin Poulain.
This teaches the register allocator that it should pick spills based on whichever tmp has the
highest score:
score(tmp) = degree(tmp) / sum(for each use of tmp, block->frequency)
In other words, the numerator is the number of edges in the inteference graph and the denominator
is an estimate of the dynamic number of uses.
This also extends Arg::Role to know that there is such a thing as ColdUse, i.e. a Use that
doesn't count as such for the above formula. Because LateUse is always used in contexts where we
want it to be Cold, I've defined LateUse to imply ColdUse.
This gets rid of all spilling inside the hot loop in Kraken/imaging-gaussian-blur. But more
importantly, it makes our register allocator use a well-known heuristic based on reusable
building blocks like the new Air::UseCounts. Even if the heuristic is slightly wrong, the right
heuristic probably uses the same building blocks.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
* b3/B3ValueRep.h:
* b3/air/AirArg.cpp:
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isAnyUse):
(JSC::B3::Air::Arg::isColdUse):
(JSC::B3::Air::Arg::isWarmUse):
(JSC::B3::Air::Arg::isEarlyUse):
(JSC::B3::Air::Arg::isDef):
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::iteratedRegisterCoalescing):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator): Deleted.
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocatedReg): Deleted.
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::tmpArraySize): Deleted.
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::initializeDegrees): Deleted.
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::build): Deleted.
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill): Deleted.
(JSC::B3::Air::isUselessMoveInst): Deleted.
(JSC::B3::Air::assignRegisterToTmpInProgram): Deleted.
(JSC::B3::Air::addSpillAndFillToProgram): Deleted.
(JSC::B3::Air::iteratedRegisterCoalescingOnType): Deleted.
* b3/air/AirLiveness.h:
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/AirUseCounts.h: Added.
(JSC::B3::Air::UseCounts::Counts::dump):
(JSC::B3::Air::UseCounts::UseCounts):
(JSC::B3::Air::UseCounts::operator[]):
(JSC::B3::Air::UseCounts::dump):
* runtime/Options.h:
2015-11-30 Csaba Osztrogonác <ossy@webkit.org>
Fix the !ENABLE(DFG_JIT) build after r192699
https://bugs.webkit.org/show_bug.cgi?id=151616
Reviewed by Darin Adler.
* assembler/MacroAssembler.h:
2015-11-30 Yusuke Suzuki <utatane.tea@gmail.com>
Object::{freeze, seal} perform preventExtensionsTransition twice
https://bugs.webkit.org/show_bug.cgi?id=151606
Reviewed by Darin Adler.
In Structure::{freezeTransition, sealTransition}, we perform preventExtensionsTransition.
So it is unnecessary to perform preventExtensionsTransition before executing Structure::{freezeTransition, sealTransition}.
* runtime/JSObject.cpp:
(JSC::JSObject::seal):
(JSC::JSObject::freeze):
(JSC::JSObject::preventExtensions):
* tests/stress/freeze-and-seal-should-prevent-extensions.js: Added.
(shouldBe):
(shouldThrow):
2015-11-30 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add Sqrt to B3
https://bugs.webkit.org/show_bug.cgi?id=151692
Reviewed by Geoffrey Garen.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::sqrtDouble):
* assembler/X86Assembler.h:
(JSC::X86Assembler::sqrtsd_mr):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testSqrtArg):
(JSC::B3::testSqrtImm):
(JSC::B3::testSqrtMem):
(JSC::B3::run):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::doubleSqrt):
2015-11-30 Filip Pizlo <fpizlo@apple.com>
FTL lazy slow paths should work with B3
https://bugs.webkit.org/show_bug.cgi?id=151667
Reviewed by Geoffrey Garen.
This adds all of the glue necessary to make FTL::LazySlowPath work with B3. The B3 approach
allows us to put all of the code in FTL::LowerDFGToLLVM, instead of having supporting data
structures on the side and a bunch of complex code in FTLCompile.cpp.
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::generate):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::generate):
* b3/B3StackmapValue.h:
* ftl/FTLJSTailCall.cpp:
(JSC::FTL::DFG::recoveryFor):
(JSC::FTL::JSTailCall::emit):
* ftl/FTLLazySlowPath.cpp:
(JSC::FTL::LazySlowPath::LazySlowPath):
(JSC::FTL::LazySlowPath::generate):
* ftl/FTLLazySlowPath.h:
(JSC::FTL::LazySlowPath::createGenerator):
(JSC::FTL::LazySlowPath::patchableJump):
(JSC::FTL::LazySlowPath::done):
(JSC::FTL::LazySlowPath::patchpoint):
(JSC::FTL::LazySlowPath::usedRegisters):
(JSC::FTL::LazySlowPath::callSiteIndex):
(JSC::FTL::LazySlowPath::stub):
* ftl/FTLLocation.cpp:
(JSC::FTL::Location::forValueRep):
(JSC::FTL::Location::forStackmaps):
(JSC::FTL::Location::dump):
(JSC::FTL::Location::isGPR):
(JSC::FTL::Location::gpr):
(JSC::FTL::Location::isFPR):
(JSC::FTL::Location::fpr):
(JSC::FTL::Location::restoreInto):
* ftl/FTLLocation.h:
(JSC::FTL::Location::Location):
(JSC::FTL::Location::forRegister):
(JSC::FTL::Location::forIndirect):
(JSC::FTL::Location::forConstant):
(JSC::FTL::Location::kind):
(JSC::FTL::Location::hasReg):
(JSC::FTL::Location::reg):
(JSC::FTL::Location::hasOffset):
(JSC::FTL::Location::offset):
(JSC::FTL::Location::hash):
(JSC::FTL::Location::hasDwarfRegNum): Deleted.
(JSC::FTL::Location::dwarfRegNum): Deleted.
(JSC::FTL::Location::hasDwarfReg): Deleted.
(JSC::FTL::Location::dwarfReg): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::stubUnavailableRegisters):
(JSC::RegisterSet::macroScratchRegisters):
(JSC::RegisterSet::calleeSaveRegisters):
* jit/RegisterSet.h:
2015-11-30 Geoffrey Garen <ggaren@apple.com>
Use a better RNG for Math.random()
https://bugs.webkit.org/show_bug.cgi?id=151641
Reviewed by Anders Carlsson.
Updated for interface change.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::setInputCursor):
2015-11-30 Benjamin Poulain <bpoulain@apple.com>
[JSC] Speed up Air Liveness Analysis on Tmps
https://bugs.webkit.org/show_bug.cgi?id=151556
Reviewed by Filip Pizlo.
Liveness Analysis scales poorly on large graphs like the ones
generated by testComplex().
This patch introduces a faster of Liveness using the continuous indices
of values instead of the values themselves.
There are two main areas of improvements:
1) Reduce the cost of doing a LocalCalc over a BasicBlock.
2) Reduce how many LocalCalc are needed to converge to a solution.
Most of the costs of LocalCalc are from HashSet manipulations.
The HashSet operations are O(1) but the constant is large enough
to be a problem.
I used a similar trick as the Register Allocator to remove hashing
and collision handling: the absolute value of the Tmp is used as an index
into a flat array.
I used Briggs's Sparse Set implementation for the local live information
at each instruction. It has great properties for doing the local calculation:
-No memory reallocation.
-O(1) add() and remove() with a small constant.
-Strict O(n) iteration.
-O(1) clear().
The values Live-At-Head are now stored into a Vector. The Sparse Set
is used to maintain the Tmp uniqueness.
When forwarding new liveness at head to the predecessor, I start by removing
everything that was already in live-at-head. We can assume that any value
in that list has already been added to the predecessors.
This leaves us with a small-ish number of Tmps to add to live-at-head
and to the predecessors.
The speed up convergence, I used the same trick as DFG's liveness: keep
a set of dirty blocks to process. In practice, all the blocks without
back-edges converge quickly, and we only propagate liveness as needed.
This patch reduces the time taken by "testComplex(64, 384)" by another 5%.
The remaining things to do for Liveness are:
-Skip the first block for the fix point (it is often large and doing a local
calc on it is useless).
-Find a better Data Structure for live-at-tail (updating the HashSet takes
> 50% of the total convergence time).
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::getAlias):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::getAliasWhenSpilling):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocatedReg):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::tmpArraySize):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::initializeDegrees):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdge):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::makeWorkList):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::simplify):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::forEachAdjacent):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::hasBeenSimplified):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::decrementDegree):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::forEachNodeMoves):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::isMoveRelated):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::enableMovesOnValue):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::precoloredCoalescingHeuristic):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::conservativeHeuristic):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addWorkList):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::combine):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::freezeMoves):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::assignColors):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::dumpInterferenceGraphInDot):
(JSC::B3::Air::iteratedRegisterCoalescingOnType):
(JSC::B3::Air::iteratedRegisterCoalescing):
(JSC::B3::Air::AbsoluteTmpHelper<Arg::GP>::absoluteIndex): Deleted.
(JSC::B3::Air::AbsoluteTmpHelper<Arg::GP>::tmpFromAbsoluteIndex): Deleted.
(JSC::B3::Air::AbsoluteTmpHelper<Arg::FP>::absoluteIndex): Deleted.
(JSC::B3::Air::AbsoluteTmpHelper<Arg::FP>::tmpFromAbsoluteIndex): Deleted.
* b3/air/AirReportUsedRegisters.cpp:
(JSC::B3::Air::reportUsedRegisters):
* b3/air/AirTmpInlines.h:
(JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::absoluteIndex):
(JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::tmpFromAbsoluteIndex):
(JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::absoluteIndex):
(JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::tmpFromAbsoluteIndex):
* b3/air/AirLiveness.h: Added.
2015-11-30 Saam barati <sbarati@apple.com>
FTL OSR Exits that are exception handlers should not have two different entrances. Instead, we should have two discrete OSR exits that do different things.
https://bugs.webkit.org/show_bug.cgi?id=151404
Reviewed by Filip Pizlo.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExceptionHandlerManager.cpp:
(JSC::FTL::ExceptionHandlerManager::addNewExit):
(JSC::FTL::ExceptionHandlerManager::addNewCallOperationExit):
(JSC::FTL::ExceptionHandlerManager::callOperationExceptionTarget):
(JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
(JSC::FTL::ExceptionHandlerManager::callOperationOSRExit):
(JSC::FTL::ExceptionHandlerManager::getByIdOSRExit): Deleted.
(JSC::FTL::ExceptionHandlerManager::subOSRExit): Deleted.
* ftl/FTLExceptionHandlerManager.h:
* ftl/FTLExitThunkGenerator.cpp:
(JSC::FTL::ExitThunkGenerator::emitThunk):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
(JSC::FTL::OSRExitDescriptor::isExceptionHandler):
(JSC::FTL::OSRExit::OSRExit):
(JSC::FTL::OSRExit::spillRegistersToSpillSlot):
(JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
(JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
(JSC::FTL::OSRExit::willArriveAtOSRExitFromGenericUnwind):
(JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
(JSC::FTL::OSRExit::needsRegisterRecoveryOnGenericUnwindOSRExitPath):
(JSC::FTL::OSRExitDescriptor::willArriveAtExitFromIndirectExceptionCheck): Deleted.
(JSC::FTL::OSRExitDescriptor::mightArriveAtOSRExitFromGenericUnwind): Deleted.
(JSC::FTL::OSRExitDescriptor::mightArriveAtOSRExitFromCallOperation): Deleted.
(JSC::FTL::OSRExitDescriptor::needsRegisterRecoveryOnGenericUnwindOSRExitPath): Deleted.
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompilationInfo.h:
(JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileFTLOSRExit):
2015-11-30 Mark Lam <mark.lam@apple.com>
Refactor the op_add, op_sub, and op_mul snippets to use the SnippetOperand class.
https://bugs.webkit.org/show_bug.cgi?id=151678
Reviewed by Geoffrey Garen.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileArithSub):
* ftl/FTLCompile.cpp:
* jit/JITAddGenerator.cpp:
(JSC::JITAddGenerator::generateFastPath):
* jit/JITAddGenerator.h:
(JSC::JITAddGenerator::JITAddGenerator):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_add):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emit_op_sub):
* jit/JITMulGenerator.cpp:
(JSC::JITMulGenerator::generateFastPath):
* jit/JITMulGenerator.h:
(JSC::JITMulGenerator::JITMulGenerator):
* jit/JITSubGenerator.cpp:
(JSC::JITSubGenerator::generateFastPath):
* jit/JITSubGenerator.h:
(JSC::JITSubGenerator::JITSubGenerator):
* jit/SnippetOperand.h:
(JSC::SnippetOperand::isPositiveConstInt32):
2015-11-30 Filip Pizlo <fpizlo@apple.com>
B3 stackmaps should support early clobber
https://bugs.webkit.org/show_bug.cgi?id=151668
Reviewed by Geoffrey Garen.
While starting work on FTL lazy slow paths, I realized that we needed some way to say that r11 is
off limits. Not just that it's clobbered, but that it cannot be used for any input values to a
stackmap.
In LLVM we do this by having the AnyRegCC forbid r11.
In B3, we want something more flexible. In this and other cases, what we really want is an early
clobber set. B3 already supported a late clobber set for every stackmap value. Late clobber means
that the act of performing the operation will cause garbage to be written into those registers.
But here we want: assume that garbage magically appears in those registers in the moment before
the operation executes. Any registers in that set will be off-limits to the inputs to the
stackmap. This should be great for other things, like the way the we handle exceptions.
For the simple r11 issue, what we want is to call the StackmapValue::clobber() method, which now
means both early and late clobber. It's the weapon of choice whenever you're unsure.
This adds the early clobber feature, does some minor Inst refactoring to make this less scary,
and adds a test. The test is simple but it's very comprehensive - for example it tests the
early-clobber-after-Move special case.
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::extraClobberedRegs):
(JSC::B3::StackmapSpecial::extraEarlyClobberedRegs):
(JSC::B3::StackmapSpecial::forEachArgImpl):
* b3/B3StackmapSpecial.h:
* b3/B3StackmapValue.cpp:
(JSC::B3::StackmapValue::dumpMeta):
(JSC::B3::StackmapValue::StackmapValue):
* b3/B3StackmapValue.h:
* b3/air/AirCCallSpecial.cpp:
(JSC::B3::Air::CCallSpecial::extraClobberedRegs):
(JSC::B3::Air::CCallSpecial::extraEarlyClobberedRegs):
(JSC::B3::Air::CCallSpecial::dumpImpl):
* b3/air/AirCCallSpecial.h:
* b3/air/AirInst.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::extraClobberedRegs):
(JSC::B3::Air::Inst::extraEarlyClobberedRegs):
(JSC::B3::Air::Inst::forEachTmpWithExtraClobberedRegs):
(JSC::B3::Air::Inst::reportUsedRegisters):
(JSC::B3::Air::Inst::forEachDefAndExtraClobberedTmp): Deleted.
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocate):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::initializeDegrees):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdge):
(JSC::B3::Air::iteratedRegisterCoalescingOnType):
(JSC::B3::Air::iteratedRegisterCoalescing):
* b3/air/AirSpecial.h:
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/testb3.cpp:
(JSC::B3::testSimplePatchpointWithoutOuputClobbersGPArgs):
(JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
(JSC::B3::testSimplePatchpointWithoutOuputClobbersFPArgs):
(JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
(JSC::B3::testPatchpointWithEarlyClobber):
(JSC::B3::testPatchpointCallArg):
(JSC::B3::run):
* dfg/DFGCommon.h:
2015-11-30 Mark Lam <mark.lam@apple.com>
Snippefy op_div for the baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=151607
Reviewed by Geoffrey Garen.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_div):
(JSC::JIT::emitSlow_op_div):
(JSC::JIT::compileBinaryArithOpSlowCase): Deleted.
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emitBinaryDoubleOp):
(JSC::JIT::emit_op_div): Deleted.
(JSC::JIT::emitSlow_op_div): Deleted.
- Removed the 32-bit specific op_div implementation. The 64-bit version with the
op_div snippet can now service both 32-bit and 64-bit.
* jit/JITDivGenerator.cpp: Added.
(JSC::JITDivGenerator::loadOperand):
(JSC::JITDivGenerator::generateFastPath):
* jit/JITDivGenerator.h: Added.
(JSC::JITDivGenerator::JITDivGenerator):
(JSC::JITDivGenerator::didEmitFastPath):
(JSC::JITDivGenerator::endJumpList):
(JSC::JITDivGenerator::slowPathJumpList):
* jit/JITInlines.h:
(JSC::JIT::getOperandConstantDouble): Added.
* jit/SnippetOperand.h: Added.
(JSC::SnippetOperand::SnippetOperand):
(JSC::SnippetOperand::mightBeNumber):
(JSC::SnippetOperand::definitelyIsNumber):
(JSC::SnippetOperand::isConst):
(JSC::SnippetOperand::isConstInt32):
(JSC::SnippetOperand::isConstDouble):
(JSC::SnippetOperand::asRawBits):
(JSC::SnippetOperand::asConstInt32):
(JSC::SnippetOperand::asConstDouble):
(JSC::SnippetOperand::setConstInt32):
(JSC::SnippetOperand::setConstDouble):
- The SnippetOperand encapsulates operand constness, const type, and profiling
information. As a result:
1. The argument list to the JITDivGenerator constructor is now more concise.
2. The logic of the JITDivGenerator is now less verbose and easier to express.
* parser/ResultType.h:
(JSC::ResultType::isInt32):
(JSC::ResultType::definitelyIsNumber):
(JSC::ResultType::definitelyIsString):
(JSC::ResultType::definitelyIsBoolean):
(JSC::ResultType::mightBeNumber):
(JSC::ResultType::isNotNumber):
- Made these functions const because they were always meant to be const.
This also allows me to enforce constness in the SnippetOperand.
2015-11-30 Sukolsak Sakshuwong <sukolsak@gmail.com>
Fix coding style of Intl code
https://bugs.webkit.org/show_bug.cgi?id=151491
Reviewed by Darin Adler.
This patch does three things:
1. Rename pointers and references to ExecState from "exec" to "state".
2. Pass parameters by references instead of pointers if the parameters
are required.
3. Remove the word "get" from the names of functions that don't return
values through out arguments.
* runtime/IntlCollator.cpp:
(JSC::IntlCollatorFuncCompare):
* runtime/IntlCollatorConstructor.cpp:
(JSC::initializeCollator):
(JSC::constructIntlCollator):
(JSC::callIntlCollator):
(JSC::IntlCollatorConstructor::getOwnPropertySlot):
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormatFuncFormatDateTime):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::constructIntlDateTimeFormat):
(JSC::callIntlDateTimeFormat):
(JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot):
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot):
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
(JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormatFuncFormatNumber):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::constructIntlNumberFormat):
(JSC::callIntlNumberFormat):
(JSC::IntlNumberFormatConstructor::getOwnPropertySlot):
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototype::getOwnPropertySlot):
(JSC::IntlNumberFormatPrototypeGetterFormat):
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
* runtime/IntlObject.cpp:
(JSC::intlBooleanOption):
(JSC::intlStringOption):
(JSC::privateUseLangTag):
(JSC::canonicalLangTag):
(JSC::grandfatheredLangTag):
(JSC::canonicalizeLanguageTag):
(JSC::canonicalizeLocaleList):
(JSC::lookupSupportedLocales):
(JSC::bestFitSupportedLocales):
(JSC::supportedLocales):
(JSC::getIntlBooleanOption): Deleted.
(JSC::getIntlStringOption): Deleted.
(JSC::getPrivateUseLangTag): Deleted.
(JSC::getCanonicalLangTag): Deleted.
(JSC::getGrandfatheredLangTag): Deleted.
* runtime/IntlObject.h:
2015-11-30 Benjamin Poulain <bpoulain@apple.com>
[JSC] Simplify the loop that remove useless Air instructions
https://bugs.webkit.org/show_bug.cgi?id=151652
Reviewed by Andreas Kling.
* b3/air/AirEliminateDeadCode.cpp:
(JSC::B3::Air::eliminateDeadCode):
Use Vector's removeAllMatching() instead of custom code.
It is likely faster too since we remove few values and Vector
is good at doing that.
2015-11-30 Filip Pizlo <fpizlo@apple.com>
B3 should be be clever about choosing which child to reuse for result in two-operand commutative operations
https://bugs.webkit.org/show_bug.cgi?id=151321
Reviewed by Geoffrey Garen.
When lowering a commutative operation to a two-operand instruction, you have a choice of which
child value to move into the result tmp. For example we might have:
@x = Add(@y, @z)
Assuming no three-operand add is available, we could either lower it to this:
Move %y, %x
Add %z, %x
or to this:
Move %z, %x
Add %y, %x
Which is better depends on the likelihood of coalescing with %x. If it's more likely that %y will
coalesce with %x, then we want to use the first form. Otherwise, we should use the second form.
This implements two heuristics for selecting the right form, and makes those heuristics reusable
within the B3->Air lowering by abstracting it as preferRightForResult(). For non-commutative
operations we must use the first form, so the first form is the default. The heuristics are:
- If the right child has only one user, then use the second form instead. This is profitable because
that means that @z dies at the Add, so using the second form means that the Move will be coalesced
away.
- If one of the children is a Phi that this operation (the Add in this case) flows into via some
Upsilon - possibly transitively through other Phis - then use the form that cases a Move on that
child. This overrides everything else, and is meant to optimize variables that accumulate in a
loop.
This required adding a reusable PhiChildren analysis, so I wrote one. It has an API that is mostly
based on iterators, and a higher-level API for looking at transitive children that is based on
functors.
I was originally implementing this for completeness, but when looking at how it interacted with
imaging-gaussian-blur, I realized the need for some heuristic for the loop-accumulator case. This
helps a lot on that benchmark. This widens the overall lead that B3 has on imaging-gaussian-blur, but
steady-state runs that exclude compile latency still show a slight deficit. That will most likely get
fixed by https://bugs.webkit.org/show_bug.cgi?id=151174.
No new tests because the commutativity appears to be covered by existing tests, and anyway, there are
no correctness implications to commuting a commutative operation.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::LowerToAir):
(JSC::B3::Air::LowerToAir::canBeInternal):
(JSC::B3::Air::LowerToAir::appendUnOp):
(JSC::B3::Air::LowerToAir::preferRightForResult):
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3PhiChildren.cpp: Added.
(JSC::B3::PhiChildren::PhiChildren):
(JSC::B3::PhiChildren::~PhiChildren):
* b3/B3PhiChildren.h: Added.
(JSC::B3::PhiChildren::ValueCollection::ValueCollection):
(JSC::B3::PhiChildren::ValueCollection::size):
(JSC::B3::PhiChildren::ValueCollection::at):
(JSC::B3::PhiChildren::ValueCollection::operator[]):
(JSC::B3::PhiChildren::ValueCollection::contains):
(JSC::B3::PhiChildren::ValueCollection::iterator::iterator):
(JSC::B3::PhiChildren::ValueCollection::iterator::operator*):
(JSC::B3::PhiChildren::ValueCollection::iterator::operator++):
(JSC::B3::PhiChildren::ValueCollection::iterator::operator==):
(JSC::B3::PhiChildren::ValueCollection::iterator::operator!=):
(JSC::B3::PhiChildren::ValueCollection::begin):
(JSC::B3::PhiChildren::ValueCollection::end):
(JSC::B3::PhiChildren::UpsilonCollection::UpsilonCollection):
(JSC::B3::PhiChildren::UpsilonCollection::size):
(JSC::B3::PhiChildren::UpsilonCollection::at):
(JSC::B3::PhiChildren::UpsilonCollection::operator[]):
(JSC::B3::PhiChildren::UpsilonCollection::contains):
(JSC::B3::PhiChildren::UpsilonCollection::begin):
(JSC::B3::PhiChildren::UpsilonCollection::end):
(JSC::B3::PhiChildren::UpsilonCollection::values):
(JSC::B3::PhiChildren::UpsilonCollection::forAllTransitiveIncomingValues):
(JSC::B3::PhiChildren::UpsilonCollection::transitivelyUses):
(JSC::B3::PhiChildren::at):
(JSC::B3::PhiChildren::operator[]):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::Procedure):
* b3/B3Procedure.h:
* b3/B3UseCounts.cpp:
(JSC::B3::UseCounts::UseCounts):
* b3/B3UseCounts.h:
(JSC::B3::UseCounts::numUses):
(JSC::B3::UseCounts::numUsingInstructions):
(JSC::B3::UseCounts::operator[]): Deleted.
2015-11-30 Filip Pizlo <fpizlo@apple.com>
REGRESSION(r192812): This change seems to have broken the iOS builds (Requested by ryanhaddad on #webkit).
https://bugs.webkit.org/show_bug.cgi?id=151669
Unreviewed, fix build.
* dfg/DFGCommon.h:
2015-11-30 Saam barati <sbarati@apple.com>
implement op_get_rest_length so that we can allocate the rest array with the right size from the start
https://bugs.webkit.org/show_bug.cgi?id=151467
Reviewed by Geoffrey Garen and Mark Lam.
This patch implements op_get_rest_length which returns the length
that the rest parameter array will be. We're implementing this because
it might be a constant value in the presence of inlining in the DFG.
We will take advantage of this optimization opportunity in a future patch:
https://bugs.webkit.org/show_bug.cgi?id=151454
to emit better code for op_copy_rest.
op_get_rest_length has two operands:
1) a destination
2) A constant indicating the number of parameters to skip when copying the rest array.
op_get_rest_length lowers to a JSConstant node when we're inlined
and not a varargs call (in this case, we statically know the arguments
length). When that condition isn't met, we lower op_get_rest_length to
GetRestArray. GetRestArray produces its result as an int32.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewArray):
(JSC::BytecodeGenerator::emitNewArrayWithSize):
(JSC::BytecodeGenerator::emitNewFunction):
(JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
(JSC::BytecodeGenerator::emitRestParameter):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::RestParameterNode::emit):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGNode.h:
(JSC::DFG::Node::numberOfArgumentsToSkip):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCopyRest):
(JSC::DFG::SpeculativeJIT::compileGetRestLength):
(JSC::DFG::SpeculativeJIT::compileNotifyWrite):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCopyRest):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetRestLength):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewObject):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_copy_rest):
(JSC::JIT::emit_op_get_rest_length):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2015-11-30 Filip Pizlo <fpizlo@apple.com>
MacroAssembler needs an API for disabling scratch registers
https://bugs.webkit.org/show_bug.cgi?id=151010
Reviewed by Saam Barati and Michael Saboff.
This adds two scope classes, DisallowMacroScratchRegisterUsage and
AllowMacroScratchRegisterUsage. The default is that the scratch registers are enabled. Air
disables them before generation.
Henceforth the pattern inside B3 stackmap generator callbacks will be that you can only use
AllowMacroScratchRegisterUsage if you've either supplied the scratch register as a clobbered
register and arranged for all of the stackmap values to be late uses, or you're writing a test
and you're OK with it being fragile with respect to scratch registers. The latter holds in most
of testb3.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::optimizeForX86):
(JSC::AbstractMacroAssembler::setTempRegisterValid):
* assembler/AllowMacroScratchRegisterUsage.h: Added.
(JSC::AllowMacroScratchRegisterUsage::AllowMacroScratchRegisterUsage):
(JSC::AllowMacroScratchRegisterUsage::~AllowMacroScratchRegisterUsage):
* assembler/DisallowMacroScratchRegisterUsage.h: Added.
(JSC::DisallowMacroScratchRegisterUsage::DisallowMacroScratchRegisterUsage):
(JSC::DisallowMacroScratchRegisterUsage::~DisallowMacroScratchRegisterUsage):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::scratchRegister):
(JSC::MacroAssemblerX86Common::loadDouble):
(JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::add32):
(JSC::MacroAssemblerX86_64::and32):
(JSC::MacroAssemblerX86_64::or32):
(JSC::MacroAssemblerX86_64::sub32):
(JSC::MacroAssemblerX86_64::load8):
(JSC::MacroAssemblerX86_64::addDouble):
(JSC::MacroAssemblerX86_64::convertInt32ToDouble):
(JSC::MacroAssemblerX86_64::store32):
(JSC::MacroAssemblerX86_64::store8):
(JSC::MacroAssemblerX86_64::callWithSlowPathReturnType):
(JSC::MacroAssemblerX86_64::call):
(JSC::MacroAssemblerX86_64::jump):
(JSC::MacroAssemblerX86_64::tailRecursiveCall):
(JSC::MacroAssemblerX86_64::makeTailRecursiveCall):
(JSC::MacroAssemblerX86_64::branchAdd32):
(JSC::MacroAssemblerX86_64::add64):
(JSC::MacroAssemblerX86_64::addPtrNoFlags):
(JSC::MacroAssemblerX86_64::and64):
(JSC::MacroAssemblerX86_64::lshift64):
(JSC::MacroAssemblerX86_64::or64):
(JSC::MacroAssemblerX86_64::sub64):
(JSC::MacroAssemblerX86_64::store64):
(JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch):
(JSC::MacroAssemblerX86_64::branch64):
(JSC::MacroAssemblerX86_64::branchPtr):
(JSC::MacroAssemblerX86_64::branchTest64):
(JSC::MacroAssemblerX86_64::test64):
(JSC::MacroAssemblerX86_64::branchPtrWithPatch):
(JSC::MacroAssemblerX86_64::branch32WithPatch):
(JSC::MacroAssemblerX86_64::storePtrWithPatch):
(JSC::MacroAssemblerX86_64::branch8):
(JSC::MacroAssemblerX86_64::branchTest8):
(JSC::MacroAssemblerX86_64::convertInt64ToDouble):
(JSC::MacroAssemblerX86_64::readCallTarget):
(JSC::MacroAssemblerX86_64::haveScratchRegisterForBlinding):
(JSC::MacroAssemblerX86_64::scratchRegisterForBlinding):
(JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranchPtrWithPatch):
(JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranch32WithPatch):
(JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranchPtrWithPatch):
(JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranch32WithPatch):
(JSC::MacroAssemblerX86_64::revertJumpReplacementToBranchPtrWithPatch):
(JSC::MacroAssemblerX86_64::repatchCall):
(JSC::MacroAssemblerX86_64::add64AndSetFlags):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/testb3.cpp:
(JSC::B3::testSimplePatchpoint):
(JSC::B3::testSimplePatchpointWithoutOuputClobbersGPArgs):
(JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
(JSC::B3::testSimplePatchpointWithoutOuputClobbersFPArgs):
(JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
(JSC::B3::testPatchpointCallArg):
(JSC::B3::testPatchpointFixedRegister):
(JSC::B3::testPatchpointAny):
(JSC::B3::testPatchpointAnyImm):
(JSC::B3::testSimpleCheck):
(JSC::B3::testCheckLessThan):
(JSC::B3::testCheckMegaCombo):
(JSC::B3::testCheckAddImm):
(JSC::B3::testCheckAddImmCommute):
(JSC::B3::testCheckAddImmSomeRegister):
(JSC::B3::testCheckAdd):
(JSC::B3::testCheckAdd64):
(JSC::B3::testCheckAddFoldFail):
(JSC::B3::testCheckSubImm):
(JSC::B3::testCheckSubBadImm):
(JSC::B3::testCheckSub):
(JSC::B3::testCheckSub64):
(JSC::B3::testCheckSubFoldFail):
(JSC::B3::testCheckNeg):
(JSC::B3::testCheckNeg64):
(JSC::B3::testCheckMul):
(JSC::B3::testCheckMulMemory):
(JSC::B3::testCheckMul2):
(JSC::B3::testCheckMul64):
(JSC::B3::testCheckMulFoldFail):
(JSC::B3::genericTestCompare):
* dfg/DFGCommon.h:
* jit/GPRInfo.h:
(JSC::GPRInfo::toRegister):
(JSC::GPRInfo::reservedRegisters):
2015-11-26 Mark Lam <mark.lam@apple.com>
[ARM64] stress/op_div.js is failing on some divide by 0 cases.
https://bugs.webkit.org/show_bug.cgi?id=151515
Reviewed by Saam Barati.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithDiv):
- Added a check for the divide by zero case.
* tests/stress/op_div.js:
- Un-skipped the test.
2015-11-27 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Add testb3 to the build system
https://bugs.webkit.org/show_bug.cgi?id=151619
Reviewed by Gyuyoung Kim.
* shell/CMakeLists.txt:
2015-11-27 Csaba Osztrogonác <ossy@webkit.org>
Use mark pragmas only if it is supported
https://bugs.webkit.org/show_bug.cgi?id=151621
Reviewed by Mark Lam.
* b3/air/AirIteratedRegisterCoalescing.cpp:
2015-11-27 Csaba Osztrogonác <ossy@webkit.org>
Fix the ENABLE(B3_JIT) build with GCC in B3Procedure.h
https://bugs.webkit.org/show_bug.cgi?id=151620
Reviewed by Mark Lam.
* b3/B3Procedure.h:
2015-11-27 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Add new B3 source files to the build system
https://bugs.webkit.org/show_bug.cgi?id=151618
Reviewed by Gyuyoung Kim.
* CMakeLists.txt:
2015-11-26 Carlos Garcia Campos <cgarcia@igalia.com>
[GLIB] Implement garbage collector timers
https://bugs.webkit.org/show_bug.cgi?id=151391
Reviewed by Žan Doberšek.
Add GLib implementation using GSource.
* heap/EdenGCActivityCallback.cpp:
* heap/FullGCActivityCallback.cpp:
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::GCActivityCallback):
(JSC::GCActivityCallback::scheduleTimer):
(JSC::GCActivityCallback::cancelTimer):
* heap/GCActivityCallback.h:
* heap/Heap.cpp:
(JSC::Heap::Heap):
* heap/HeapTimer.cpp:
(JSC::HeapTimer::HeapTimer):
(JSC::HeapTimer::~HeapTimer):
(JSC::HeapTimer::timerDidFire):
* heap/HeapTimer.h:
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::IncrementalSweeper):
(JSC::IncrementalSweeper::scheduleTimer):
(JSC::IncrementalSweeper::cancelTimer):
* heap/IncrementalSweeper.h:
2015-11-24 Caitlin Potter <caitp@igalia.com>
[JSC] support Computed Property Names in destructuring Patterns
https://bugs.webkit.org/show_bug.cgi?id=151494
Reviewed by Saam Barati.
Add support for computed property names in destructuring BindingPatterns
and AssignmentPatterns.
Productions BindingProperty(1) and AssignmentProperty(2) allow for any valid
PropertName(3), including ComputedPropertyName(4)
1: http://tc39.github.io/ecma262/#prod-BindingProperty
2: http://tc39.github.io/ecma262/#prod-AssignmentProperty
3: http://tc39.github.io/ecma262/#prod-PropertyName
4: http://tc39.github.io/ecma262/#prod-ComputedPropertyName
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::bindValue):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::appendObjectPatternEntry):
* parser/Nodes.h:
(JSC::ObjectPatternNode::appendEntry):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseDestructuringPattern):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
* tests/es6.yaml:
* tests/es6/destructuring_assignment_computed_properties.js: Added.
(test):
(test.computeName):
(test.loadValue):
(test.out.get a):
(test.out.set a):
(test.out.get b):
(test.out.set b):
(test.out.get c):
(test.out.set c):
(test.get var):
2015-11-24 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r192536, r192722, and r192743.
https://bugs.webkit.org/show_bug.cgi?id=151593
Still causing trouble. (Requested by kling on #webkit).
Reverted changesets:
"[JSC] JSPropertyNameEnumerator could be destructorless."
https://bugs.webkit.org/show_bug.cgi?id=151242
http://trac.webkit.org/changeset/192536
"REGRESSION(r192536): Null pointer dereference in
JSPropertyNameEnumerator::visitChildren()."
https://bugs.webkit.org/show_bug.cgi?id=151495
http://trac.webkit.org/changeset/192722
"REGRESSION(r192536): Null pointer dereference in
JSPropertyNameEnumerator::visitChildren()."
https://bugs.webkit.org/show_bug.cgi?id=151495
http://trac.webkit.org/changeset/192743
2015-11-23 Brian Burg <bburg@apple.com>
Unreviewed, fix the Mac CMake build after r192793.
* PlatformMac.cmake:
2015-11-20 Brian Burg <bburg@apple.com>
Web Inspector: RemoteInspector should track targets and connections for remote automation
https://bugs.webkit.org/show_bug.cgi?id=151042
Reviewed by Joseph Pecoraro.
Refactor RemoteInspector so it can be used to send listings of different target types.
First, rename Debuggable to RemoteInspectionTarget, and pull things not specific to
remote inspection into the base class RemoteControllableTarget and its Connection class.
Add a new RemoteControllableTarget called RemoteAutomationTarget, used by UIProcess
to support remote UI automation via webinspectord. On the protocol side, this target
uses a new WIRTypeKey called WIRTypeAutomation to distiguish the listing from
Web and JavaScript listings and avoid inventing a new listing mechanism.
* API/JSContextRef.cpp:
(JSGlobalContextGetDebuggerRunLoop):
(JSGlobalContextSetDebuggerRunLoop):
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/InspectorFrontendChannel.h:
* inspector/remote/RemoteAutomationTarget.cpp: Added.
(Inspector::RemoteAutomationTarget::setAutomationAllowed): Added.
* inspector/remote/RemoteAutomationTarget.h: Added.
* inspector/remote/RemoteConnectionToTarget.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggableConnection.h.
(Inspector::RemoteTargetBlock::RemoteTargetBlock):
(Inspector::RemoteTargetBlock::~RemoteTargetBlock):
(Inspector::RemoteTargetBlock::operator=):
(Inspector::RemoteTargetBlock::operator()):
* inspector/remote/RemoteConnectionToTarget.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggableConnection.mm.
(Inspector::RemoteTargetHandleRunSourceGlobal):
(Inspector::RemoteTargetQueueTaskOnGlobalQueue):
(Inspector::RemoteTargetInitializeGlobalQueue):
(Inspector::RemoteTargetHandleRunSourceWithInfo):
(Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget):
(Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget):
(Inspector::RemoteConnectionToTarget::destination):
(Inspector::RemoteConnectionToTarget::connectionIdentifier):
(Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget):
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::targetClosed):
(Inspector::RemoteConnectionToTarget::close):
(Inspector::RemoteConnectionToTarget::sendMessageToTarget):
(Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
(Inspector::RemoteConnectionToTarget::setupRunLoop):
(Inspector::RemoteConnectionToTarget::teardownRunLoop):
(Inspector::RemoteConnectionToTarget::queueTaskOnPrivateRunLoop):
* inspector/remote/RemoteControllableTarget.cpp: Added.
(Inspector::RemoteControllableTarget::~RemoteControllableTarget):
(Inspector::RemoteControllableTarget::init):
(Inspector::RemoteControllableTarget::update):
* inspector/remote/RemoteControllableTarget.h: Added.
* inspector/remote/RemoteInspectionTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggable.cpp.
(Inspector::RemoteInspectionTarget::remoteControlAllowed):
(Inspector::RemoteInspectionTarget::setRemoteDebuggingAllowed):
(Inspector::RemoteInspectionTarget::pauseWaitingForAutomaticInspection):
(Inspector::RemoteInspectionTarget::unpauseForInitializedInspector):
* inspector/remote/RemoteInspectionTarget.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggable.h.
(isType):
* inspector/remote/RemoteInspector.h:
Code to manage Debuggables now works with RemoteControllableTargets and doesn't
care whether the target is for Inspection or Automation. Listing data with target-
and type-specific information are captured when clients call into RemoteInspector
since that's the easiest time to gather this information on the right thread.
Use the is<> / downcast<> machinery when we need a concrete Target type.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::nextAvailableIdentifier):
(Inspector::RemoteInspector::registerTarget): renamed from registerDebuggable.
(Inspector::RemoteInspector::unregisterTarget): renamed from unregisterDebuggable.
(Inspector::RemoteInspector::updateTarget): renamed from updateDebuggable.
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
(Inspector::RemoteInspector::sendMessageToRemote):
(Inspector::RemoteInspector::setupFailed):
(Inspector::RemoteInspector::stopInternal):
(Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
(Inspector::RemoteInspector::xpcConnectionFailed):
(Inspector::RemoteInspector::listingForTarget):
(Inspector::RemoteInspector::listingForInspectionTarget):
(Inspector::RemoteInspector::listingForAutomationTarget):
(Inspector::RemoteInspector::pushListingsNow):
(Inspector::RemoteInspector::pushListingsSoon):
(Inspector::RemoteInspector::receivedSetupMessage):
(Inspector::RemoteInspector::receivedDataMessage):
(Inspector::RemoteInspector::receivedDidCloseMessage):
(Inspector::RemoteInspector::receivedGetListingMessage):
(Inspector::RemoteInspector::receivedIndicateMessage):
(Inspector::RemoteInspector::receivedConnectionDiedMessage):
(Inspector::RemoteInspector::RemoteInspector): Deleted.
(Inspector::RemoteInspector::registerDebuggable): Deleted.
(Inspector::RemoteInspector::unregisterDebuggable): Deleted.
(Inspector::RemoteInspector::updateDebuggable): Deleted.
(Inspector::RemoteInspector::updateDebuggableAutomaticInspectCandidate): Deleted.
(Inspector::RemoteInspector::sendMessageToRemoteFrontend): Deleted.
(Inspector::RemoteInspector::listingForDebuggable): Deleted.
(Inspector::RemoteInspector::pushListingNow): Deleted.
(Inspector::RemoteInspector::pushListingSoon): Deleted.
* inspector/remote/RemoteInspectorConstants.h:
* runtime/JSGlobalObjectDebuggable.cpp:
(JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemote):
(JSC::JSGlobalObjectDebuggable::pauseWaitingForAutomaticInspection):
(JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemoteFrontend): Deleted.
* runtime/JSGlobalObjectDebuggable.h:
2015-11-23 Brian Burg <bburg@apple.com>
Rename JavaScriptCore builtins files to match exposed object names
https://bugs.webkit.org/show_bug.cgi?id=151549
Reviewed by Youenn Fablet.
As a subtask of unifying code generation for WebCore and JSC builtins, we need to get rid of
differences between builtins filenames (e.g., Promise.prototype.js) and the name of the
generated Builtin object (PromisePrototype).
If we don't do this, then both build systems need special hacks to normalize the object name
from the file name. It's easier to just normalize the filename.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/ArrayIteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/ArrayIterator.prototype.js.
* builtins/ArrayPrototype.js: Renamed from Source/JavaScriptCore/builtins/Array.prototype.js.
* builtins/FunctionPrototype.js: Renamed from Source/JavaScriptCore/builtins/Function.prototype.js.
* builtins/IteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/Iterator.prototype.js.
* builtins/PromiseOperations.js: Renamed from Source/JavaScriptCore/builtins/Operations.Promise.js.
* builtins/PromisePrototype.js: Renamed from Source/JavaScriptCore/builtins/Promise.prototype.js.
* builtins/StringIteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/StringIterator.prototype.js.
* builtins/TypedArrayPrototype.js: Renamed from Source/JavaScriptCore/builtins/TypedArray.prototype.js.
2015-11-23 Andreas Kling <akling@apple.com>
REGRESSION(r192536): Null pointer dereference in JSPropertyNameEnumerator::visitChildren().
<https://webkit.org/b/151495>
Reviewed by Mark Lam
The test I added when fixing this bug the first time caught another bug when
run on 32-bit: jsString() can also cause GC, so we have to make sure that
JSPropertyNameEnumerator::m_propertyNames is null until after the array it
points to has been populated.
Test: property-name-enumerator-gc-151495.js
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::finishCreation):
== Rolled over to ChangeLog-2015-11-21 ==