2013-08-28 Filip Pizlo
CodeBlock compilation and installation should be simplified and rationalized
https://bugs.webkit.org/show_bug.cgi?id=120326
Reviewed by Oliver Hunt.
Previously Executable owned the code for generating JIT code; you always had
to go through Executable. But often you also had to go through CodeBlock,
because ScriptExecutable couldn't have virtual methods, but CodeBlock could.
So you'd ask CodeBlock to do something, which would dispatch through a
virtual method that would select the appropriate Executable subtype's method.
This all meant that the same code would often be duplicated, because most of
the work needed to compile something was identical regardless of code type.
But then we tried to fix this, by having templatized helpers in
ExecutionHarness.h and JITDriver.h. The result was that if you wanted to find
out what happened when you asked for something to be compiled, you'd go on a
wild ride that started with CodeBlock, touched upon Executable, and then
ricocheted into either ExecutionHarness or JITDriver (likely both).
Another awkwardness was that for concurrent compiles, the DFG::Worklist had
super-special inside knowledge of what JITStubs.cpp's cti_optimize would have
done once the compilation finished.
Also, most of the DFG JIT drivers assumed that they couldn't install the
JITCode into the CodeBlock directly - instead they would return it via a
reference, which happened to be a reference to the JITCode pointer in
Executable. This was super weird.
Finally, there was no notion of compiling code into a special CodeBlock that
wasn't used for handling calls into an Executable. I'd like this for FTL OSR
entry.
This patch solves these problems by reducing all of that complexity into just
three primitives:
- Executable::newCodeBlock(). This gives you a new code block, either for call
or for construct, and either to serve as the baseline code or the optimized
code. The new code block is then owned by the caller; Executable doesn't
register it anywhere. The new code block has no JITCode and isn't callable,
but it has all of the bytecode.
- CodeBlock::prepareForExecution(). This takes the CodeBlock's bytecode and
produces a JITCode, and then installs the JITCode into the CodeBlock. This
method takes a JITType, and always compiles with that JIT. If you ask for
JITCode::InterpreterThunk then you'll get JITCode that just points to the
LLInt entrypoints. Once this returns, it is possible to call into the
CodeBlock if you do so manually - but the Executable still won't know about
it so JS calls to that Executable will still be routed to whatever CodeBlock
is associated with the Executable.
- Executable::installCode(). This takes a CodeBlock and makes it the code-for-
entry for that Executable. This involves unlinking the Executable's last
CodeBlock, if there was one. This also tells the GC about any effect on
memory usage and does a bunch of weird data structure rewiring, since
Executable caches some of CodeBlock's fields for the benefit of virtual call
fast paths.
This functionality is then wrapped around three convenience methods:
- Executable::prepareForExecution(). If there is no code block for that
Executable, then one is created (newCodeBlock()), compiled
(CodeBlock::prepareForExecution()) and installed (installCode()).
- CodeBlock::newReplacement(). Asks the Executable for a new CodeBlock that
can serve as an optimized replacement of the current one.
- CodeBlock::install(). Asks the Executable to install this code block.
This patch allows me to kill *a lot* of code and to remove a lot of
specializations for functions vs. not-functions, and a lot of places where we
pass around JITCode references and such. ExecutionHarness and JITDriver are
both gone. Overall this patch has more red than green.
It also allows me to work on FTL OSR entry and tier-up:
- FTL tier-up: this will involve DFGOperations.cpp asking the DFG::Worklist
to do some compilation, but it will require the DFG::Worklist to do
something different than what JITStubs.cpp would want, once the compilation
finishes. This patch introduces a callback mechanism for that purpose.
- FTL OSR entry: this will involve creating a special auto-jettisoned
CodeBlock that is used only for FTL OSR entry. The new set of primitives
allows for this: Executable can vend you a fresh new CodeBlock, and you can
ask that CodeBlock to compile itself with any JIT of your choosing. Or you
can take that CodeBlock and compile it yourself. Previously the act of
producing a CodeBlock-for-optimization and the act of compiling code for it
were tightly coupled; now you can separate them and you can create such
auto-jettisoned CodeBlocks that are used for a one-shot OSR entry.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::prepareForExecution):
(JSC::CodeBlock::install):
(JSC::CodeBlock::newReplacement):
(JSC::FunctionCodeBlock::jettisonImpl):
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::hasBaselineJITProfiling):
* bytecode/DeferredCompilationCallback.cpp: Added.
(JSC::DeferredCompilationCallback::DeferredCompilationCallback):
(JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
* bytecode/DeferredCompilationCallback.h: Added.
* dfg/DFGDriver.cpp:
(JSC::DFG::tryCompile):
* dfg/DFGDriver.h:
(JSC::DFG::tryCompile):
* dfg/DFGFailedFinalizer.cpp:
(JSC::DFG::FailedFinalizer::finalize):
(JSC::DFG::FailedFinalizer::finalizeFunction):
* dfg/DFGFailedFinalizer.h:
* dfg/DFGFinalizer.h:
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
* dfg/DFGJITFinalizer.h:
* dfg/DFGOSRExitPreparation.cpp:
(JSC::DFG::prepareCodeOriginForOSRExit):
* dfg/DFGOperations.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::compileInThreadImpl):
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
(JSC::DFG::Plan::finalizeAndNotifyCallback):
* dfg/DFGPlan.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalize):
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLJITFinalizer.h:
* heap/Heap.h:
(JSC::Heap::isDeferred):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
* jit/JITDriver.h: Removed.
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
(JSC::jitCompileFor):
(JSC::lazyLinkFor):
* jit/JITToDFGDeferredCompilationCallback.cpp: Added.
(JSC::JITToDFGDeferredCompilationCallback::JITToDFGDeferredCompilationCallback):
(JSC::JITToDFGDeferredCompilationCallback::~JITToDFGDeferredCompilationCallback):
(JSC::JITToDFGDeferredCompilationCallback::create):
(JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
* jit/JITToDFGDeferredCompilationCallback.h: Added.
* llint/LLIntEntrypoints.cpp:
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
* llint/LLIntEntrypoints.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
(JSC::LLInt::setUpCall):
* runtime/ArrayPrototype.cpp:
(JSC::isNumericCompareFunction):
* runtime/CommonSlowPaths.cpp:
* runtime/CompilationResult.cpp:
(WTF::printInternal):
* runtime/CompilationResult.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::installCode):
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::newReplacementCodeBlockFor):
(JSC::ScriptExecutable::prepareForExecutionImpl):
* runtime/Executable.h:
(JSC::ScriptExecutable::prepareForExecution):
(JSC::FunctionExecutable::jettisonOptimizedCodeFor):
* runtime/ExecutionHarness.h: Removed.
2013-08-28 Chris Curtis
https://bugs.webkit.org/show_bug.cgi?id=119548
Refactoring Exception throws.
Reviewed by Geoffrey Garen.
Gardening of exception throws. The act of throwing an exception was being handled in
different ways depending on whether the code was running in the LLint, Baseline JIT,
or the DFG Jit. This made development in the vm exception and error objects difficult.
* runtime/VM.cpp:
(JSC::appendSourceToError):
This function moved from the interpreter into the VM. It views the developers code
(if there is a codeBlock) to extract what was trying to be evaluated when the error
occurred.
(JSC::VM::throwException):
This function takes in the error object and sets the following:
1: The VM's exception stack
2: The VM's exception
3: Appends extra information on the error message(via appendSourceToError)
4: The error object's line number
5: The error object's column number
6: The error object's sourceURL
7: The error object's stack trace (unless it already exists because the developer
created the error object).
(JSC::VM::getExceptionInfo):
(JSC::VM::setExceptionInfo):
(JSC::VM::clearException):
(JSC::clearExceptionStack):
* runtime/VM.h:
(JSC::VM::exceptionOffset):
(JSC::VM::exception):
(JSC::VM::addressOfException):
(JSC::VM::exceptionStack):
VM exception and exceptionStack are now private data members.
* interpreter/Interpreter.h:
(JSC::ClearExceptionScope::ClearExceptionScope):
Created this structure to temporarily clear the exception within the VM. This
needed to see if addition errors occur when setting the debugger as we are
unwinding the stack.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::unwind):
Removed the code that would try to add error information if it did not exist.
All of this functionality has moved into the VM and all error information is set
at the time the error occurs.
The rest of these functions reference the new calling convention to throw an error.
* API/APICallbackFunction.h:
(JSC::APICallbackFunction::call):
* API/JSCallbackConstructor.cpp:
(JSC::constructJSCallback):
* API/JSCallbackObjectFunctions.h:
(JSC::::getOwnPropertySlot):
(JSC::::defaultValue):
(JSC::::put):
(JSC::::putByIndex):
(JSC::::deleteProperty):
(JSC::::construct):
(JSC::::customHasInstance):
(JSC::::call):
(JSC::::getStaticValue):
(JSC::::staticFunctionGetter):
(JSC::::callbackGetter):
* debugger/Debugger.cpp:
(JSC::evaluateInGlobalCallFrame):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluate):
* dfg/DFGAssemblyHelpers.h:
(JSC::DFG::AssemblyHelpers::emitExceptionCheck):
* dfg/DFGOperations.cpp:
(JSC::DFG::operationPutByValInternal):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::callCheck):
* heap/Heap.cpp:
(JSC::Heap::markRoots):
* interpreter/CallFrame.h:
(JSC::ExecState::clearException):
(JSC::ExecState::exception):
(JSC::ExecState::hadException):
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::loadVarargs):
(JSC::stackTraceAsString):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
* interpreter/Interpreter.h:
(JSC::ClearExceptionScope::ClearExceptionScope):
* jit/JITCode.cpp:
(JSC::JITCode::execute):
* jit/JITExceptions.cpp:
(JSC::genericThrow):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileCTINativeCall):
(JSC::JIT::emit_op_catch):
* jit/JITStubs.cpp:
(JSC::returnToThrowTrampoline):
(JSC::throwExceptionFromOpCall):
(JSC::DEFINE_STUB_FUNCTION):
(JSC::jitCompileFor):
(JSC::lazyLinkFor):
(JSC::putByVal):
(JSC::cti_vm_handle_exception):
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::call):
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* jsc.cpp:
(functionRun):
(functionLoad):
(functionCheckSyntax):
* llint/LLIntExceptions.cpp:
(JSC::LLInt::doThrow):
(JSC::LLInt::returnToThrow):
(JSC::LLInt::callToThrow):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.cpp:
(JSC::CLoop::execute):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/ArrayConstructor.cpp:
(JSC::constructArrayWithSizeQuirk):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opIn):
* runtime/CommonSlowPathsExceptions.cpp:
(JSC::CommonSlowPaths::interpreterThrowInCaller):
* runtime/Completion.cpp:
(JSC::evaluate):
* runtime/Error.cpp:
(JSC::addErrorInfo):
(JSC::throwTypeError):
(JSC::throwSyntaxError):
* runtime/Error.h:
(JSC::throwVMError):
* runtime/ExceptionHelpers.cpp:
(JSC::throwOutOfMemoryError):
(JSC::throwStackOverflowError):
(JSC::throwTerminatedExecutionException):
* runtime/Executable.cpp:
(JSC::EvalExecutable::create):
(JSC::FunctionExecutable::produceCodeBlockFor):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
(JSC::JSArray::put):
(JSC::JSArray::push):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toObjectSlowCase):
(JSC::JSValue::synthesizePrototype):
(JSC::JSValue::putToPrimitive):
* runtime/JSFunction.cpp:
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::::create):
(JSC::::createUninitialized):
(JSC::::validateRange):
(JSC::::setWithSpecificType):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode):
(JSC::decode):
(JSC::globalFuncProtoSetter):
* runtime/JSNameScope.cpp:
(JSC::JSNameScope::put):
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue):
(JSC::Walker::walk):
* runtime/JSObject.cpp:
(JSC::JSObject::put):
(JSC::JSObject::defaultValue):
(JSC::JSObject::hasInstance):
(JSC::JSObject::defaultHasInstance):
(JSC::JSObject::defineOwnNonIndexProperty):
(JSC::throwTypeError):
* runtime/ObjectConstructor.cpp:
(JSC::toPropertyDescriptor):
* runtime/RegExpConstructor.cpp:
(JSC::constructRegExp):
* runtime/StringObject.cpp:
(JSC::StringObject::defineOwnProperty):
* runtime/StringRecursionChecker.cpp:
(JSC::StringRecursionChecker::throwStackOverflowError):
2013-08-28 Zan Dobersek
[GTK] Add support for building JSC with FTL JIT enabled
https://bugs.webkit.org/show_bug.cgi?id=120270
Reviewed by Filip Pizlo.
* GNUmakefile.am: Add LLVM_LIBS to the list of linker flags and LLVM_CFLAGS to the list of
compiler flags for the JSC library.
* GNUmakefile.list.am: Add the missing build targets.
* ftl/FTLAbbreviations.h: Include the header and use std::strlen. This avoids compilation
failures when using the Clang compiler with the libstdc++ standard library.
(JSC::FTL::mdKindID):
(JSC::FTL::mdString):
2013-08-23 Andy Estes
Fix issues found by the Clang Static Analyzer
https://bugs.webkit.org/show_bug.cgi?id=120230
Reviewed by Darin Adler.
* API/JSValue.mm:
(valueToString): Don't leak every CFStringRef when in Objective-C GC.
* API/ObjCCallbackFunction.mm:
(JSC::ObjCCallbackFunctionImpl::~ObjCCallbackFunctionImpl): Don't
release m_invocation's target since NSInvocation will do it for us on
-dealloc.
(objCCallbackFunctionForBlock): Tell NSInvocation to retain its target
and -release our reference to the copied block.
* API/tests/minidom.c:
(createStringWithContentsOfFile): Free buffer before returning.
* API/tests/testapi.c:
(createStringWithContentsOfFile): Ditto.
2013-08-26 Brent Fulgham
[Windows] Unreviewed build fix after r154629.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add missing build files.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2013-08-26 Ryosuke Niwa
Windows build fix attempt after r154629.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2013-08-25 Mark Hahnenberg
JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage does a check on the length of the ArrayStorage after possible reallocing it
https://bugs.webkit.org/show_bug.cgi?id=120278
Reviewed by Geoffrey Garen.
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
2013-08-26 Filip Pizlo
Fix indention of Executable.h.
Rubber stamped by Mark Hahnenberg.
* runtime/Executable.h:
2013-08-26 Mark Hahnenberg
Object.defineProperty should be able to create a PropertyDescriptor where m_attributes == 0
https://bugs.webkit.org/show_bug.cgi?id=120314
Reviewed by Darin Adler.
Currently with the way that defineProperty works, we leave a stray low bit set in
PropertyDescriptor::m_attributes in the following code:
var o = {};
Object.defineProperty(o, 100, {writable:true, enumerable:true, configurable:true, value:"foo"});
This is due to the fact that the lowest non-zero attribute (ReadOnly) is represented as 1
Add support for Promises
https://bugs.webkit.org/show_bug.cgi?id=120260
Reviewed by Darin Adler.
Add an initial implementation of Promises - http://dom.spec.whatwg.org/#promises.
- Despite Promises being defined in the DOM, the implementation is being put in JSC
in preparation for the Promises eventually being defined in ECMAScript.
* CMakeLists.txt:
* DerivedSources.make:
* DerivedSources.pri:
* GNUmakefile.list.am:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
Add new files.
* jsc.cpp:
Update jsc's GlobalObjectMethodTable to stub out the new QueueTaskToEventLoop callback. This mean's
you can't quite use Promises with with the command line tool yet.
* interpreter/CallFrame.h:
(JSC::ExecState::promisePrototypeTable):
(JSC::ExecState::promiseConstructorTable):
(JSC::ExecState::promiseResolverPrototypeTable):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
* runtime/VM.h:
Add supporting code for the new static lookup tables.
* runtime/CommonIdentifiers.h:
Add 3 new identifiers, "Promise", "PromiseResolver", and "then".
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::reset):
(JSC::JSGlobalObject::visitChildren):
Add supporting code Promise and PromiseResolver's constructors and structures.
* runtime/JSGlobalObject.h:
(JSC::TaskContext::~TaskContext):
Add a new callback to the GlobalObjectMethodTable to post a task on the embedder's runloop.
(JSC::JSGlobalObject::promisePrototype):
(JSC::JSGlobalObject::promiseResolverPrototype):
(JSC::JSGlobalObject::promiseStructure):
(JSC::JSGlobalObject::promiseResolverStructure):
(JSC::JSGlobalObject::promiseCallbackStructure):
(JSC::JSGlobalObject::promiseWrapperCallbackStructure):
Add supporting code Promise and PromiseResolver's constructors and structures.
* runtime/JSPromise.cpp: Added.
* runtime/JSPromise.h: Added.
* runtime/JSPromiseCallback.cpp: Added.
* runtime/JSPromiseCallback.h: Added.
* runtime/JSPromiseConstructor.cpp: Added.
* runtime/JSPromiseConstructor.h: Added.
* runtime/JSPromisePrototype.cpp: Added.
* runtime/JSPromisePrototype.h: Added.
* runtime/JSPromiseResolver.cpp: Added.
* runtime/JSPromiseResolver.h: Added.
* runtime/JSPromiseResolverConstructor.cpp: Added.
* runtime/JSPromiseResolverConstructor.h: Added.
* runtime/JSPromiseResolverPrototype.cpp: Added.
* runtime/JSPromiseResolverPrototype.h: Added.
Add Promise implementation.
2013-08-26 Zan Dobersek
Plenty of -Wcast-align warnings in KeywordLookup.h
https://bugs.webkit.org/show_bug.cgi?id=120316
Reviewed by Darin Adler.
* KeywordLookupGenerator.py: Use reinterpret_cast instead of a C-style cast when casting
the character pointers to types of larger size. This avoids spewing lots of warnings
in the KeywordLookup.h header when compiling with the -Wcast-align option.
2013-08-26 Gavin Barraclough
RegExpMatchesArray should not call [[put]]
https://bugs.webkit.org/show_bug.cgi?id=120317
Reviewed by Oliver Hunt.
This will call accessors on the JSObject/JSArray prototypes - so adding an accessor or read-only
property called index or input to either of these prototypes will result in broken behavior.
* runtime/RegExpMatchesArray.cpp:
(JSC::RegExpMatchesArray::reifyAllProperties):
- put -> putDirect
2013-08-24 Filip Pizlo
FloatTypedArrayAdaptor::toJSValue should almost certainly not use jsNumber() since that attempts int conversions
https://bugs.webkit.org/show_bug.cgi?id=120228
Reviewed by Oliver Hunt.
It turns out that there were three problems:
- Using jsNumber() meant that we were converting doubles to integers and then
possibly back again whenever doing a set() between floating point arrays.
- Slow-path accesses to double typed arrays were slower than necessary because
of the to-int conversion attempt.
- The use of JSValue as an intermediate for converting between differen types
in typedArray.set() resulted in worse code than I had previously expected.
This patch solves the problem by using template double-dispatch to ensure that
that C++ compiler sees the simplest possible combination of casts between any
combination of typed array types, while still preserving JS and typed array
conversion semantics. Conversions are done as follows:
SourceAdaptor::convertTo(value)
Internally, convertTo() calls one of three possible methods on TargetAdaptor,
with one method for each of int32_t, uint32_t, and double. This means that the
C++ compiler will at worst see a widening cast to one of those types followed
by a narrowing conversion (not necessarily a cast - may have clamping or the
JS toInt32() function).
This change doesn't just affect typedArray.set(); it also affects slow-path
accesses to typed arrays as well. This patch also adds a bunch of new test
coverage.
This change is a ~50% speed-up on typedArray.set() involving floating point
types.
* GNUmakefile.list.am:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/GenericTypedArrayView.h:
(JSC::GenericTypedArrayView::set):
* runtime/JSDataViewPrototype.cpp:
(JSC::setData):
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
(JSC::JSGenericTypedArrayView::setIndexQuickly):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::::setWithSpecificType):
(JSC::::set):
* runtime/ToNativeFromValue.h: Added.
(JSC::toNativeFromValue):
* runtime/TypedArrayAdaptors.h:
(JSC::IntegralTypedArrayAdaptor::toJSValue):
(JSC::IntegralTypedArrayAdaptor::toDouble):
(JSC::IntegralTypedArrayAdaptor::toNativeFromInt32):
(JSC::IntegralTypedArrayAdaptor::toNativeFromUint32):
(JSC::IntegralTypedArrayAdaptor::toNativeFromDouble):
(JSC::IntegralTypedArrayAdaptor::convertTo):
(JSC::FloatTypedArrayAdaptor::toJSValue):
(JSC::FloatTypedArrayAdaptor::toDouble):
(JSC::FloatTypedArrayAdaptor::toNativeFromInt32):
(JSC::FloatTypedArrayAdaptor::toNativeFromUint32):
(JSC::FloatTypedArrayAdaptor::toNativeFromDouble):
(JSC::FloatTypedArrayAdaptor::convertTo):
(JSC::Uint8ClampedAdaptor::toJSValue):
(JSC::Uint8ClampedAdaptor::toDouble):
(JSC::Uint8ClampedAdaptor::toNativeFromInt32):
(JSC::Uint8ClampedAdaptor::toNativeFromUint32):
(JSC::Uint8ClampedAdaptor::toNativeFromDouble):
(JSC::Uint8ClampedAdaptor::convertTo):
2013-08-24 Dan Bernstein
[mac] link against libz in a more civilized manner
https://bugs.webkit.org/show_bug.cgi?id=120258
Reviewed by Darin Adler.
* Configurations/JavaScriptCore.xcconfig: Removed “-lz†from OTHER_LDFLAGS_BASE.
* JavaScriptCore.xcodeproj/project.pbxproj: Added libz.dylib to the JavaScriptCore target’s
Link Binary With Libraries build phase.
2013-08-23 Laszlo Papp
Failure building with python3
https://bugs.webkit.org/show_bug.cgi?id=106645
Reviewed by Benjamin Poulain.
Use print functions instead of python statements to be compatible with python 3.X and 2.7 as well.
Archlinux has been using python3 and that is what causes issues while packaging QtWebKit along with Qt5.
* disassembler/udis86/itab.py:
(UdItabGenerator.genInsnTable):
* disassembler/udis86/ud_opcode.py:
(UdOpcodeTables.print_table):
* disassembler/udis86/ud_optable.py:
(UdOptableXmlParser.parseDef):
(UdOptableXmlParser.parse):
(printFn):
2013-08-23 Filip Pizlo
Incorrect TypedArray#set behavior
https://bugs.webkit.org/show_bug.cgi?id=83818
Reviewed by Oliver Hunt and Mark Hahnenberg.
This was so much fun! typedArray.set() is like a memmove on steroids, and I'm
not smart enough to figure out optimal versions for *all* of the cases. But I
did come up with optimal implementations for most of the cases, and I wrote
spec-literal code (i.e. copy via a transfer buffer) for the cases I'm not smart
enough to write optimal code for.
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::hasArrayBuffer):
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::buffer):
(JSC::JSArrayBufferView::existingBufferInButterfly):
(JSC::JSArrayBufferView::neuter):
(JSC::JSArrayBufferView::byteOffset):
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::::setWithSpecificType):
(JSC::::set):
(JSC::::existingBuffer):
2013-08-23 Alex Christensen
Re-separating Win32 and Win64 builds.
https://bugs.webkit.org/show_bug.cgi?id=120178
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
Pass PlatformArchitecture as a command line parameter to bash scripts.
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh:
* JavaScriptCore.vcxproj/build-generated-files.sh:
Use PlatformArchitecture from command line to determine which object directory to use (obj32 or obj64).
2013-08-22 Filip Pizlo
build-jsc --ftl-jit should work
https://bugs.webkit.org/show_bug.cgi?id=120194
Reviewed by Oliver Hunt.
* Configurations/Base.xcconfig: CPPFLAGS should include FEATURE_DEFINES
* Configurations/JSC.xcconfig: The 'jsc' tool includes headers where field layout may depend on FEATURE_DEFINES
* Configurations/ToolExecutable.xcconfig: All other tools include headers where field layout may depend on FEATURE_DEFINES
* ftl/FTLLowerDFGToLLVM.cpp: Build fix
(JSC::FTL::LowerDFGToLLVM::compilePutStructure):
(JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):
2013-08-23 Oliver Hunt
Re-sort xcode project file
* JavaScriptCore.xcodeproj/project.pbxproj:
2013-08-23 Oliver Hunt
Support in memory compression of rarely used data
https://bugs.webkit.org/show_bug.cgi?id=120143
Reviewed by Gavin Barraclough.
Include zlib in LD_FLAGS and make UnlinkedCodeBlock make use of CompressibleVector. This saves ~200k on google maps.
* Configurations/JavaScriptCore.xcconfig:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
(JSC::UnlinkedCodeBlock::addExpressionInfo):
* bytecode/UnlinkedCodeBlock.h:
2013-08-22 Mark Hahnenberg
JSObject and JSArray code shouldn't have to tiptoe around garbage collection
https://bugs.webkit.org/show_bug.cgi?id=120179
Reviewed by Geoffrey Garen.
There are many places in the code for JSObject and JSArray where they are manipulating their
Butterfly/Structure, e.g. after expanding their out-of-line backing storage via allocating. Within
these places there are certain "critical sections" where a GC would be disastrous. Gen GC looks
like it will make this dance even more intricate. To make everybody's lives easier we should use
the DeferGC mechanism in these functions to make these GC critical sections both obvious in the
code and trivially safe. Deferring collections will usually only last marginally longer, thus we
should not incur any additional overhead.
* heap/Heap.h:
* runtime/JSArray.cpp:
(JSC::JSArray::unshiftCountSlowCase):
* runtime/JSObject.cpp:
(JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
(JSC::JSObject::createInitialUndecided):
(JSC::JSObject::createInitialInt32):
(JSC::JSObject::createInitialDouble):
(JSC::JSObject::createInitialContiguous):
(JSC::JSObject::createArrayStorage):
(JSC::JSObject::convertUndecidedToArrayStorage):
(JSC::JSObject::convertInt32ToArrayStorage):
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
(JSC::JSObject::increaseVectorLength):
(JSC::JSObject::ensureLengthSlow):
* runtime/JSObject.h:
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
(JSC::JSObject::putDirectWithoutTransition):
2013-08-22 Filip Pizlo
Update LLVM binary drops and scripts to the latest version from SVN
https://bugs.webkit.org/show_bug.cgi?id=120184
Reviewed by Mark Hahnenberg.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
2013-08-22 Gavin Barraclough
Don't leak registers for redeclared variables
https://bugs.webkit.org/show_bug.cgi?id=120174
Reviewed by Geoff Garen.
We currently always allocate registers for new global variables, but these are wasted when the variable is being redeclared.
Only allocate new registers when necessary.
No performance impact.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* runtime/Executable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
- Don't allocate the register here.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::addGlobalVar):
- Allocate the register here instead.
2013-08-22 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120128
Remove putDirectVirtual
Unreviewed, checked in commented out code. :-(
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
- delete commented out code
2013-08-22 Gavin Barraclough
Error.stack should not be enumerable
https://bugs.webkit.org/show_bug.cgi?id=120171
Reviewed by Oliver Hunt.
Breaks ECMA tests.
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
- None -> DontEnum
2013-08-21 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120128
Remove putDirectVirtual
Reviewed by Sam Weinig.
This could most generously be described as 'vestigial'.
No performance impact.
* API/JSObjectRef.cpp:
(JSObjectSetProperty):
- changed to use defineOwnProperty
* debugger/DebuggerActivation.cpp:
* debugger/DebuggerActivation.h:
- remove putDirectVirtual
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
- changed to use defineOwnProperty
* runtime/ClassInfo.h:
* runtime/JSActivation.cpp:
* runtime/JSActivation.h:
* runtime/JSCell.cpp:
* runtime/JSCell.h:
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
* runtime/JSObject.cpp:
* runtime/JSObject.h:
* runtime/JSProxy.cpp:
* runtime/JSProxy.h:
* runtime/JSSymbolTableObject.cpp:
* runtime/JSSymbolTableObject.h:
- remove putDirectVirtual
* runtime/PropertyDescriptor.h:
(JSC::PropertyDescriptor::PropertyDescriptor):
- added constructor for convenience
2013-08-22 Chris Curtis
errorDescriptionForValue() should not assume error value is an Object
https://bugs.webkit.org/show_bug.cgi?id=119812
Reviewed by Geoffrey Garen.
Added a check to make sure that the JSValue was an object before casting it as an object. Also, in case the parameterized JSValue
has no type, the function now returns the empty string.
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue):
2013-08-22 Julien Brianceau
Fix P_DFGOperation_EJS call for MIPS and ARM EABI.
https://bugs.webkit.org/show_bug.cgi?id=120107
Reviewed by Yong Li.
EncodedJSValue parameters must be aligned to even registers for MIPS and ARM EABI.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
2013-08-21 Commit Queue
Unreviewed, rolling out r154416.
http://trac.webkit.org/changeset/154416
https://bugs.webkit.org/show_bug.cgi?id=120147
Broke Windows builds (Requested by rniwa on #webkit).
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh:
* JavaScriptCore.vcxproj/build-generated-files.sh:
2013-08-21 Gavin Barraclough
Clarify var/const/function declaration
https://bugs.webkit.org/show_bug.cgi?id=120144
Reviewed by Sam Weinig.
Add methods to JSGlobalObject to declare vars, consts, and functions.
* runtime/Executable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/Executable.h:
- Moved declaration code to JSGlobalObject
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::addGlobalVar):
- internal implementation of addVar, addConst, addFunction
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::addVar):
(JSC::JSGlobalObject::addConst):
(JSC::JSGlobalObject::addFunction):
- Added methods to declare vars, consts, and functions
2013-08-21 Yi Shen
https://bugs.webkit.org/show_bug.cgi?id=119900
Exception in global setter doesn't unwind correctly
Reviewed by Geoffrey Garen.
Call VM_THROW_EXCEPTION_AT_END in op_put_to_scope if the setter throws exception.
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
2013-08-21 Mark Hahnenberg
Rename/refactor setButterfly/setStructure
https://bugs.webkit.org/show_bug.cgi?id=120138
Reviewed by Geoffrey Garen.
setButterfly becomes setStructureAndButterfly.
Also removed the Butterfly* argument from setStructure and just implicitly
used m_butterfly internally since that's what every single client of setStructure
was doing already.
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* runtime/JSObject.cpp:
(JSC::JSObject::notifyPresenceOfIndexedAccessors):
(JSC::JSObject::createInitialUndecided):
(JSC::JSObject::createInitialInt32):
(JSC::JSObject::createInitialDouble):
(JSC::JSObject::createInitialContiguous):
(JSC::JSObject::createArrayStorage):
(JSC::JSObject::convertUndecidedToInt32):
(JSC::JSObject::convertUndecidedToDouble):
(JSC::JSObject::convertUndecidedToContiguous):
(JSC::JSObject::convertUndecidedToArrayStorage):
(JSC::JSObject::convertInt32ToDouble):
(JSC::JSObject::convertInt32ToContiguous):
(JSC::JSObject::convertInt32ToArrayStorage):
(JSC::JSObject::genericConvertDoubleToContiguous):
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
(JSC::JSObject::switchToSlowPutArrayStorage):
(JSC::JSObject::setPrototype):
(JSC::JSObject::putDirectAccessor):
(JSC::JSObject::seal):
(JSC::JSObject::freeze):
(JSC::JSObject::preventExtensions):
(JSC::JSObject::reifyStaticFunctionsForDelete):
(JSC::JSObject::removeDirect):
* runtime/JSObject.h:
(JSC::JSObject::setStructureAndButterfly):
(JSC::JSObject::setStructure):
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
(JSC::JSObject::putDirectWithoutTransition):
* runtime/Structure.cpp:
(JSC::Structure::flattenDictionaryStructure):
2013-08-21 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120127
Remove JSObject::propertyIsEnumerable
Unreviewed typo fix
* runtime/JSObject.h:
- fix typo
2013-08-21 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120139
PropertyDescriptor argument to define methods should be const
Rubber stamped by Sam Weinig.
This should never be modified, and this way we can use rvalues.
* debugger/DebuggerActivation.cpp:
(JSC::DebuggerActivation::defineOwnProperty):
* debugger/DebuggerActivation.h:
* runtime/Arguments.cpp:
(JSC::Arguments::defineOwnProperty):
* runtime/Arguments.h:
* runtime/ClassInfo.h:
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
* runtime/JSArray.h:
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::defineOwnProperty):
* runtime/JSArrayBuffer.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::defineOwnProperty):
* runtime/JSArrayBufferView.h:
* runtime/JSCell.cpp:
(JSC::JSCell::defineOwnProperty):
* runtime/JSCell.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::defineOwnProperty):
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::::defineOwnProperty):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::defineOwnProperty):
* runtime/JSGlobalObject.h:
* runtime/JSObject.cpp:
(JSC::JSObject::putIndexedDescriptor):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::putDescriptor):
(JSC::JSObject::defineOwnNonIndexProperty):
(JSC::JSObject::defineOwnProperty):
* runtime/JSObject.h:
* runtime/JSProxy.cpp:
(JSC::JSProxy::defineOwnProperty):
* runtime/JSProxy.h:
* runtime/RegExpMatchesArray.h:
(JSC::RegExpMatchesArray::defineOwnProperty):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
* runtime/RegExpObject.h:
* runtime/StringObject.cpp:
(JSC::StringObject::defineOwnProperty):
* runtime/StringObject.h:
- make PropertyDescriptor const
2013-08-21 Filip Pizlo
REGRESSION: Crash under JITCompiler::link while loading Gmail
https://bugs.webkit.org/show_bug.cgi?id=119872
Reviewed by Mark Hahnenberg.
Apparently, unsigned + signed = unsigned. Work around it with a cast.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2013-08-21 Alex Christensen Separating Win32 and Win64 builds.
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
Pass PlatformArchitecture as a command line parameter to bash scripts.
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh:
* JavaScriptCore.vcxproj/build-generated-files.sh:
Use PlatformArchitecture from command line to determine which object directory to use (obj32 or obj64).
2013-08-21 Filip Pizlo
Assertion failure in JSC::SlotVisitor::copyLater when marking JSDataView
https://bugs.webkit.org/show_bug.cgi?id=120099
Reviewed by Mark Hahnenberg.
JSDataView should not store the ArrayBuffer* in the butterfly indexing header, since
JSDataView may have ordinary JS indexed properties.
* runtime/ClassInfo.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
(JSC::JSArrayBufferView::finishCreation):
* runtime/JSArrayBufferView.h:
(JSC::hasArrayBuffer):
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::buffer):
(JSC::JSArrayBufferView::neuter):
(JSC::JSArrayBufferView::byteOffset):
* runtime/JSCell.cpp:
(JSC::JSCell::slowDownAndWasteMemory):
* runtime/JSCell.h:
* runtime/JSDataView.cpp:
(JSC::JSDataView::JSDataView):
(JSC::JSDataView::create):
(JSC::JSDataView::slowDownAndWasteMemory):
* runtime/JSDataView.h:
(JSC::JSDataView::buffer):
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::::visitChildren):
(JSC::::slowDownAndWasteMemory):
2013-08-21 Mark Hahnenberg
Remove incorrect ASSERT from CopyVisitor::visitItem
Rubber stamped by Filip Pizlo.
* heap/CopyVisitorInlines.h:
(JSC::CopyVisitor::visitItem):
2013-08-21 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120127
Remove JSObject::propertyIsEnumerable
Reviewed by Sam Weinig.
This method is just a wart - it contains unnecessary const-casting, function call overhead, and LOC.
* runtime/JSObject.cpp:
* runtime/JSObject.h:
- remove propertyIsEnumerable
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncPropertyIsEnumerable):
- Move implementation here using getOwnPropertyDescriptor directly.
2013-08-20 Filip Pizlo
DFG should inline new typedArray()
https://bugs.webkit.org/show_bug.cgi?id=120022
Reviewed by Oliver Hunt.
Adds inlining of typed array allocations in the DFG. Any operation of the
form:
new foo(blah)
or:
foo(blah)
where 'foo' is a typed array constructor and 'blah' is exactly one argument,
is turned into the NewTypedArray intrinsic. Later, of child1 (i.e. 'blah')
is predicted integer, we generate inline code for an allocation. Otherwise
it turns into a call to an operation that behaves like the constructor would
if it was passed one argument (i.e. it may wrap a buffer or it may create a
copy or another array, or it may allocate an array of that length).
* bytecode/SpeculatedType.cpp:
(JSC::speculationFromTypedArrayType):
(JSC::speculationFromClassInfo):
* bytecode/SpeculatedType.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
* dfg/DFGCCallHelpers.h:
(JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::putStructureStoreElimination):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasTypedArrayType):
(JSC::DFG::Node::typedArrayType):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::newTypedArrayWithSize):
(JSC::DFG::newTypedArrayWithOneArgument):
* dfg/DFGOperations.h:
(JSC::DFG::operationNewTypedArrayWithSizeForType):
(JSC::DFG::operationNewTypedArrayWithOneArgumentForType):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewTypedArray):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_object):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_new_object):
* runtime/JSArray.h:
(JSC::JSArray::allocationSize):
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::allocationSize):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayView):
* runtime/JSObject.h:
(JSC::JSFinalObject::allocationSize):
* runtime/TypedArrayType.cpp:
(JSC::constructorClassInfoForType):
* runtime/TypedArrayType.h:
(JSC::indexToTypedArrayType):
2013-08-21 Julien Brianceau Fix V_DFGOperation_EJPP signature in DFG.
Reviewed by Geoffrey Garen.
* dfg/DFGOperations.h:
2013-08-20 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120093
Remove getOwnPropertyDescriptor trap
Reviewed by Geoff Garen.
All implementations of this method are now called via the method table, and equivalent in behaviour.
Remove all duplicate implementations (and the method table trap), and add a single member function implementation on JSObject.
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
* debugger/DebuggerActivation.cpp:
* debugger/DebuggerActivation.h:
* runtime/Arguments.cpp:
* runtime/Arguments.h:
* runtime/ArrayConstructor.cpp:
* runtime/ArrayConstructor.h:
* runtime/ArrayPrototype.cpp:
* runtime/ArrayPrototype.h:
* runtime/BooleanPrototype.cpp:
* runtime/BooleanPrototype.h:
- remove getOwnPropertyDescriptor
* runtime/ClassInfo.h:
- remove getOwnPropertyDescriptor from MethodTable
* runtime/DateConstructor.cpp:
* runtime/DateConstructor.h:
* runtime/DatePrototype.cpp:
* runtime/DatePrototype.h:
* runtime/ErrorPrototype.cpp:
* runtime/ErrorPrototype.h:
* runtime/JSActivation.cpp:
* runtime/JSActivation.h:
* runtime/JSArray.cpp:
* runtime/JSArray.h:
* runtime/JSArrayBuffer.cpp:
* runtime/JSArrayBuffer.h:
* runtime/JSArrayBufferView.cpp:
* runtime/JSArrayBufferView.h:
* runtime/JSCell.cpp:
* runtime/JSCell.h:
* runtime/JSDataView.cpp:
* runtime/JSDataView.h:
* runtime/JSDataViewPrototype.cpp:
* runtime/JSDataViewPrototype.h:
* runtime/JSFunction.cpp:
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
* runtime/JSNotAnObject.cpp:
* runtime/JSNotAnObject.h:
* runtime/JSONObject.cpp:
* runtime/JSONObject.h:
- remove getOwnPropertyDescriptor
* runtime/JSObject.cpp:
(JSC::JSObject::propertyIsEnumerable):
- switch to call new getOwnPropertyDescriptor member function
(JSC::JSObject::getOwnPropertyDescriptor):
- new, based on imlementation from GET_OWN_PROPERTY_DESCRIPTOR_IMPL
(JSC::JSObject::defineOwnNonIndexProperty):
- switch to call new getOwnPropertyDescriptor member function
* runtime/JSObject.h:
* runtime/JSProxy.cpp:
* runtime/JSProxy.h:
* runtime/NamePrototype.cpp:
* runtime/NamePrototype.h:
* runtime/NumberConstructor.cpp:
* runtime/NumberConstructor.h:
* runtime/NumberPrototype.cpp:
* runtime/NumberPrototype.h:
- remove getOwnPropertyDescriptor
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
- switch to call new getOwnPropertyDescriptor member function
* runtime/ObjectConstructor.h:
- remove getOwnPropertyDescriptor
* runtime/PropertyDescriptor.h:
- remove GET_OWN_PROPERTY_DESCRIPTOR_IMPL
* runtime/RegExpConstructor.cpp:
* runtime/RegExpConstructor.h:
* runtime/RegExpMatchesArray.cpp:
* runtime/RegExpMatchesArray.h:
* runtime/RegExpObject.cpp:
* runtime/RegExpObject.h:
* runtime/RegExpPrototype.cpp:
* runtime/RegExpPrototype.h:
* runtime/StringConstructor.cpp:
* runtime/StringConstructor.h:
* runtime/StringObject.cpp:
* runtime/StringObject.h:
- remove getOwnPropertyDescriptor
2013-08-20 Mark Hahnenberg Flattening a dictionary can cause CopiedSpace corruption
Reviewed by Oliver Hunt.
When we flatten an object in dictionary mode, we compact its properties. If the object
had out-of-line storage in the form of a Butterfly prior to this compaction, and after
compaction its properties fit inline, the object's Structure "forgets" that the object
has a non-zero Butterfly pointer. During GC, we check the Butterfly and reportLiveBytes
with bytes = 0, which causes all sorts of badness in CopiedSpace.
Instead, after we flatten a dictionary, if properties fit inline we should clear the
Butterfly pointer so that the GC doesn't get confused later.
This patch does this clearing, and it also adds JSObject::checkStructure, which overrides
JSCell::checkStructure to add an ASSERT that makes sure that the Structure being assigned
agrees with the whether or not the object has a Butterfly. Also added an ASSERT to check
that the number of bytes reported to SlotVisitor::copyLater is non-zero.
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::copyLater):
* runtime/JSObject.cpp:
(JSC::JSObject::notifyPresenceOfIndexedAccessors):
(JSC::JSObject::convertUndecidedToInt32):
(JSC::JSObject::convertUndecidedToDouble):
(JSC::JSObject::convertUndecidedToContiguous):
(JSC::JSObject::convertInt32ToDouble):
(JSC::JSObject::convertInt32ToContiguous):
(JSC::JSObject::genericConvertDoubleToContiguous):
(JSC::JSObject::switchToSlowPutArrayStorage):
(JSC::JSObject::setPrototype):
(JSC::JSObject::putDirectAccessor):
(JSC::JSObject::seal):
(JSC::JSObject::freeze):
(JSC::JSObject::preventExtensions):
(JSC::JSObject::reifyStaticFunctionsForDelete):
(JSC::JSObject::removeDirect):
* runtime/JSObject.h:
(JSC::JSObject::setButterfly):
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::setStructure):
(JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
* runtime/Structure.cpp:
(JSC::Structure::flattenDictionaryStructure):
2013-08-20 Alex Christensen
Compile fix for Win64 after r154156.
Rubber stamped by Oliver Hunt.
* jit/JITStubsMSVC64.asm:
Renamed ctiVMThrowTrampolineSlowpath to ctiVMHandleException and
cti_vm_throw_slowpath to cti_vm_handle_exception.
2013-08-20 Alex Christensen More work towards a Win64 build
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
* JavaScriptCore.vcxproj/copy-files.cmd:
* JavaScriptCore.vcxproj/jsc/jscCommon.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
Use PlatformArchitecture macro instead of bin32, lib32, and obj32.
2013-08-20 Mark Hahnenberg Concurrent JIT crashes in various fast/js/dfg-* tests while the main thread is setting innerHTML
Reviewed by Geoffrey Garen.
More fixes for WriteBarrier deferral during concurrent JIT-ing. This patch makes the use of DesiredWriteBarriers class and the
initializeLazyWriteBarrierFor* wrapper functions more sane.
Refactored DesiredWriteBarrier to require an owner, a type, a CodeBlock, and an index. The type indicates how to use the CodeBlock
and index when triggering the WriteBarrier at the end of compilation.
The client code of initializeLazy* is now responsible for creating the WriteBarrier that will be initialized as well as passing
in the relevant index to be used at the end of compilation. Things were kind of muddled before in that one function did a
little extra work that really shouldn't have been its responsibility.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addConstant):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGDesiredWriteBarriers.cpp:
(JSC::DFG::DesiredWriteBarrier::DesiredWriteBarrier):
(JSC::DFG::DesiredWriteBarrier::trigger):
* dfg/DFGDesiredWriteBarriers.h:
(JSC::DFG::DesiredWriteBarriers::add):
(JSC::DFG::initializeLazyWriteBarrierForInlineCallFrameExecutable):
(JSC::DFG::initializeLazyWriteBarrierForInlineCallFrameCallee):
(JSC::DFG::initializeLazyWriteBarrierForConstant):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::truncateConstantToInt32):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::constantRegisterForConstant):
2013-08-20 Michael Saboff
https://bugs.webkit.org/show_bug.cgi?id=120075
REGRESSION (r128400): BBC4 website not displaying pictures
Reviewed by Oliver Hunt.
* runtime/RegExpMatchesArray.h:
(JSC::RegExpMatchesArray::createStructure): Changed the array IndexingType to be ArrayWithSlowPutArrayStorage
so that the match results will be reified before any other modification to the results array.
2013-08-19 Filip Pizlo
Incorrect behavior on emscripten-compiled cube2hash
https://bugs.webkit.org/show_bug.cgi?id=120033
Reviewed by Mark Hahnenberg.
If PutClosureVar is may-aliased to another PutClosureVar or GetClosureVar
then we should bail attempts to CSE.
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::scopedVarLoadElimination):
(JSC::DFG::CSEPhase::scopedVarStoreElimination):
2013-08-20 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120073
Remove use of GOPD from JSFunction::defineProperty
Reviewed by Oliver Hunt.
Call getOwnPropertySlot to check for existing properties instead.
* runtime/JSFunction.cpp:
(JSC::JSFunction::defineOwnProperty):
- getOwnPropertyDescriptor -> getOwnPropertySlot
2013-08-20 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120067
Remove getPropertyDescriptor
Reviewed by Oliver Hunt.
This is used by lookupGetter/lookupSetter - this can easily bee replaced by getPropertySlot.
Since we'll be getting the GetterSetter from the slot in the setter case, rename isGetter() to isAccessor().
* runtime/JSObject.cpp:
* runtime/JSObject.h:
- remove getPropertyDescriptor
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncLookupGetter):
(JSC::objectProtoFuncLookupSetter):
- replace call to getPropertyDescriptor with getPropertySlot
* runtime/PropertyDescriptor.h:
* runtime/PropertySlot.h:
(JSC::PropertySlot::isAccessor):
(JSC::PropertySlot::isCacheableGetter):
(JSC::PropertySlot::getterSetter):
- rename isGetter() to isAccessor()
2013-08-20 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120054
Remove some dead code following getOwnPropertyDescriptor cleanup
Reviewed by Oliver Hunt.
* runtime/Lookup.h:
(JSC::getStaticFunctionSlot):
- remove getStaticPropertyDescriptor, getStaticFunctionDescriptor, getStaticValueDescriptor.
2013-08-20 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120052
Remove custom getOwnPropertyDescriptor for JSProxy
Reviewed by Geoff Garen.
GET_OWN_PROPERTY_DESCRIPTOR_IMPL runs afoul with JSProxy due to the workaround for JSDOMWindow's broken behavior.
Because the window object incorrectly searches the prototype chain in getOwnPropertySlot we check that the base
object matches, but in the case of JSProxy we can end up comparing the window object to the window shell & falsely
assuming this is a prototype property. Add toThis conversion to correctly identify proxied own access. I've kept
the original slotBase check as a fast case, and also so that direct access on JSDOMWindow still works.
* runtime/JSProxy.cpp:
- Remove custom getOwnPropertyDescriptor implementation.
* runtime/PropertyDescriptor.h:
- Modify own property access check to perform toThis conversion.
2013-08-20 Alex Christensen
Use PlatformArchitecture to distinguish between 32-bit and 64-bit builds on Windows.
https://bugs.webkit.org/show_bug.cgi?id=119512
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props:
Replaced obj32, bin32, and lib32 with macros for 64-bit build.
2013-08-20 Julien Brianceau Missing ensureSpace call in sh4 baseline JIT.
Reviewed by Allan Sandfeld Jensen.
branchPtrWithPatch() of baseline JIT must ensure that space is available for its
instructions and two constants now DFG is enabled for sh4 architecture.
These missing ensureSpace calls lead to random crashes.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::branchPtrWithPatch):
2013-08-19 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=120034
Remove custom getOwnPropertyDescriptor for global objects
Reviewed by Geoff Garen.
Fix attributes of JSC SynbolTableObject entries, ensure that cross frame access is safe, and suppress prototype chain walk.
* runtime/JSGlobalObject.cpp:
- Remove custom getOwnPropertyDescriptor implementation.
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
- The symbol table does not store the DontDelete attribute, we should be adding it back in.
* runtime/PropertyDescriptor.h:
- JSDOMWindow walks the prototype chain on own access. This is bad, but for now workaround for the getOwnPropertyDescriptor case.
* runtime/PropertySlot.h:
(JSC::PropertySlot::setUndefined):
- This is used by WebCore when blocking access to properties on cross-frame access.
Mark blocked properties as read-only, non-configurable to prevent defineProperty.
2013-08-17 Filip Pizlo
DFG should inline typedArray.byteOffset
https://bugs.webkit.org/show_bug.cgi?id=119962
Reviewed by Oliver Hunt.
This adds a new node, GetTypedArrayByteOffset, which inlines
typedArray.byteOffset.
Also, I improved a bunch of the clobbering logic related to typed arrays
and clobbering in general. For example, PutByOffset/PutStructure are not
clobber-world so they can be handled by most default cases in CSE. Also,
It's better to use the 'Class_field' notation for typed arrays now that
they no longer involve magical descriptor thingies.
* bytecode/SpeculatedType.h:
* dfg/DFGAbstractHeap.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGArrayMode.h:
(JSC::DFG::neverNeedsStorage):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::getByValLoadElimination):
(JSC::DFG::CSEPhase::getByOffsetLoadElimination):
(JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
(JSC::DFG::CSEPhase::checkArrayElimination):
(JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
(JSC::DFG::CSEPhase::getTypedArrayByteOffsetLoadElimination):
(JSC::DFG::CSEPhase::performNodeCSE):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteLength):
(JSC::DFG::FixupPhase::convertToGetArrayLength):
(JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
* runtime/ArrayBuffer.h:
(JSC::ArrayBuffer::offsetOfData):
* runtime/Butterfly.h:
(JSC::Butterfly::offsetOfArrayBuffer):
* runtime/IndexingHeader.h:
(JSC::IndexingHeader::offsetOfArrayBuffer):
2013-08-18 Filip Pizlo DFG new Array() inlining could get confused about global objects
Reviewed by Geoffrey Garen.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2013-08-18 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=119995
Start removing custom implementations of getOwnPropertyDescriptor
Reviewed by Oliver Hunt.
This can now typically implemented in terms of getOwnPropertySlot.
Add a macro to PropertyDescriptor to define an implementation of GOPD in terms of GOPS.
Switch over most classes in JSC & the WebCore bindings generator to use this.
* API/JSCallbackObjectFunctions.h:
* debugger/DebuggerActivation.cpp:
* runtime/Arguments.cpp:
* runtime/ArrayConstructor.cpp:
* runtime/ArrayPrototype.cpp:
* runtime/BooleanPrototype.cpp:
* runtime/DateConstructor.cpp:
* runtime/DatePrototype.cpp:
* runtime/ErrorPrototype.cpp:
* runtime/JSActivation.cpp:
* runtime/JSArray.cpp:
* runtime/JSArrayBuffer.cpp:
* runtime/JSArrayBufferView.cpp:
* runtime/JSCell.cpp:
* runtime/JSDataView.cpp:
* runtime/JSDataViewPrototype.cpp:
* runtime/JSFunction.cpp:
* runtime/JSGenericTypedArrayViewInlines.h:
* runtime/JSNotAnObject.cpp:
* runtime/JSONObject.cpp:
* runtime/JSObject.cpp:
* runtime/NamePrototype.cpp:
* runtime/NumberConstructor.cpp:
* runtime/NumberPrototype.cpp:
* runtime/ObjectConstructor.cpp:
- Implement getOwnPropertySlot in terms of GET_OWN_PROPERTY_DESCRIPTOR_IMPL.
* runtime/PropertyDescriptor.h:
- Added GET_OWN_PROPERTY_DESCRIPTOR_IMPL macro.
* runtime/PropertySlot.h:
(JSC::PropertySlot::isValue):
(JSC::PropertySlot::isGetter):
(JSC::PropertySlot::isCustom):
(JSC::PropertySlot::isCacheableValue):
(JSC::PropertySlot::isCacheableGetter):
(JSC::PropertySlot::isCacheableCustom):
(JSC::PropertySlot::attributes):
(JSC::PropertySlot::getterSetter):
- Add accessors necessary to convert PropertySlot to descriptor.
* runtime/RegExpConstructor.cpp:
* runtime/RegExpMatchesArray.cpp:
* runtime/RegExpMatchesArray.h:
* runtime/RegExpObject.cpp:
* runtime/RegExpPrototype.cpp:
* runtime/StringConstructor.cpp:
* runtime/StringObject.cpp:
- Implement getOwnPropertySlot in terms of GET_OWN_PROPERTY_DESCRIPTOR_IMPL.
2013-08-19 Michael Saboff
https://bugs.webkit.org/show_bug.cgi?id=120015 DFG 32Bit: Crash loading "Classic" site @ translate.google.com
Reviewed by Sam Weinig.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateCell): Added checks for spillFormat being
DataFormatInteger or DataFormatDouble similar to what is in the 64 bit code and in
all versions of fillSpeculateBoolean().
2013-08-19 Michael Saboff
https://bugs.webkit.org/show_bug.cgi?id=120020 Change Set 154207 causes wrong register to be used for 32 bit tests
Reviewed by Benjamin Poulain.
Change branshTest32 to only use the byte for 8 bit test on the lower 4 registers.
Registers 4 through 7 as byte regisers are ah, ch, dh and bh instead of sp, bp, si and di.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branchTest32):
2013-08-16 Oliver Hunt Crash during exception unwinding
Reviewed by Filip Pizlo.
Add an "Unreachable" NodeType, and then rearrange op_throw and op_throw_reference_error
to plant Throw or ThrowReferenceError followed by a flush and then the Unreachable node.
We need this so that Throw and ThrowReferenceError no longer need to be treated as
terminals and the subsequent flush keeps the activation (and other registers) live.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::isTerminal):
* 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):
2013-08-19 VÃctor Manuel Jáquez Leal [GTK][ARM] javascriptcore compilation is broken
Reviewed by Oliver Hunt.
Guard the compilation of these files only if DFG_JIT is enabled.
* dfg/DFGDesiredTransitions.cpp:
* dfg/DFGDesiredTransitions.h:
* dfg/DFGDesiredWeakReferences.cpp:
* dfg/DFGDesiredWeakReferences.h:
* dfg/DFGDesiredWriteBarriers.cpp:
* dfg/DFGDesiredWriteBarriers.h:
2013-08-17 Filip Pizlo
REGRESSION(r154218): DFG::FixupPhase no longer turns GetById's child1 into CellUse
https://bugs.webkit.org/show_bug.cgi?id=119961
Reviewed by Mark Hahnenberg.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2013-08-18 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=119972
Add attributes field to PropertySlot
Reviewed by Geoff Garen.
For all JSC types, this makes getOwnPropertyDescriptor redundant.
There will be a bit more hacking required in WebCore to remove GOPD whilst maintaining current behaviour.
(Current behaviour is in many ways broken, particularly in that GOPD & GOPS are inconsistent, but we should fix incrementally).
No performance impact.
* runtime/PropertySlot.h:
(JSC::PropertySlot::setValue):
(JSC::PropertySlot::setCustom):
(JSC::PropertySlot::setCacheableCustom):
(JSC::PropertySlot::setCustomIndex):
(JSC::PropertySlot::setGetterSlot):
(JSC::PropertySlot::setCacheableGetterSlot):
- These mathods now all require 'attributes'.
* runtime/JSObject.h:
(JSC::JSObject::getDirect):
(JSC::JSObject::getDirectOffset):
(JSC::JSObject::inlineGetOwnPropertySlot):
- Added variants of getDirect, getDirectOffset that return the attributes.
* API/JSCallbackObjectFunctions.h:
(JSC::::getOwnPropertySlot):
* runtime/Arguments.cpp:
(JSC::Arguments::getOwnPropertySlotByIndex):
(JSC::Arguments::getOwnPropertySlot):
* runtime/JSActivation.cpp:
(JSC::JSActivation::symbolTableGet):
(JSC::JSActivation::getOwnPropertySlot):
* runtime/JSArray.cpp:
(JSC::JSArray::getOwnPropertySlot):
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::getOwnPropertySlot):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::getOwnPropertySlot):
* runtime/JSDataView.cpp:
(JSC::JSDataView::getOwnPropertySlot):
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::::getOwnPropertySlot):
(JSC::::getOwnPropertySlotByIndex):
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertySlotByIndex):
(JSC::JSObject::fillGetterPropertySlot):
* runtime/JSString.h:
(JSC::JSString::getStringPropertySlot):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
* runtime/Lookup.cpp:
(JSC::setUpStaticFunctionSlot):
* runtime/Lookup.h:
(JSC::getStaticPropertySlot):
(JSC::getStaticPropertyDescriptor):
(JSC::getStaticValueSlot):
(JSC::getStaticValueDescriptor):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::getOwnPropertySlot):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayEntry::get):
- Pass attributes to PropertySlot::set* methods.
2013-08-17 Mark Hahnenberg Concurrent JIT crashes in various fast/js/dfg-* tests while the main thread is setting innerHTML
Reviewed by Filip Pizlo.
Added a new mode for DesiredWriteBarrier that allows it to track a position in a
Vector of WriteBarriers rather than the specific address. The fact that we were
arbitrarily storing into a Vector's backing store for constants at the end of
compilation after the Vector could have resized was causing crashes.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::constants):
(JSC::CodeBlock::addConstantLazily):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addConstant):
* dfg/DFGDesiredWriteBarriers.cpp:
(JSC::DFG::DesiredWriteBarrier::DesiredWriteBarrier):
(JSC::DFG::DesiredWriteBarrier::trigger):
(JSC::DFG::initializeLazyWriteBarrierForConstant):
* dfg/DFGDesiredWriteBarriers.h:
(JSC::DFG::DesiredWriteBarriers::add):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::truncateConstantToInt32):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::constantRegisterForConstant):
2013-08-16 Filip Pizlo
DFG should optimize typedArray.byteLength
https://bugs.webkit.org/show_bug.cgi?id=119909
Reviewed by Oliver Hunt.
This adds typedArray.byteLength inlining to the DFG, and does so without changing
the IR: byteLength is turned into GetArrayLength followed by BitLShift. This is
legal since the byteLength of a typed array cannot exceed
numeric_limits::max().
* bytecode/SpeculatedType.cpp:
(JSC::typedArrayTypeFromSpeculation):
* bytecode/SpeculatedType.h:
* dfg/DFGArrayMode.cpp:
(JSC::DFG::toArrayType):
* dfg/DFGArrayMode.h:
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
(JSC::DFG::FixupPhase::attemptToMakeGetByteLength):
(JSC::DFG::FixupPhase::convertToGetArrayLength):
(JSC::DFG::FixupPhase::prependGetArrayLength):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::constantRegisterForConstant):
(JSC::DFG::Graph::convertToConstant):
* runtime/TypedArrayType.h:
(JSC::logElementSize):
(JSC::elementSize):
2013-08-16 Filip Pizlo
DFG optimizes out strict mode arguments tear off
https://bugs.webkit.org/show_bug.cgi?id=119504
Reviewed by Mark Hahnenberg and Oliver Hunt.
Don't do the optimization for strict mode.
* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
(JSC::DFG::ArgumentsSimplificationPhase::pruneObviousArgumentCreations):
2013-08-16 Benjamin Poulain
[JSC] x86: improve code generation for xxxTest32
https://bugs.webkit.org/show_bug.cgi?id=119876
Reviewed by Geoffrey Garen.
Try to use testb whenever possible when testing for an immediate value.
When the input is an address and an offset, we can tweak the mask
and offset to be able to generate testb for any byte of the mask.
When the input is a register, we can use testb if we are only interested
in testing the low bits.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branchTest32):
(JSC::MacroAssemblerX86Common::test32):
(JSC::MacroAssemblerX86Common::generateTest32):
2013-08-16 Mark Lam Baseline JIT gives erroneous
error message that an object is not a constructor though it expects a function
Reviewed by Michael Saboff.
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
2013-08-16 Filip Pizlo
Object properties added using dot syntax (o.f = ...) from code that isn't in eval should be less likely to cause an object to become a dictionary
https://bugs.webkit.org/show_bug.cgi?id=119897
Reviewed by Oliver Hunt.
6-10x speed-up on microbenchmarks that create large static objects. 40-65% speed-up
on Octane/gbemu. 3% overall speed-up on Octane. No slow-downs anywhere; our ability
to turn objects into dictionaries when you're storing using bracket syntax or using
eval is still in place.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::putByIdContext):
* dfg/DFGOperations.cpp:
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/JSObject.h:
(JSC::JSObject::putDirectInternal):
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
(JSC::PutPropertySlot::context):
* runtime/Structure.cpp:
(JSC::Structure::addPropertyTransition):
* runtime/Structure.h:
2013-08-16 Balazs Kilvady REGRESSION(FTL): Fix register usage in mips implementation of ctiVMHandleException
Reviewed by Allan Sandfeld Jensen.
ctiVMHandleException must jump/return using register ra (r31).
* jit/JITStubsMIPS.h:
2013-08-16 Julien Brianceau Fix sh4 build after r154156.
Reviewed by Allan Sandfeld Jensen.
Fix typo in JITStubsSH4.h file.
* jit/JITStubsSH4.h:
2013-08-15 Mark Hahnenberg Concurrent compilation thread should not trigger WriteBarriers
Reviewed by Oliver Hunt.
The concurrent compilation thread should interact minimally with the Heap, including not
triggering WriteBarriers. This is a prerequisite for generational GC.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::addOrFindConstant):
(JSC::CodeBlock::findConstant):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addConstantLazily):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getJSConstantForValue):
(JSC::DFG::ByteCodeParser::constantUndefined):
(JSC::DFG::ByteCodeParser::constantNull):
(JSC::DFG::ByteCodeParser::one):
(JSC::DFG::ByteCodeParser::constantNaN):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::notifyCompilingStructureTransition):
* dfg/DFGCommonData.h:
* dfg/DFGDesiredTransitions.cpp: Added.
(JSC::DFG::DesiredTransition::DesiredTransition):
(JSC::DFG::DesiredTransition::reallyAdd):
(JSC::DFG::DesiredTransitions::DesiredTransitions):
(JSC::DFG::DesiredTransitions::~DesiredTransitions):
(JSC::DFG::DesiredTransitions::addLazily):
(JSC::DFG::DesiredTransitions::reallyAdd):
* dfg/DFGDesiredTransitions.h: Added.
* dfg/DFGDesiredWeakReferences.cpp: Added.
(JSC::DFG::DesiredWeakReferences::DesiredWeakReferences):
(JSC::DFG::DesiredWeakReferences::~DesiredWeakReferences):
(JSC::DFG::DesiredWeakReferences::addLazily):
(JSC::DFG::DesiredWeakReferences::reallyAdd):
* dfg/DFGDesiredWeakReferences.h: Added.
* dfg/DFGDesiredWriteBarriers.cpp: Added.
(JSC::DFG::DesiredWriteBarrier::DesiredWriteBarrier):
(JSC::DFG::DesiredWriteBarrier::trigger):
(JSC::DFG::DesiredWriteBarriers::DesiredWriteBarriers):
(JSC::DFG::DesiredWriteBarriers::~DesiredWriteBarriers):
(JSC::DFG::DesiredWriteBarriers::addImpl):
(JSC::DFG::DesiredWriteBarriers::trigger):
* dfg/DFGDesiredWriteBarriers.h: Added.
(JSC::DFG::DesiredWriteBarriers::add):
(JSC::DFG::initializeLazyWriteBarrier):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::truncateConstantToInt32):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::convertToConstant):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addWeakReference):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::reallyAdd):
* dfg/DFGPlan.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* runtime/WriteBarrier.h:
(JSC::WriteBarrierBase::set):
(JSC::WriteBarrier::WriteBarrier):
2013-08-15 Benjamin Poulain
Fix x86 32bits build after r154158
* assembler/X86Assembler.h: Add missing #ifdef for the x86_64 instructions.
2013-08-15 Ryosuke Niwa
Build fix attempt after r154156.
* jit/JITStubs.cpp:
(JSC::cti_vm_handle_exception): encode!
2013-08-15 Benjamin Poulain
[JSC] x86: Use inc and dec when possible
https://bugs.webkit.org/show_bug.cgi?id=119831
Reviewed by Geoffrey Garen.
When incrementing or decrementing by an immediate of 1, use the insctructions
inc and dec instead of add and sub.
The instructions have good timing and their encoding is smaller.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86_64::add32):
(JSC::MacroAssemblerX86_64::sub32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::add64):
(JSC::MacroAssemblerX86_64::sub64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::dec_r):
(JSC::X86Assembler::decq_r):
(JSC::X86Assembler::inc_r):
(JSC::X86Assembler::incq_r):
2013-08-15 Filip Pizlo
Sometimes, the DFG uses a GetById for typed array length accesses despite profiling data that indicates that it's a typed array length access
https://bugs.webkit.org/show_bug.cgi?id=119874
Reviewed by Oliver Hunt and Mark Hahnenberg.
It was a confusion between heuristics in DFG::ArrayMode that are assuming that
you'll use ForceExit if array profiles are empty, the JIT creating empty profiles
sometimes for typed array length accesses, and the FixupPhase assuming that a
ForceExit ArrayMode means that it should continue using a generic GetById.
This fixes the confusion.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2013-08-15 Mark Lam
Fix crash when performing activation tearoff.
https://bugs.webkit.org/show_bug.cgi?id=119848
Reviewed by Oliver Hunt.
The activation tearoff crash was due to a bug in the baseline JIT.
If we have a scenario where the a baseline JIT frame calls a LLINT
frame, an exception may be thrown while in the LLINT.
Interpreter::throwException() which handles the exception will unwind
all frames until it finds a catcher or sees a host frame. When we
return from the LLINT to the baseline JIT code, the baseline JIT code
errorneously sets topCallFrame to the value in its call frame register,
and starts unwinding the stack frames that have already been unwound.
The fix is:
1. Rename ctiVMThrowTrampolineSlowpath to ctiVMHandleException.
This is a more accurate description of what this runtime function
is supposed to do i.e. it handles the exception which include doing
nothing (if there are no more frames to unwind).
2. Fix up topCallFrame values so that the HostCallFrameFlag is never
set on it.
3. Reloading the call frame register from topCallFrame when we're
returning from a callee and detect exception handling in progress.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::unwindCallFrame):
- Ensure that topCallFrame is not set with the HostCallFrameFlag.
(JSC::Interpreter::getStackTrace):
* interpreter/Interpreter.h:
(JSC::TopCallFrameSetter::TopCallFrameSetter):
(JSC::TopCallFrameSetter::~TopCallFrameSetter):
(JSC::NativeCallFrameTracer::NativeCallFrameTracer):
- Ensure that topCallFrame is not set with the HostCallFrameFlag.
* jit/JIT.h:
* jit/JITExceptions.cpp:
(JSC::uncaughtExceptionHandler):
- Convenience function to get the handler for uncaught exceptions.
* jit/JITExceptions.h:
* jit/JITInlines.h:
(JSC::JIT::reloadCallFrameFromTopCallFrame):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileCTINativeCall):
- Rename ctiVMThrowTrampolineSlowpath to ctiVMHandleException.
* jit/JITStubs.cpp:
(JSC::throwExceptionFromOpCall):
- Ensure that topCallFrame is not set with the HostCallFrameFlag.
(JSC::cti_vm_handle_exception):
- Check for the case when there are no more frames to unwind.
* jit/JITStubs.h:
* jit/JITStubsARM.h:
* jit/JITStubsARMv7.h:
* jit/JITStubsMIPS.h:
* jit/JITStubsSH4.h:
* jit/JITStubsX86.h:
* jit/JITStubsX86_64.h:
- Rename ctiVMThrowTrampolineSlowpath to ctiVMHandleException.
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::call):
- reload cfr from topcallFrame when handling an exception.
- Rename ctiVMThrowTrampolineSlowpath to ctiVMHandleException.
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
- reload cfr from topcallFrame when handling an exception.
* runtime/VM.cpp:
(JSC::VM::VM):
- Ensure that topCallFrame is not set with the HostCallFrameFlag.
2013-08-15 Filip Pizlo
Remove some code duplication.
Rubber stamped by Mark Hahnenberg.
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::setData):
2013-08-15 Julien Brianceau
[DFG] isDouble() and isNumerical() should return true with KnownNumberUse UseKind.
https://bugs.webkit.org/show_bug.cgi?id=119794
Reviewed by Filip Pizlo.
This patch fixes ASSERTs failures in debug builds for sh4 and mips architecture.
* dfg/DFGUseKind.h:
(JSC::DFG::isNumerical):
(JSC::DFG::isDouble):
2013-08-15 Filip Pizlo
http://trac.webkit.org/changeset/154120 accidentally changed DFGCapabilities to read the resolve type from operand 4, not 3; it should be 3.
Rubber stamped by Oliver Hunt.
This was causing some test crashes for me.
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
2013-08-15 Brent Fulgham
[Windows] Clear up improper export declaration.
* runtime/ArrayBufferView.h:
2013-08-15 Filip Pizlo
Unreviewed, remove some unnecessary periods from exceptions.
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::setData):
2013-08-15 Filip Pizlo
Unreviewed, fix 32-bit build.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2013-08-14 Filip Pizlo
Typed arrays should be rewritten
https://bugs.webkit.org/show_bug.cgi?id=119064
Reviewed by Oliver Hunt.
Typed arrays were previously deficient in several major ways:
- They were defined separately in WebCore and in the jsc shell. The two
implementations were different, and the jsc shell one was basically wrong.
The WebCore one was quite awful, also.
- Typed arrays were not visible to the JIT except through some weird hooks.
For example, the JIT could not ask "what is the Structure that this typed
array would have if I just allocated it from this global object". Also,
it was difficult to wire any of the typed array intrinsics, because most
of the functionality wasn't visible anywhere in JSC.
- Typed array allocation was brain-dead. Allocating a typed array involved
two JS objects, two GC weak handles, and three malloc allocations.
- Neutering. It involved keeping tabs on all native views but not the view
wrappers, even though the native views can autoneuter just by asking the
buffer if it was neutered anytime you touch them; while the JS view
wrappers are the ones that you really want to reach out to.
- Common case-ing. Most typed arrays have one buffer and one view, and
usually nobody touches the buffer. Yet we created all of that stuff
anyway, using data structures optimized for the case where you had a lot
of views.
- Semantic goofs. Typed arrays should, in the future, behave like ES
features rather than DOM features, for example when it comes to exceptions.
Firefox already does this and I agree with them.
This patch cleanses our codebase of these sins:
- Typed arrays are almost entirely defined in JSC. Only the lifecycle
management of native references to buffers is left to WebCore.
- Allocating a typed array requires either two GC allocations (a cell and a
copied storage vector) or one GC allocation, a malloc allocation, and a
weak handle (a cell and a malloc'd storage vector, plus a finalizer for the
latter). The latter is only used for oversize arrays. Remember that before
it was 7 allocations no matter what.
- Typed arrays require just 4 words of overhead: Structure*, Butterfly*,
mode/length, void* vector. Before it was a lot more than that - remember,
there were five additional objects that did absolutely nothing for anybody.
- Native views aren't tracked by the buffer, or by the wrappers. They are
transient. In the future we'll probably switch to not even having them be
malloc'd.
- Native array buffers have an efficient way of tracking all of their JS view
wrappers, both for neutering, and for lifecycle management. The GC
special-cases native array buffers. This saves a bunch of grief; for example
it means that a JS view wrapper can refer to its buffer via the butterfly,
which would be dead by the time we went to finalize.
- Typed array semantics now match Firefox, which also happens to be where the
standards are going. The discussion on webkit-dev seemed to confirm that
Chrome is also heading in this direction. This includes making
Uint8ClampedArray not a subtype of Uint8Array, and getting rid of
ArrayBufferView as a JS-visible construct.
This is up to a 10x speed-up on programs that allocate a lot of typed arrays.
It's a 1% speed-up on Octane. It also opens up a bunch of possibilities for
further typed array optimizations in the JSC JITs, including inlining typed
array allocation, inlining more of the accessors, reducing the cost of type
checks, etc.
An additional property of this patch is that typed arrays are mostly
implemented using templates. This deduplicates a bunch of code, but does mean
that we need some hacks for exporting s_info's of template classes. See
JSGenericTypedArrayView.h and JSTypedArrays.cpp. Those hacks are fairly
low-impact compared to code duplication.
Automake work courtesy of Zan Dobersek .
* CMakeLists.txt:
* DerivedSources.make:
* GNUmakefile.list.am:
* JSCTypedArrayStubs.h: Removed.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* bytecode/ByValInfo.h:
(JSC::hasOptimizableIndexingForClassInfo):
(JSC::jitArrayModeForClassInfo):
(JSC::typedArrayTypeForJITArrayMode):
* bytecode/SpeculatedType.cpp:
(JSC::speculationFromClassInfo):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::toTypedArrayType):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::typedArrayType):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArray):
(JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
(JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
(JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* heap/CopyToken.h:
* heap/DeferGC.h:
(JSC::DeferGCForAWhile::DeferGCForAWhile):
(JSC::DeferGCForAWhile::~DeferGCForAWhile):
* heap/GCIncomingRefCounted.h: Added.
(JSC::GCIncomingRefCounted::GCIncomingRefCounted):
(JSC::GCIncomingRefCounted::~GCIncomingRefCounted):
(JSC::GCIncomingRefCounted::numberOfIncomingReferences):
(JSC::GCIncomingRefCounted::incomingReferenceAt):
(JSC::GCIncomingRefCounted::singletonFlag):
(JSC::GCIncomingRefCounted::hasVectorOfCells):
(JSC::GCIncomingRefCounted::hasAnyIncoming):
(JSC::GCIncomingRefCounted::hasSingleton):
(JSC::GCIncomingRefCounted::singleton):
(JSC::GCIncomingRefCounted::vectorOfCells):
* heap/GCIncomingRefCountedInlines.h: Added.
(JSC::::addIncomingReference):
(JSC::::filterIncomingReferences):
* heap/GCIncomingRefCountedSet.h: Added.
(JSC::GCIncomingRefCountedSet::size):
* heap/GCIncomingRefCountedSetInlines.h: Added.
(JSC::::GCIncomingRefCountedSet):
(JSC::::~GCIncomingRefCountedSet):
(JSC::::addReference):
(JSC::::sweep):
(JSC::::removeAll):
(JSC::::removeDead):
* heap/Heap.cpp:
(JSC::Heap::addReference):
(JSC::Heap::extraSize):
(JSC::Heap::size):
(JSC::Heap::capacity):
(JSC::Heap::collect):
(JSC::Heap::decrementDeferralDepth):
(JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
* heap/Heap.h:
* interpreter/CallFrame.h:
(JSC::ExecState::dataViewTable):
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* jsc.cpp:
(GlobalObject::finishCreation):
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::transfer):
* runtime/ArrayBuffer.h:
(JSC::ArrayBuffer::createAdopted):
(JSC::ArrayBuffer::ArrayBuffer):
(JSC::ArrayBuffer::gcSizeEstimateInBytes):
(JSC::ArrayBuffer::pin):
(JSC::ArrayBuffer::unpin):
(JSC::ArrayBufferContents::tryAllocate):
* runtime/ArrayBufferView.cpp:
(JSC::ArrayBufferView::ArrayBufferView):
(JSC::ArrayBufferView::~ArrayBufferView):
(JSC::ArrayBufferView::setNeuterable):
* runtime/ArrayBufferView.h:
(JSC::ArrayBufferView::isNeutered):
(JSC::ArrayBufferView::buffer):
(JSC::ArrayBufferView::baseAddress):
(JSC::ArrayBufferView::byteOffset):
(JSC::ArrayBufferView::verifySubRange):
(JSC::ArrayBufferView::clampOffsetAndNumElements):
(JSC::ArrayBufferView::calculateOffsetAndLength):
* runtime/ClassInfo.h:
* runtime/CommonIdentifiers.h:
* runtime/DataView.cpp: Added.
(JSC::DataView::DataView):
(JSC::DataView::create):
(JSC::DataView::wrap):
* runtime/DataView.h: Added.
(JSC::DataView::byteLength):
(JSC::DataView::getType):
(JSC::DataView::get):
(JSC::DataView::set):
* runtime/Float32Array.h:
* runtime/Float64Array.h:
* runtime/GenericTypedArrayView.h: Added.
(JSC::GenericTypedArrayView::data):
(JSC::GenericTypedArrayView::set):
(JSC::GenericTypedArrayView::setRange):
(JSC::GenericTypedArrayView::zeroRange):
(JSC::GenericTypedArrayView::zeroFill):
(JSC::GenericTypedArrayView::length):
(JSC::GenericTypedArrayView::byteLength):
(JSC::GenericTypedArrayView::item):
(JSC::GenericTypedArrayView::checkInboundData):
(JSC::GenericTypedArrayView::getType):
* runtime/GenericTypedArrayViewInlines.h: Added.
(JSC::::GenericTypedArrayView):
(JSC::::create):
(JSC::::createUninitialized):
(JSC::::subarray):
(JSC::::wrap):
* runtime/IndexingHeader.h:
(JSC::IndexingHeader::arrayBuffer):
(JSC::IndexingHeader::setArrayBuffer):
* runtime/Int16Array.h:
* runtime/Int32Array.h:
* runtime/Int8Array.h:
* runtime/JSArrayBuffer.cpp: Added.
(JSC::JSArrayBuffer::JSArrayBuffer):
(JSC::JSArrayBuffer::finishCreation):
(JSC::JSArrayBuffer::create):
(JSC::JSArrayBuffer::createStructure):
(JSC::JSArrayBuffer::getOwnPropertySlot):
(JSC::JSArrayBuffer::getOwnPropertyDescriptor):
(JSC::JSArrayBuffer::put):
(JSC::JSArrayBuffer::defineOwnProperty):
(JSC::JSArrayBuffer::deleteProperty):
(JSC::JSArrayBuffer::getOwnNonIndexPropertyNames):
* runtime/JSArrayBuffer.h: Added.
(JSC::JSArrayBuffer::impl):
(JSC::toArrayBuffer):
* runtime/JSArrayBufferConstructor.cpp: Added.
(JSC::JSArrayBufferConstructor::JSArrayBufferConstructor):
(JSC::JSArrayBufferConstructor::finishCreation):
(JSC::JSArrayBufferConstructor::create):
(JSC::JSArrayBufferConstructor::createStructure):
(JSC::constructArrayBuffer):
(JSC::JSArrayBufferConstructor::getConstructData):
(JSC::JSArrayBufferConstructor::getCallData):
* runtime/JSArrayBufferConstructor.h: Added.
* runtime/JSArrayBufferPrototype.cpp: Added.
(JSC::arrayBufferProtoFuncSlice):
(JSC::JSArrayBufferPrototype::JSArrayBufferPrototype):
(JSC::JSArrayBufferPrototype::finishCreation):
(JSC::JSArrayBufferPrototype::create):
(JSC::JSArrayBufferPrototype::createStructure):
* runtime/JSArrayBufferPrototype.h: Added.
* runtime/JSArrayBufferView.cpp: Added.
(JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
(JSC::JSArrayBufferView::JSArrayBufferView):
(JSC::JSArrayBufferView::finishCreation):
(JSC::JSArrayBufferView::getOwnPropertySlot):
(JSC::JSArrayBufferView::getOwnPropertyDescriptor):
(JSC::JSArrayBufferView::put):
(JSC::JSArrayBufferView::defineOwnProperty):
(JSC::JSArrayBufferView::deleteProperty):
(JSC::JSArrayBufferView::getOwnNonIndexPropertyNames):
(JSC::JSArrayBufferView::finalize):
* runtime/JSArrayBufferView.h: Added.
(JSC::JSArrayBufferView::sizeOf):
(JSC::JSArrayBufferView::ConstructionContext::operator!):
(JSC::JSArrayBufferView::ConstructionContext::structure):
(JSC::JSArrayBufferView::ConstructionContext::vector):
(JSC::JSArrayBufferView::ConstructionContext::length):
(JSC::JSArrayBufferView::ConstructionContext::mode):
(JSC::JSArrayBufferView::ConstructionContext::butterfly):
(JSC::JSArrayBufferView::mode):
(JSC::JSArrayBufferView::vector):
(JSC::JSArrayBufferView::length):
(JSC::JSArrayBufferView::offsetOfVector):
(JSC::JSArrayBufferView::offsetOfLength):
(JSC::JSArrayBufferView::offsetOfMode):
* runtime/JSArrayBufferViewInlines.h: Added.
(JSC::JSArrayBufferView::slowDownAndWasteMemoryIfNecessary):
(JSC::JSArrayBufferView::buffer):
(JSC::JSArrayBufferView::impl):
(JSC::JSArrayBufferView::neuter):
(JSC::JSArrayBufferView::byteOffset):
* runtime/JSCell.cpp:
(JSC::JSCell::slowDownAndWasteMemory):
(JSC::JSCell::getTypedArrayImpl):
* runtime/JSCell.h:
* runtime/JSDataView.cpp: Added.
(JSC::JSDataView::JSDataView):
(JSC::JSDataView::create):
(JSC::JSDataView::createUninitialized):
(JSC::JSDataView::set):
(JSC::JSDataView::typedImpl):
(JSC::JSDataView::getOwnPropertySlot):
(JSC::JSDataView::getOwnPropertyDescriptor):
(JSC::JSDataView::slowDownAndWasteMemory):
(JSC::JSDataView::getTypedArrayImpl):
(JSC::JSDataView::createStructure):
* runtime/JSDataView.h: Added.
* runtime/JSDataViewPrototype.cpp: Added.
(JSC::JSDataViewPrototype::JSDataViewPrototype):
(JSC::JSDataViewPrototype::create):
(JSC::JSDataViewPrototype::createStructure):
(JSC::JSDataViewPrototype::getOwnPropertySlot):
(JSC::JSDataViewPrototype::getOwnPropertyDescriptor):
(JSC::getData):
(JSC::setData):
(JSC::dataViewProtoFuncGetInt8):
(JSC::dataViewProtoFuncGetInt16):
(JSC::dataViewProtoFuncGetInt32):
(JSC::dataViewProtoFuncGetUint8):
(JSC::dataViewProtoFuncGetUint16):
(JSC::dataViewProtoFuncGetUint32):
(JSC::dataViewProtoFuncGetFloat32):
(JSC::dataViewProtoFuncGetFloat64):
(JSC::dataViewProtoFuncSetInt8):
(JSC::dataViewProtoFuncSetInt16):
(JSC::dataViewProtoFuncSetInt32):
(JSC::dataViewProtoFuncSetUint8):
(JSC::dataViewProtoFuncSetUint16):
(JSC::dataViewProtoFuncSetUint32):
(JSC::dataViewProtoFuncSetFloat32):
(JSC::dataViewProtoFuncSetFloat64):
* runtime/JSDataViewPrototype.h: Added.
* runtime/JSFloat32Array.h: Added.
* runtime/JSFloat64Array.h: Added.
* runtime/JSGenericTypedArrayView.h: Added.
(JSC::JSGenericTypedArrayView::byteLength):
(JSC::JSGenericTypedArrayView::byteSize):
(JSC::JSGenericTypedArrayView::typedVector):
(JSC::JSGenericTypedArrayView::canGetIndexQuickly):
(JSC::JSGenericTypedArrayView::canSetIndexQuickly):
(JSC::JSGenericTypedArrayView::getIndexQuicklyAsNativeValue):
(JSC::JSGenericTypedArrayView::getIndexQuicklyAsDouble):
(JSC::JSGenericTypedArrayView::getIndexQuickly):
(JSC::JSGenericTypedArrayView::setIndexQuicklyToNativeValue):
(JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
(JSC::JSGenericTypedArrayView::setIndexQuickly):
(JSC::JSGenericTypedArrayView::canAccessRangeQuickly):
(JSC::JSGenericTypedArrayView::typedImpl):
(JSC::JSGenericTypedArrayView::createStructure):
(JSC::JSGenericTypedArrayView::info):
(JSC::toNativeTypedView):
* runtime/JSGenericTypedArrayViewConstructor.h: Added.
* runtime/JSGenericTypedArrayViewConstructorInlines.h: Added.
(JSC::::JSGenericTypedArrayViewConstructor):
(JSC::::finishCreation):
(JSC::::create):
(JSC::::createStructure):
(JSC::constructGenericTypedArrayView):
(JSC::::getConstructData):
(JSC::::getCallData):
* runtime/JSGenericTypedArrayViewInlines.h: Added.
(JSC::::JSGenericTypedArrayView):
(JSC::::create):
(JSC::::createUninitialized):
(JSC::::validateRange):
(JSC::::setWithSpecificType):
(JSC::::set):
(JSC::::getOwnPropertySlot):
(JSC::::getOwnPropertyDescriptor):
(JSC::::put):
(JSC::::defineOwnProperty):
(JSC::::deleteProperty):
(JSC::::getOwnPropertySlotByIndex):
(JSC::::putByIndex):
(JSC::::deletePropertyByIndex):
(JSC::::getOwnNonIndexPropertyNames):
(JSC::::getOwnPropertyNames):
(JSC::::visitChildren):
(JSC::::copyBackingStore):
(JSC::::slowDownAndWasteMemory):
(JSC::::getTypedArrayImpl):
* runtime/JSGenericTypedArrayViewPrototype.h: Added.
* runtime/JSGenericTypedArrayViewPrototypeInlines.h: Added.
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncSubarray):
(JSC::::JSGenericTypedArrayViewPrototype):
(JSC::::finishCreation):
(JSC::::create):
(JSC::::createStructure):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::reset):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrayBufferPrototype):
(JSC::JSGlobalObject::arrayBufferStructure):
(JSC::JSGlobalObject::typedArrayStructure):
* runtime/JSInt16Array.h: Added.
* runtime/JSInt32Array.h: Added.
* runtime/JSInt8Array.h: Added.
* runtime/JSTypedArrayConstructors.cpp: Added.
* runtime/JSTypedArrayConstructors.h: Added.
* runtime/JSTypedArrayPrototypes.cpp: Added.
* runtime/JSTypedArrayPrototypes.h: Added.
* runtime/JSTypedArrays.cpp: Added.
* runtime/JSTypedArrays.h: Added.
* runtime/JSUint16Array.h: Added.
* runtime/JSUint32Array.h: Added.
* runtime/JSUint8Array.h: Added.
* runtime/JSUint8ClampedArray.h: Added.
* runtime/Operations.h:
* runtime/Options.h:
* runtime/SimpleTypedArrayController.cpp: Added.
(JSC::SimpleTypedArrayController::SimpleTypedArrayController):
(JSC::SimpleTypedArrayController::~SimpleTypedArrayController):
(JSC::SimpleTypedArrayController::toJS):
* runtime/SimpleTypedArrayController.h: Added.
* runtime/Structure.h:
(JSC::Structure::couldHaveIndexingHeader):
* runtime/StructureInlines.h:
(JSC::Structure::hasIndexingHeader):
* runtime/TypedArrayAdaptors.h: Added.
(JSC::IntegralTypedArrayAdaptor::toNative):
(JSC::IntegralTypedArrayAdaptor::toJSValue):
(JSC::IntegralTypedArrayAdaptor::toDouble):
(JSC::FloatTypedArrayAdaptor::toNative):
(JSC::FloatTypedArrayAdaptor::toJSValue):
(JSC::FloatTypedArrayAdaptor::toDouble):
(JSC::Uint8ClampedAdaptor::toNative):
(JSC::Uint8ClampedAdaptor::toJSValue):
(JSC::Uint8ClampedAdaptor::toDouble):
(JSC::Uint8ClampedAdaptor::clamp):
* runtime/TypedArrayController.cpp: Added.
(JSC::TypedArrayController::TypedArrayController):
(JSC::TypedArrayController::~TypedArrayController):
* runtime/TypedArrayController.h: Added.
* runtime/TypedArrayDescriptor.h: Removed.
* runtime/TypedArrayInlines.h: Added.
* runtime/TypedArrayType.cpp: Added.
(JSC::classInfoForType):
(WTF::printInternal):
* runtime/TypedArrayType.h: Added.
(JSC::toIndex):
(JSC::isTypedView):
(JSC::elementSize):
(JSC::isInt):
(JSC::isFloat):
(JSC::isSigned):
(JSC::isClamped):
* runtime/TypedArrays.h: Added.
* runtime/Uint16Array.h:
* runtime/Uint32Array.h:
* runtime/Uint8Array.h:
* runtime/Uint8ClampedArray.h:
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
* runtime/VM.h:
2013-08-15 Oliver Hunt Assigning to a readonly global results in DFG byte code parse failure
Reviewed by Filip Pizlo.
Make sure dfgCapabilities doesn't report a Dynamic put as
being compilable when we don't actually support it.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
2013-08-15 Brent Fulgham
[Windows] Incorrect DLL Linkage for JSC ArrayBuffer and ArrayBufferView
https://bugs.webkit.org/show_bug.cgi?id=119847
Reviewed by Oliver Hunt.
* runtime/ArrayBuffer.h: Switch from WTF_EXPORT_PRIVATE to JS_EXPORT_PRIVATE
* runtime/ArrayBufferView.h: Ditto.
2013-08-15 Gavin Barraclough
https://bugs.webkit.org/show_bug.cgi?id=119843
PropertySlot::setValue is ambiguous
Reviewed by Geoff Garen.
There are three different versions of PropertySlot::setValue, one for cacheable properties, and two that are used interchangeably and inconsistently.
The problematic variants are the ones that just take a value, and one that takes a value and also the object containing the property.
Unify on always providing the object, and remove the version that just takes a value.
This always works except for JSString, where we optimize out the object (logically we should be instantiating a temporary StringObject on every property access).
Provide a version of setValue that takes a JSString as the owner of the property.
We won't store this, but it makes it clear that this interface should only be used from JSString.
* API/JSCallbackObjectFunctions.h:
(JSC::::getOwnPropertySlot):
* JSCTypedArrayStubs.h:
* runtime/Arguments.cpp:
(JSC::Arguments::getOwnPropertySlotByIndex):
(JSC::Arguments::getOwnPropertySlot):
* runtime/JSActivation.cpp:
(JSC::JSActivation::symbolTableGet):
(JSC::JSActivation::getOwnPropertySlot):
* runtime/JSArray.cpp:
(JSC::JSArray::getOwnPropertySlot):
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertySlotByIndex):
* runtime/JSString.h:
(JSC::JSString::getStringPropertySlot):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayEntry::get):
- Pass object containing property to PropertySlot::setValue
* runtime/PropertySlot.h:
(JSC::PropertySlot::setValue):
- Logically, the base of a string property access is a temporary StringObject, but we optimize that away.
(JSC::PropertySlot::setUndefined):
- removed setValue(JSValue), added setValue(JSString*, JSValue)
2013-08-15 Oliver Hunt
Remove bogus assertion.
RS=Filip Pizlo
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
2013-08-15 Allan Sandfeld Jensen
REGRESSION(r148790) Made 7 tests fail on x86 32bit
https://bugs.webkit.org/show_bug.cgi?id=114913
Reviewed by Filip Pizlo.
The X87 register was not freed before some calls. Instead
of inserting resetX87Registers to the last call sites,
the two X87 registers are now freed in every call.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/instructions.rb:
* offlineasm/x86.rb:
2013-08-14 Michael Saboff
Fixed jit on Win64.
https://bugs.webkit.org/show_bug.cgi?id=119601
Reviewed by Oliver Hunt.
* jit/JITStubsMSVC64.asm: Added ctiVMThrowTrampolineSlowpath implementation.
* jit/JSInterfaceJIT.h: Added thirdArgumentRegister.
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::call): Added correct calling convention for Win64.
2013-08-14 Alex Christensen
Compile fix for Win64 with jit disabled.
https://bugs.webkit.org/show_bug.cgi?id=119804
Reviewed by Michael Saboff.
* offlineasm/cloop.rb: Added std:: before isnan.
2013-08-14 Julien Brianceau
DFG_JIT implementation for sh4 architecture.
https://bugs.webkit.org/show_bug.cgi?id=119737
Reviewed by Oliver Hunt.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::invert):
(JSC::MacroAssemblerSH4::add32):
(JSC::MacroAssemblerSH4::and32):
(JSC::MacroAssemblerSH4::lshift32):
(JSC::MacroAssemblerSH4::mul32):
(JSC::MacroAssemblerSH4::or32):
(JSC::MacroAssemblerSH4::rshift32):
(JSC::MacroAssemblerSH4::sub32):
(JSC::MacroAssemblerSH4::xor32):
(JSC::MacroAssemblerSH4::store32):
(JSC::MacroAssemblerSH4::swapDouble):
(JSC::MacroAssemblerSH4::storeDouble):
(JSC::MacroAssemblerSH4::subDouble):
(JSC::MacroAssemblerSH4::mulDouble):
(JSC::MacroAssemblerSH4::divDouble):
(JSC::MacroAssemblerSH4::negateDouble):
(JSC::MacroAssemblerSH4::zeroExtend32ToPtr):
(JSC::MacroAssemblerSH4::branchTruncateDoubleToUint32):
(JSC::MacroAssemblerSH4::truncateDoubleToUint32):
(JSC::MacroAssemblerSH4::swap):
(JSC::MacroAssemblerSH4::jump):
(JSC::MacroAssemblerSH4::branchNeg32):
(JSC::MacroAssemblerSH4::branchAdd32):
(JSC::MacroAssemblerSH4::branchMul32):
(JSC::MacroAssemblerSH4::urshift32):
* assembler/SH4Assembler.h:
(JSC::SH4Assembler::SH4Assembler):
(JSC::SH4Assembler::labelForWatchpoint):
(JSC::SH4Assembler::label):
(JSC::SH4Assembler::debugOffset):
* dfg/DFGAssemblyHelpers.h:
(JSC::DFG::AssemblyHelpers::preserveReturnAddressAfterCall):
(JSC::DFG::AssemblyHelpers::restoreReturnAddressBeforeReturn):
(JSC::DFG::AssemblyHelpers::debugCall):
* dfg/DFGCCallHelpers.h:
(JSC::DFG::CCallHelpers::setupArguments):
(JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
* dfg/DFGFPRInfo.h:
(JSC::DFG::FPRInfo::toRegister):
(JSC::DFG::FPRInfo::toIndex):
(JSC::DFG::FPRInfo::debugName):
* dfg/DFGGPRInfo.h:
(JSC::DFG::GPRInfo::toRegister):
(JSC::DFG::GPRInfo::toIndex):
(JSC::DFG::GPRInfo::debugName):
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* jit/JITStubs.h:
* jit/JITStubsSH4.h:
2013-08-13 Filip Pizlo
Unreviewed, fix build.
* API/JSValue.mm:
(isDate):
(isArray):
* API/JSWrapperMap.mm:
(tryUnwrapObjcObject):
* API/ObjCCallbackFunction.mm:
(tryUnwrapBlock):
2013-08-13 Filip Pizlo
Foo::s_info should be Foo::info(), so that you can change how the s_info is actually linked
https://bugs.webkit.org/show_bug.cgi?id=119770
Reviewed by Mark Hahnenberg.
* API/JSCallbackConstructor.cpp:
(JSC::JSCallbackConstructor::finishCreation):
* API/JSCallbackConstructor.h:
(JSC::JSCallbackConstructor::createStructure):
* API/JSCallbackFunction.cpp:
(JSC::JSCallbackFunction::finishCreation):
* API/JSCallbackFunction.h:
(JSC::JSCallbackFunction::createStructure):
* API/JSCallbackObject.cpp:
(JSC::::createStructure):
* API/JSCallbackObject.h:
(JSC::JSCallbackObject::visitChildren):
* API/JSCallbackObjectFunctions.h:
(JSC::::asCallbackObject):
(JSC::::finishCreation):
* API/JSObjectRef.cpp:
(JSObjectGetPrivate):
(JSObjectSetPrivate):
(JSObjectGetPrivateProperty):
(JSObjectSetPrivateProperty):
(JSObjectDeletePrivateProperty):
* API/JSValueRef.cpp:
(JSValueIsObjectOfClass):
* API/JSWeakObjectMapRefPrivate.cpp:
* API/ObjCCallbackFunction.h:
(JSC::ObjCCallbackFunction::createStructure):
* JSCTypedArrayStubs.h:
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::CallLinkStatus):
(JSC::CallLinkStatus::function):
(JSC::CallLinkStatus::internalFunction):
* bytecode/CodeBlock.h:
(JSC::baselineCodeBlockForInlineCallFrame):
* bytecode/SpeculatedType.cpp:
(JSC::speculationFromClassInfo):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::visitChildren):
(JSC::UnlinkedCodeBlock::visitChildren):
(JSC::UnlinkedProgramCodeBlock::visitChildren):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::createStructure):
(JSC::UnlinkedProgramCodeBlock::createStructure):
(JSC::UnlinkedEvalCodeBlock::createStructure):
(JSC::UnlinkedFunctionCodeBlock::createStructure):
* debugger/Debugger.cpp:
* debugger/DebuggerActivation.cpp:
(JSC::DebuggerActivation::visitChildren):
* debugger/DebuggerActivation.h:
(JSC::DebuggerActivation::createStructure):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::functionName):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
(JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::isInternalFunctionConstant):
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArray):
(JSC::DFG::SpeculativeJIT::compileNewStringObject):
* dfg/DFGThunks.cpp:
(JSC::DFG::virtualForThunkGenerator):
* interpreter/Interpreter.cpp:
(JSC::loadVarargs):
* jsc.cpp:
(GlobalObject::createStructure):
* profiler/LegacyProfiler.cpp:
(JSC::LegacyProfiler::createCallIdentifier):
* runtime/Arguments.cpp:
(JSC::Arguments::visitChildren):
* runtime/Arguments.h:
(JSC::Arguments::createStructure):
(JSC::asArguments):
(JSC::Arguments::finishCreation):
* runtime/ArrayConstructor.cpp:
(JSC::arrayConstructorIsArray):
* runtime/ArrayConstructor.h:
(JSC::ArrayConstructor::createStructure):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
(JSC::arrayProtoFuncConcat):
(JSC::attemptFastSort):
* runtime/ArrayPrototype.h:
(JSC::ArrayPrototype::createStructure):
* runtime/BooleanConstructor.h:
(JSC::BooleanConstructor::createStructure):
* runtime/BooleanObject.cpp:
(JSC::BooleanObject::finishCreation):
* runtime/BooleanObject.h:
(JSC::BooleanObject::createStructure):
(JSC::asBooleanObject):
* runtime/BooleanPrototype.cpp:
(JSC::BooleanPrototype::finishCreation):
(JSC::booleanProtoFuncToString):
(JSC::booleanProtoFuncValueOf):
* runtime/BooleanPrototype.h:
(JSC::BooleanPrototype::createStructure):
* runtime/DateConstructor.cpp:
(JSC::constructDate):
* runtime/DateConstructor.h:
(JSC::DateConstructor::createStructure):
* runtime/DateInstance.cpp:
(JSC::DateInstance::finishCreation):
* runtime/DateInstance.h:
(JSC::DateInstance::createStructure):
(JSC::asDateInstance):
* runtime/DatePrototype.cpp:
(JSC::formateDateInstance):
(JSC::DatePrototype::finishCreation):
(JSC::dateProtoFuncToISOString):
(JSC::dateProtoFuncToLocaleString):
(JSC::dateProtoFuncToLocaleDateString):
(JSC::dateProtoFuncToLocaleTimeString):
(JSC::dateProtoFuncGetTime):
(JSC::dateProtoFuncGetFullYear):
(JSC::dateProtoFuncGetUTCFullYear):
(JSC::dateProtoFuncGetMonth):
(JSC::dateProtoFuncGetUTCMonth):
(JSC::dateProtoFuncGetDate):
(JSC::dateProtoFuncGetUTCDate):
(JSC::dateProtoFuncGetDay):
(JSC::dateProtoFuncGetUTCDay):
(JSC::dateProtoFuncGetHours):
(JSC::dateProtoFuncGetUTCHours):
(JSC::dateProtoFuncGetMinutes):
(JSC::dateProtoFuncGetUTCMinutes):
(JSC::dateProtoFuncGetSeconds):
(JSC::dateProtoFuncGetUTCSeconds):
(JSC::dateProtoFuncGetMilliSeconds):
(JSC::dateProtoFuncGetUTCMilliseconds):
(JSC::dateProtoFuncGetTimezoneOffset):
(JSC::dateProtoFuncSetTime):
(JSC::setNewValueFromTimeArgs):
(JSC::setNewValueFromDateArgs):
(JSC::dateProtoFuncSetYear):
(JSC::dateProtoFuncGetYear):
* runtime/DatePrototype.h:
(JSC::DatePrototype::createStructure):
* runtime/Error.h:
(JSC::StrictModeTypeErrorFunction::createStructure):
* runtime/ErrorConstructor.h:
(JSC::ErrorConstructor::createStructure):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::createStructure):
* runtime/ErrorPrototype.cpp:
(JSC::ErrorPrototype::finishCreation):
* runtime/ErrorPrototype.h:
(JSC::ErrorPrototype::createStructure):
* runtime/ExceptionHelpers.cpp:
(JSC::isTerminatedExecutionException):
* runtime/ExceptionHelpers.h:
(JSC::TerminatedExecutionError::createStructure):
* runtime/Executable.cpp:
(JSC::EvalExecutable::visitChildren):
(JSC::ProgramExecutable::visitChildren):
(JSC::FunctionExecutable::visitChildren):
(JSC::ExecutableBase::hashFor):
* runtime/Executable.h:
(JSC::ExecutableBase::createStructure):
(JSC::NativeExecutable::createStructure):
(JSC::EvalExecutable::createStructure):
(JSC::ProgramExecutable::createStructure):
(JSC::FunctionExecutable::compileFor):
(JSC::FunctionExecutable::compileOptimizedFor):
(JSC::FunctionExecutable::createStructure):
* runtime/FunctionConstructor.h:
(JSC::FunctionConstructor::createStructure):
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
(JSC::functionProtoFuncApply):
(JSC::functionProtoFuncBind):
* runtime/FunctionPrototype.h:
(JSC::FunctionPrototype::createStructure):
* runtime/GetterSetter.cpp:
(JSC::GetterSetter::visitChildren):
* runtime/GetterSetter.h:
(JSC::GetterSetter::createStructure):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::finishCreation):
* runtime/InternalFunction.h:
(JSC::InternalFunction::createStructure):
(JSC::asInternalFunction):
* runtime/JSAPIValueWrapper.h:
(JSC::JSAPIValueWrapper::createStructure):
* runtime/JSActivation.cpp:
(JSC::JSActivation::visitChildren):
(JSC::JSActivation::argumentsGetter):
* runtime/JSActivation.h:
(JSC::JSActivation::createStructure):
(JSC::asActivation):
* runtime/JSArray.h:
(JSC::JSArray::createStructure):
(JSC::asArray):
(JSC::isJSArray):
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::finishCreation):
(JSC::JSBoundFunction::visitChildren):
* runtime/JSBoundFunction.h:
(JSC::JSBoundFunction::createStructure):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dumpInContext):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::isFunction):
* runtime/JSCell.h:
(JSC::jsCast):
(JSC::jsDynamicCast):
* runtime/JSCellInlines.h:
(JSC::allocateCell):
* runtime/JSFunction.cpp:
(JSC::JSFunction::finishCreation):
(JSC::JSFunction::visitChildren):
(JSC::skipOverBoundFunctions):
(JSC::JSFunction::callerGetter):
* runtime/JSFunction.h:
(JSC::JSFunction::createStructure):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::visitChildren):
(JSC::slowValidateCell):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::createStructure):
* runtime/JSNameScope.cpp:
(JSC::JSNameScope::visitChildren):
* runtime/JSNameScope.h:
(JSC::JSNameScope::createStructure):
* runtime/JSNotAnObject.h:
(JSC::JSNotAnObject::createStructure):
* runtime/JSONObject.cpp:
(JSC::JSONObject::finishCreation):
(JSC::unwrapBoxedPrimitive):
(JSC::Stringifier::Stringifier):
(JSC::Stringifier::appendStringifiedValue):
(JSC::Stringifier::Holder::Holder):
(JSC::Walker::walk):
(JSC::JSONProtoFuncStringify):
* runtime/JSONObject.h:
(JSC::JSONObject::createStructure):
* runtime/JSObject.cpp:
(JSC::getCallableObjectSlow):
(JSC::JSObject::visitChildren):
(JSC::JSObject::copyBackingStore):
(JSC::JSFinalObject::visitChildren):
(JSC::JSObject::ensureInt32Slow):
(JSC::JSObject::ensureDoubleSlow):
(JSC::JSObject::ensureContiguousSlow):
(JSC::JSObject::ensureArrayStorageSlow):
* runtime/JSObject.h:
(JSC::JSObject::finishCreation):
(JSC::JSObject::createStructure):
(JSC::JSNonFinalObject::createStructure):
(JSC::JSFinalObject::createStructure):
(JSC::isJSFinalObject):
* runtime/JSPropertyNameIterator.cpp:
(JSC::JSPropertyNameIterator::visitChildren):
* runtime/JSPropertyNameIterator.h:
(JSC::JSPropertyNameIterator::createStructure):
* runtime/JSProxy.cpp:
(JSC::JSProxy::visitChildren):
* runtime/JSProxy.h:
(JSC::JSProxy::createStructure):
* runtime/JSScope.cpp:
(JSC::JSScope::visitChildren):
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::visitChildren):
* runtime/JSString.h:
(JSC::JSString::createStructure):
(JSC::isJSString):
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::visitChildren):
* runtime/JSVariableObject.h:
* runtime/JSWithScope.cpp:
(JSC::JSWithScope::visitChildren):
* runtime/JSWithScope.h:
(JSC::JSWithScope::createStructure):
* runtime/JSWrapperObject.cpp:
(JSC::JSWrapperObject::visitChildren):
* runtime/JSWrapperObject.h:
(JSC::JSWrapperObject::createStructure):
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
* runtime/MathObject.h:
(JSC::MathObject::createStructure):
* runtime/NameConstructor.h:
(JSC::NameConstructor::createStructure):
* runtime/NameInstance.h:
(JSC::NameInstance::createStructure):
(JSC::NameInstance::finishCreation):
* runtime/NamePrototype.cpp:
(JSC::NamePrototype::finishCreation):
(JSC::privateNameProtoFuncToString):
* runtime/NamePrototype.h:
(JSC::NamePrototype::createStructure):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor::visitChildren):
* runtime/NativeErrorConstructor.h:
(JSC::NativeErrorConstructor::createStructure):
(JSC::NativeErrorConstructor::finishCreation):
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
* runtime/NumberConstructor.h:
(JSC::NumberConstructor::createStructure):
* runtime/NumberObject.cpp:
(JSC::NumberObject::finishCreation):
* runtime/NumberObject.h:
(JSC::NumberObject::createStructure):
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation):
* runtime/NumberPrototype.h:
(JSC::NumberPrototype::createStructure):
* runtime/ObjectConstructor.h:
(JSC::ObjectConstructor::createStructure):
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
* runtime/ObjectPrototype.h:
(JSC::ObjectPrototype::createStructure):
* runtime/PropertyMapHashTable.h:
(JSC::PropertyTable::createStructure):
* runtime/PropertyTable.cpp:
(JSC::PropertyTable::visitChildren):
* runtime/RegExp.h:
(JSC::RegExp::createStructure):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::finishCreation):
(JSC::RegExpConstructor::visitChildren):
(JSC::constructRegExp):
* runtime/RegExpConstructor.h:
(JSC::RegExpConstructor::createStructure):
(JSC::asRegExpConstructor):
* runtime/RegExpMatchesArray.cpp:
(JSC::RegExpMatchesArray::visitChildren):
* runtime/RegExpMatchesArray.h:
(JSC::RegExpMatchesArray::createStructure):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::finishCreation):
(JSC::RegExpObject::visitChildren):
* runtime/RegExpObject.h:
(JSC::RegExpObject::createStructure):
(JSC::asRegExpObject):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncTest):
(JSC::regExpProtoFuncExec):
(JSC::regExpProtoFuncCompile):
(JSC::regExpProtoFuncToString):
* runtime/RegExpPrototype.h:
(JSC::RegExpPrototype::createStructure):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::createStructure):
* runtime/SparseArrayValueMap.h:
* runtime/StrictEvalActivation.h:
(JSC::StrictEvalActivation::createStructure):
* runtime/StringConstructor.h:
(JSC::StringConstructor::createStructure):
* runtime/StringObject.cpp:
(JSC::StringObject::finishCreation):
* runtime/StringObject.h:
(JSC::StringObject::createStructure):
(JSC::asStringObject):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::stringProtoFuncReplace):
(JSC::stringProtoFuncToString):
(JSC::stringProtoFuncMatch):
(JSC::stringProtoFuncSearch):
(JSC::stringProtoFuncSplit):
* runtime/StringPrototype.h:
(JSC::StringPrototype::createStructure):
* runtime/Structure.cpp:
(JSC::Structure::Structure):
(JSC::Structure::materializePropertyMap):
(JSC::Structure::get):
(JSC::Structure::visitChildren):
* runtime/Structure.h:
(JSC::Structure::typeInfo):
(JSC::Structure::previousID):
(JSC::Structure::outOfLineSize):
(JSC::Structure::totalStorageCapacity):
(JSC::Structure::materializePropertyMapIfNecessary):
(JSC::Structure::materializePropertyMapIfNecessaryForPinning):
* runtime/StructureChain.cpp:
(JSC::StructureChain::visitChildren):
* runtime/StructureChain.h:
(JSC::StructureChain::createStructure):
* runtime/StructureInlines.h:
(JSC::Structure::get):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::createStructure):
(JSC::StructureRareData::visitChildren):
* runtime/StructureRareData.h:
* runtime/SymbolTable.h:
(JSC::SharedSymbolTable::createStructure):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::StackPreservingRecompiler::operator()):
(JSC::VM::releaseExecutableMemory):
* runtime/WriteBarrier.h:
(JSC::validateCell):
* testRegExp.cpp:
(GlobalObject::createStructure):
2013-08-13 Arunprasad Rajkumar
[WTF] [JSC] Replace currentTime() with monotonicallyIncreasingTime() in all possible places
https://bugs.webkit.org/show_bug.cgi?id=119762
Reviewed by Geoffrey Garen.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::markRoots):
(JSC::Heap::collect):
* jsc.cpp:
(StopWatch::start):
(StopWatch::stop):
* testRegExp.cpp:
(StopWatch::start):
(StopWatch::stop):
2013-08-13 Julien Brianceau
[sh4] Prepare LLINT for DFG_JIT implementation.
https://bugs.webkit.org/show_bug.cgi?id=119755
Reviewed by Oliver Hunt.
* LLIntOffsetsExtractor.pro: Add sh4.rb dependency.
* offlineasm/sh4.rb:
- Handle storeb opcode.
- Make relative jumps when possible using braf opcode.
- Update bmulio implementation to be consistent with baseline JIT.
- Remove useless code from leap opcode.
- Fix incorrect comment.
2013-08-13 Julien Brianceau
[sh4] Prepare baseline JIT for DFG_JIT implementation.
https://bugs.webkit.org/show_bug.cgi?id=119758
Reviewed by Oliver Hunt.
* assembler/MacroAssemblerSH4.h:
- Introduce a loadEffectiveAddress function to avoid code duplication.
- Add ASSERTs and clean code.
* assembler/SH4Assembler.h:
- Prepare DFG_JIT implementation.
- Add ASSERTs.
* jit/JITStubs.cpp:
- Add SH4 specific call for assertions.
* jit/JITStubs.h:
- Cosmetic change.
* jit/JITStubsSH4.h:
- Use constants to be more flexible with sh4 JIT stack frame.
* jit/JSInterfaceJIT.h:
- Cosmetic change.
2013-08-13 Oliver Hunt
Harden executeConstruct against incorrect return types from host functions
https://bugs.webkit.org/show_bug.cgi?id=119757
Reviewed by Mark Hahnenberg.
Add logic to guard against bogus return types. There doesn't seem to be any
class in webkit that does this wrong, but the typed array stubs in debug JSC
do exhibit this bad behaviour.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeConstruct):
2013-08-13 Allan Sandfeld Jensen
[Qt] Fix C++11 build with gcc 4.4 and 4.5
https://bugs.webkit.org/show_bug.cgi?id=119736
Reviewed by Anders Carlsson.
Don't force C++11 mode off anymore.
* Target.pri:
2013-08-12 Oliver Hunt
Remove CodeBlock's notion of adding identifiers entirely
https://bugs.webkit.org/show_bug.cgi?id=119708
Reviewed by Geoffrey Garen.
Remove addAdditionalIdentifier entirely, including the bogus assertion.
Move the addition of identifiers to DFGPlan::reallyAdd
* bytecode/CodeBlock.h:
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::reallyAdd):
* dfg/DFGDesiredIdentifiers.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::finalize):
* dfg/DFGPlan.h:
2013-08-12 Oliver Hunt
Build fix
* runtime/JSCell.h:
2013-08-12 Oliver Hunt
Move additionalIdentifiers into DFGCommonData as only the optimising JITs use them
https://bugs.webkit.org/show_bug.cgi?id=119705
Reviewed by Geoffrey Garen.
Relatively trivial refactoring
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfAdditionalIdentifiers):
(JSC::CodeBlock::addAdditionalIdentifier):
(JSC::CodeBlock::identifier):
(JSC::CodeBlock::numberOfIdentifiers):
* dfg/DFGCommonData.h:
2013-08-12 Oliver Hunt
Stop making unnecessary copy of CodeBlock Identifier Vector
https://bugs.webkit.org/show_bug.cgi?id=119702
Reviewed by Michael Saboff.
Make CodeBlock simply use a separate Vector for additional Identifiers
and use the UnlinkedCodeBlock for the initial set of identifiers.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printGetByIdOp):
(JSC::dumpStructure):
(JSC::dumpChain):
(JSC::CodeBlock::printGetByIdCacheStatus):
(JSC::CodeBlock::printPutByIdOp):
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::shrinkToFit):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfIdentifiers):
(JSC::CodeBlock::numberOfAdditionalIdentifiers):
(JSC::CodeBlock::addAdditionalIdentifier):
(JSC::CodeBlock::identifier):
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::reallyAdd):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emitSlow_op_get_arguments_length):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::compileGetByIdHotPath):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::compileGetByIdSlowCase):
(JSC::JIT::emitSlow_op_put_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::compileGetByIdHotPath):
(JSC::JIT::compileGetByIdSlowCase):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2013-08-08 Mark Lam
Restoring use of StackIterator instead of Interpreter::getStacktrace().
https://bugs.webkit.org/show_bug.cgi?id=119575.
Reviewed by Oliver Hunt.
* interpreter/Interpreter.h:
- Made getStackTrace() private.
* interpreter/StackIterator.cpp:
(JSC::StackIterator::StackIterator):
(JSC::StackIterator::numberOfFrames):
- Computes the number of frames by iterating through the whole stack
from the starting frame. The iterator will save its current frame
position before counting the frames, and then restoring it after
the counting.
(JSC::StackIterator::gotoFrameAtIndex):
(JSC::StackIterator::gotoNextFrame):
(JSC::StackIterator::resetIterator):
- Points the iterator to the starting frame.
* interpreter/StackIteratorPrivate.h:
2013-08-08 Mark Lam
Moved ErrorConstructor and NativeErrorConstructor helper functions into
the Interpreter class.
https://bugs.webkit.org/show_bug.cgi?id=119576.
Reviewed by Oliver Hunt.
This change is needed to prepare for making Interpreter::getStackTrace()
private. It does not change the behavior of the code, only the lexical
scoping.
* interpreter/Interpreter.h:
- Added helper functions for ErrorConstructor and NativeErrorConstructor.
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
(JSC::ErrorConstructor::getConstructData):
(JSC::Interpreter::callErrorConstructor):
(JSC::ErrorConstructor::getCallData):
- Don't want ErrorConstructor to call Interpreter::getStackTrace()
directly. So, we moved the helper functions into the Interpreter
class.
* runtime/NativeErrorConstructor.cpp:
(JSC::Interpreter::constructWithNativeErrorConstructor):
(JSC::NativeErrorConstructor::getConstructData):
(JSC::Interpreter::callNativeErrorConstructor):
(JSC::NativeErrorConstructor::getCallData):
- Don't want NativeErrorConstructor to call Interpreter::getStackTrace()
directly. So, we moved the helper functions into the Interpreter
class.
2013-08-07 Mark Hahnenberg
32-bit code gen for TypeOf doesn't properly update the AbstractInterpreter state
https://bugs.webkit.org/show_bug.cgi?id=119555
Reviewed by Geoffrey Garen.
It uses a speculationCheck where it should be using a DFG_TYPE_CHECK like the 64-bit backend does.
This was causing crashes on maps.google.com in 32-bit debug builds.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2013-08-06 Michael Saboff
REGRESSION(FTL merge): Assertion fail on 32 bit with enabled DFG JIT
https://bugs.webkit.org/show_bug.cgi?id=119405
Reviewed by Geoffrey Garen.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString): For X86 32 bit, construct an indexed address
ourselves to save a register and then load from it.
2013-08-06 Filip Pizlo
DFG FixupPhase should insert Int32ToDouble nodes for number uses in NewArray, and SpeculativeJIT 64-bit should not try to coerce integer constants to double constants
https://bugs.webkit.org/show_bug.cgi?id=119528
Reviewed by Geoffrey Garen.
Either of the two fixes would solve the crash I saw. Basically, for best performance, we want the DFG register allocator to track double uses and non-double
uses of a node separately, and we accomplish this by inserting Int32ToDouble nodes in the FixupPhase. But even if FixupPhase fails to do this, we still want
the DFG register allocator to do the right thing: if it encounters a double use of an integer, it should perform a conversion and preserve the original
format of the value (namely, that it was an integer). For constants, the best format to preserve is None, so that future integer uses rematerialize the int
from scratch. This only affects the 64-bit backend; the 32-bit backend was already doing the right thing.
This also fixes some more debug dumping code, and adds some stronger assertions for integer arrays.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeUnconditionally):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
* runtime/JSObject.h:
(JSC::JSObject::getIndexQuickly):
(JSC::JSObject::tryGetIndexQuickly):
2013-08-08 Stephanie Lewis REGRESSION(153806): Crash @ yahoo.com when WebKit is built with a .order file
Unreviewed.
Ensure llint symbols are in source order.
* JavaScriptCore.order:
2013-08-06 Mark Lam
Assertion failure in emitExpressionInfo when reloading with Web Inspector open.
https://bugs.webkit.org/show_bug.cgi?id=119532.
Reviewed by Oliver Hunt.
* parser/Parser.cpp:
(JSC::::Parser):
- Just need to initialize the Parser's JSTokenLocation's initial line and
startOffset as well during Parser construction.
2013-08-06 Stephanie Lewis
Update Order Files for Safari
Unreviewed.
* JavaScriptCore.order:
2013-08-04 Sam Weinig
Remove support for HTML5 MicroData
https://bugs.webkit.org/show_bug.cgi?id=119480
Reviewed by Anders Carlsson.
* Configurations/FeatureDefines.xcconfig:
2013-08-05 Oliver Hunt
Delay Arguments creation in strict mode
https://bugs.webkit.org/show_bug.cgi?id=119505
Reviewed by Geoffrey Garen.
Make use of the write tracking performed by the parser to
allow us to know if we're modifying the parameters to a function.
Then use that information to make strict mode function opt out
of eager arguments creation.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::createArgumentsIfNecessary):
(JSC::BytecodeGenerator::emitReturn):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::shouldTearOffArgumentsEagerly):
* parser/Nodes.h:
(JSC::ScopeNode::modifiesParameter):
* parser/Parser.cpp:
(JSC::::parseInner):
* parser/Parser.h:
(JSC::Scope::declareParameter):
(JSC::Scope::getCapturedVariables):
(JSC::Parser::declareWrite):
* parser/ParserModes.h:
2013-08-06 Patrick Gansterer
Remove useless code from COMPILER(RVCT) JITStubs
https://bugs.webkit.org/show_bug.cgi?id=119521
Reviewed by Geoffrey Garen.
* jit/JITStubsARMv7.h:
(JSC::ctiVMThrowTrampoline): "ldr r6, [sp, #PRESERVED_R6_OFFSET]" was called twice.
(JSC::ctiOpThrowNotCaught): Ditto.
2013-07-23 David Farler
Provide optional OTHER_CFLAGS, OTHER_CPPFLAGS, OTHER_LDFLAGS additions for building with ASAN
https://bugs.webkit.org/show_bug.cgi?id=117762
Reviewed by Mark Rowe.
* Configurations/DebugRelease.xcconfig:
Add ASAN_OTHER_CFLAGS, CPLUSPLUSFLAGS, LDFLAGS.
* Configurations/JavaScriptCore.xcconfig:
Add ASAN_OTHER_LDFLAGS.
* Configurations/ToolExecutable.xcconfig:
Don't use ASAN for build tools.
2013-08-06 Patrick Gansterer
Build fix for ARM MSVC after r153222 and r153648.
* jit/JITStubsARM.h: Added ctiVMThrowTrampolineSlowpath.
2013-08-06 Patrick Gansterer
Build fix for ARM MSVC after r150109.
Read the stub template from a header files instead of the JITStubs.cpp.
* CMakeLists.txt:
* DerivedSources.pri:
* create_jit_stubs:
2013-08-05 Oliver Hunt
Move TypedArray implementation into JSC
https://bugs.webkit.org/show_bug.cgi?id=119489
Reviewed by Filip Pizlo.
Move TypedArray implementation into JSC in advance of re-implementation
* GNUmakefile.list.am:
* JSCTypedArrayStubs.h:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/ArrayBuffer.cpp: Renamed from Source/WTF/wtf/ArrayBuffer.cpp.
(JSC::ArrayBuffer::transfer):
(JSC::ArrayBuffer::addView):
(JSC::ArrayBuffer::removeView):
* runtime/ArrayBuffer.h: Renamed from Source/WTF/wtf/ArrayBuffer.h.
(JSC::ArrayBufferContents::ArrayBufferContents):
(JSC::ArrayBufferContents::data):
(JSC::ArrayBufferContents::sizeInBytes):
(JSC::ArrayBufferContents::transfer):
(JSC::ArrayBufferContents::copyTo):
(JSC::ArrayBuffer::isNeutered):
(JSC::ArrayBuffer::~ArrayBuffer):
(JSC::ArrayBuffer::clampValue):
(JSC::ArrayBuffer::create):
(JSC::ArrayBuffer::createUninitialized):
(JSC::ArrayBuffer::ArrayBuffer):
(JSC::ArrayBuffer::data):
(JSC::ArrayBuffer::byteLength):
(JSC::ArrayBuffer::slice):
(JSC::ArrayBuffer::sliceImpl):
(JSC::ArrayBuffer::clampIndex):
(JSC::ArrayBufferContents::tryAllocate):
(JSC::ArrayBufferContents::~ArrayBufferContents):
* runtime/ArrayBufferView.cpp: Renamed from Source/WTF/wtf/ArrayBufferView.cpp.
(JSC::ArrayBufferView::ArrayBufferView):
(JSC::ArrayBufferView::~ArrayBufferView):
(JSC::ArrayBufferView::neuter):
* runtime/ArrayBufferView.h: Renamed from Source/WTF/wtf/ArrayBufferView.h.
(JSC::ArrayBufferView::buffer):
(JSC::ArrayBufferView::baseAddress):
(JSC::ArrayBufferView::byteOffset):
(JSC::ArrayBufferView::setNeuterable):
(JSC::ArrayBufferView::isNeuterable):
(JSC::ArrayBufferView::verifySubRange):
(JSC::ArrayBufferView::clampOffsetAndNumElements):
(JSC::ArrayBufferView::setImpl):
(JSC::ArrayBufferView::setRangeImpl):
(JSC::ArrayBufferView::zeroRangeImpl):
(JSC::ArrayBufferView::calculateOffsetAndLength):
* runtime/Float32Array.h: Renamed from Source/WTF/wtf/Float32Array.h.
(JSC::Float32Array::set):
(JSC::Float32Array::getType):
(JSC::Float32Array::create):
(JSC::Float32Array::createUninitialized):
(JSC::Float32Array::Float32Array):
(JSC::Float32Array::subarray):
* runtime/Float64Array.h: Renamed from Source/WTF/wtf/Float64Array.h.
(JSC::Float64Array::set):
(JSC::Float64Array::getType):
(JSC::Float64Array::create):
(JSC::Float64Array::createUninitialized):
(JSC::Float64Array::Float64Array):
(JSC::Float64Array::subarray):
* runtime/Int16Array.h: Renamed from Source/WTF/wtf/Int16Array.h.
(JSC::Int16Array::getType):
(JSC::Int16Array::create):
(JSC::Int16Array::createUninitialized):
(JSC::Int16Array::Int16Array):
(JSC::Int16Array::subarray):
* runtime/Int32Array.h: Renamed from Source/WTF/wtf/Int32Array.h.
(JSC::Int32Array::getType):
(JSC::Int32Array::create):
(JSC::Int32Array::createUninitialized):
(JSC::Int32Array::Int32Array):
(JSC::Int32Array::subarray):
* runtime/Int8Array.h: Renamed from Source/WTF/wtf/Int8Array.h.
(JSC::Int8Array::getType):
(JSC::Int8Array::create):
(JSC::Int8Array::createUninitialized):
(JSC::Int8Array::Int8Array):
(JSC::Int8Array::subarray):
* runtime/IntegralTypedArrayBase.h: Renamed from Source/WTF/wtf/IntegralTypedArrayBase.h.
(JSC::IntegralTypedArrayBase::set):
(JSC::IntegralTypedArrayBase::IntegralTypedArrayBase):
* runtime/TypedArrayBase.h: Renamed from Source/WTF/wtf/TypedArrayBase.h.
(JSC::TypedArrayBase::data):
(JSC::TypedArrayBase::set):
(JSC::TypedArrayBase::setRange):
(JSC::TypedArrayBase::zeroRange):
(JSC::TypedArrayBase::length):
(JSC::TypedArrayBase::byteLength):
(JSC::TypedArrayBase::item):
(JSC::TypedArrayBase::checkInboundData):
(JSC::TypedArrayBase::TypedArrayBase):
(JSC::TypedArrayBase::create):
(JSC::TypedArrayBase::createUninitialized):
(JSC::TypedArrayBase::subarrayImpl):
(JSC::TypedArrayBase::neuter):
* runtime/Uint16Array.h: Renamed from Source/WTF/wtf/Uint16Array.h.
(JSC::Uint16Array::getType):
(JSC::Uint16Array::create):
(JSC::Uint16Array::createUninitialized):
(JSC::Uint16Array::Uint16Array):
(JSC::Uint16Array::subarray):
* runtime/Uint32Array.h: Renamed from Source/WTF/wtf/Uint32Array.h.
(JSC::Uint32Array::getType):
(JSC::Uint32Array::create):
(JSC::Uint32Array::createUninitialized):
(JSC::Uint32Array::Uint32Array):
(JSC::Uint32Array::subarray):
* runtime/Uint8Array.h: Renamed from Source/WTF/wtf/Uint8Array.h.
(JSC::Uint8Array::getType):
(JSC::Uint8Array::create):
(JSC::Uint8Array::createUninitialized):
(JSC::Uint8Array::Uint8Array):
(JSC::Uint8Array::subarray):
* runtime/Uint8ClampedArray.h: Renamed from Source/WTF/wtf/Uint8ClampedArray.h.
(JSC::Uint8ClampedArray::getType):
(JSC::Uint8ClampedArray::create):
(JSC::Uint8ClampedArray::createUninitialized):
(JSC::Uint8ClampedArray::zeroFill):
(JSC::Uint8ClampedArray::set):
(JSC::Uint8ClampedArray::Uint8ClampedArray):
(JSC::Uint8ClampedArray::subarray):
* runtime/VM.h:
2013-08-03 Filip Pizlo
Copied space should be able to handle more than one copied backing store per JSCell
https://bugs.webkit.org/show_bug.cgi?id=119471
Reviewed by Mark Hahnenberg.
This allows a cell to call copyLater() multiple times for multiple different
backing stores, and then have copyBackingStore() called exactly once for each
of those. A token tells it which backing store to copy. All backing stores
must be named using the CopyToken, an enumeration which currently cannot
exceed eight entries.
When copyBackingStore() is called, it's up to the callee to (a) use the token
to decide what to copy and (b) call its base class's copyBackingStore() in
case the base class had something that needed copying. The only exception is
that JSCell never asks anything to be copied, and so if your base is JSCell
then you don't have to do anything.
* GNUmakefile.list.am:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/CopiedBlock.h:
* heap/CopiedBlockInlines.h:
(JSC::CopiedBlock::reportLiveBytes):
* heap/CopyToken.h: Added.
* heap/CopyVisitor.cpp:
(JSC::CopyVisitor::copyFromShared):
* heap/CopyVisitor.h:
* heap/CopyVisitorInlines.h:
(JSC::CopyVisitor::visitItem):
* heap/CopyWorkList.h:
(JSC::CopyWorklistItem::CopyWorklistItem):
(JSC::CopyWorklistItem::cell):
(JSC::CopyWorklistItem::token):
(JSC::CopyWorkListSegment::get):
(JSC::CopyWorkListSegment::append):
(JSC::CopyWorkListSegment::data):
(JSC::CopyWorkListIterator::get):
(JSC::CopyWorkListIterator::operator*):
(JSC::CopyWorkListIterator::operator->):
(JSC::CopyWorkList::append):
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::copyLater):
* runtime/ClassInfo.h:
* runtime/JSCell.cpp:
(JSC::JSCell::copyBackingStore):
* runtime/JSCell.h:
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterfly):
(JSC::JSObject::copyBackingStore):
* runtime/JSObject.h:
2013-08-05 Zan Dobersek
[Automake] Define ENABLE_JIT through the Autoconf header
https://bugs.webkit.org/show_bug.cgi?id=119445
Reviewed by Martin Robinson.
* GNUmakefile.am: Remove JSC_CPPFLAGS from the cpp flags for the JSC library.
2013-08-03 Filip Pizlo
hasIndexingHeader() ought really to be a property of an object and its structure, not just its structure
https://bugs.webkit.org/show_bug.cgi?id=119470
Reviewed by Oliver Hunt.
Structure can still tell you if the object "could" (in the conservative sense)
have an indexing header; that's used by the compiler.
Most of the time if you want to know if there's an indexing header, you ask the
JSObject.
In some cases, the JSObject wants to know if it would have an indexing header if
it had a different structure; then it uses Structure::hasIndexingHeader(JSCell*).
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryCachePutByID):
(JSC::DFG::tryBuildPutByIdList):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
* runtime/ButterflyInlines.h:
(JSC::Butterfly::create):
(JSC::Butterfly::growPropertyStorage):
(JSC::Butterfly::growArrayRight):
(JSC::Butterfly::resizeArray):
* runtime/JSObject.cpp:
(JSC::JSObject::copyButterfly):
(JSC::JSObject::visitButterfly):
* runtime/JSObject.h:
(JSC::JSObject::hasIndexingHeader):
(JSC::JSObject::setButterfly):
* runtime/Structure.h:
(JSC::Structure::couldHaveIndexingHeader):
(JSC::Structure::hasIndexingHeader):
2013-08-02 Chris Curtis
Give the error object's stack property accessor attributes.
https://bugs.webkit.org/show_bug.cgi?id=119404
Reviewed by Geoffrey Garen.
Changed the attributes of error object's stack property to allow developers to write
and delete the stack property. This will match the functionality of Chrome. Firefox
allows developers to write the error's stack, but not delete it.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::addStackTraceIfNecessary):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
2013-08-02 Oliver Hunt
Incorrect type speculation reported by ToPrimitive
https://bugs.webkit.org/show_bug.cgi?id=119458
Reviewed by Mark Hahnenberg.
Make sure that we report the correct type possibilities for the output
from ToPrimitive
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
2013-08-02 Gavin Barraclough
Remove no-arguments constructor to PropertySlot
https://bugs.webkit.org/show_bug.cgi?id=119460
Reviewed by Geoff Garen.
This constructor was unsafe if getValue is subsequently called,
and the property is a getter. Simplest to just remove it.
* runtime/Arguments.cpp:
(JSC::Arguments::defineOwnProperty):
* runtime/JSActivation.cpp:
(JSC::JSActivation::getOwnPropertyDescriptor):
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertyDescriptor):
(JSC::JSFunction::getOwnNonIndexPropertyNames):
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::defineOwnProperty):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::hasOwnPropertyForWrite):
* runtime/JSNameScope.cpp:
(JSC::JSNameScope::put):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::Walker::walk):
* runtime/JSObject.cpp:
(JSC::JSObject::hasProperty):
(JSC::JSObject::hasOwnProperty):
(JSC::JSObject::reifyStaticFunctionsForDelete):
* runtime/Lookup.h:
(JSC::getStaticPropertyDescriptor):
(JSC::getStaticFunctionDescriptor):
(JSC::getStaticValueDescriptor):
* runtime/ObjectConstructor.cpp:
(JSC::defineProperties):
* runtime/PropertySlot.h:
2013-08-02 Mark Hahnenberg
DFG validation can cause assertion failures due to dumping
https://bugs.webkit.org/show_bug.cgi?id=119456
Reviewed by Geoffrey Garen.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::hasHash):
(JSC::CodeBlock::isSafeToComputeHash):
(JSC::CodeBlock::hash):
(JSC::CodeBlock::dumpAssumingJITType):
* bytecode/CodeBlock.h:
2013-08-02 Chris Curtis
Have vm's exceptionStack match java's vm's exceptionStack.
https://bugs.webkit.org/show_bug.cgi?id=119362
Reviewed by Geoffrey Garen.
The error object's stack is only updated if it does not exist yet. This matches
the functionality of other browsers, and Java VMs.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::addStackTraceIfNecessary):
(JSC::Interpreter::throwException):
* runtime/VM.cpp:
(JSC::VM::clearExceptionStack):
* runtime/VM.h:
(JSC::VM::lastExceptionStack):
2013-08-02 Julien Brianceau
REGRESSION(FTL): Fix mips implementation of ctiVMThrowTrampolineSlowpath.
https://bugs.webkit.org/show_bug.cgi?id=119447
Reviewed by Geoffrey Garen.
Fix .cpload, update call frame and do not restore registers from JIT stack frame in
mips implementation of ctiVMThrowTrampolineSlowpath. This change is similar to
r153583 (sh4) and r153648 (ARM).
* jit/JITStubsMIPS.h:
2013-08-01 Filip Pizlo
hasIndexingHeader should be a property of the Structure, not just the IndexingType
https://bugs.webkit.org/show_bug.cgi?id=119422
Reviewed by Oliver Hunt.
This simplifies some code and also allows Structure to claim that an object
has an indexing header even if it doesn't have indexed properties.
I also changed some calls to use hasIndexedProperties() since in some cases,
that's what we actually meant. Currently the two are synonyms.
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryCachePutByID):
(JSC::DFG::tryBuildPutByIdList):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
* runtime/ButterflyInlines.h:
(JSC::Butterfly::create):
(JSC::Butterfly::growPropertyStorage):
(JSC::Butterfly::growArrayRight):
(JSC::Butterfly::resizeArray):
* runtime/IndexingType.h:
* runtime/JSObject.cpp:
(JSC::JSObject::copyButterfly):
(JSC::JSObject::visitButterfly):
(JSC::JSObject::setPrototype):
* runtime/JSObject.h:
(JSC::JSObject::setButterfly):
* runtime/JSPropertyNameIterator.cpp:
(JSC::JSPropertyNameIterator::create):
* runtime/Structure.h:
(JSC::Structure::hasIndexingHeader):
2013-08-02 Julien Brianceau
REGRESSION: ARM still crashes after change set r153612.
https://bugs.webkit.org/show_bug.cgi?id=119433
Reviewed by Michael Saboff.
Update call frame and do not restore registers from JIT stack frame in ARM and ARMv7
implementations of ctiVMThrowTrampolineSlowpath. This change is similar to r153583
for sh4 architecture.
* jit/JITStubsARM.h:
* jit/JITStubsARMv7.h:
2013-08-02 Michael Saboff
REGRESSION(r153612): It made jsc and layout tests crash
https://bugs.webkit.org/show_bug.cgi?id=119440
Reviewed by Csaba Osztrogonác.
Made the changes if changeset r153612 only apply to 32 bit builds.
* jit/JITExceptions.cpp:
* jit/JITExceptions.h:
* jit/JITStubs.cpp:
(JSC::cti_vm_throw_slowpath):
* jit/JITStubs.h:
2013-08-02 Patrick Gansterer
Add JSCTestRunnerUtils to the list of forwarding headers to fix build.
* CMakeLists.txt:
2013-08-01 Ruth Fong
[Forms: color] popover color well implementation
and https://bugs.webkit.org/show_bug.cgi?id=119356
Reviewed by Benjamin Poulain.
* Configurations/FeatureDefines.xcconfig: Added and enabled INPUT_TYPE_COLOR_POPOVER.
2013-08-01 Oliver Hunt
DFG is not enforcing correct ordering of ToString conversion in MakeRope
https://bugs.webkit.org/show_bug.cgi?id=119408
Reviewed by Filip Pizlo.
Construct ToString and Phantom nodes in advance of MakeRope
nodes to ensure that ordering is ensured, and correct values
will be reified on OSR exit.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2013-08-01 Michael Saboff
REGRESSION: Crash beneath cti_vm_throw_slowpath due to invalid CallFrame pointer
https://bugs.webkit.org/show_bug.cgi?id=119140
Reviewed by Filip Pizlo.
Ensure that ExceptionHandler is returned by functions in two registers by encoding the value as a 64 bit int.
* jit/JITExceptions.cpp:
(JSC::encode):
* jit/JITExceptions.h:
* jit/JITStubs.cpp:
(JSC::cti_vm_throw_slowpath):
* jit/JITStubs.h:
2013-08-01 Julien Brianceau
REGRESSION(FTL): Fix sh4 implementation of ctiVMThrowTrampolineSlowpath.
https://bugs.webkit.org/show_bug.cgi?id=119391
Reviewed by Csaba Osztrogonác.
* jit/JITStubsSH4.h: Fix ctiVMThrowTrampolineSlowpath implementation:
- Call frame is in r14 register.
- Do not restore registers from JIT stack frame here.
2013-07-31 Gavin Barraclough
More cleanup in PropertySlot
https://bugs.webkit.org/show_bug.cgi?id=119359
Reviewed by Geoff Garen.
m_slotBase is overloaded to store the (receiver) thisValue and the object that contains the property,
This is confusing, and means that slotBase cannot be typed correctly (can only be a JSObject).
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryCacheGetByID):
(JSC::DFG::tryBuildGetByIDList):
- No need to ASSERT slotBase is an object.
* jit/JITStubs.cpp:
(JSC::tryCacheGetByID):
(JSC::DEFINE_STUB_FUNCTION):
- No need to ASSERT slotBase is an object.
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertySlotByIndex):
(JSC::JSObject::fillGetterPropertySlot):
- Pass an object through to setGetterSlot.
* runtime/JSObject.h:
(JSC::PropertySlot::getValue):
- Moved from PropertySlot (need to know anout JSObject).
* runtime/PropertySlot.cpp:
(JSC::PropertySlot::functionGetter):
- update per member name changes
* runtime/PropertySlot.h:
(JSC::PropertySlot::PropertySlot):
- Argument to constructor set to 'thisValue'.
(JSC::PropertySlot::slotBase):
- This returns a JSObject*.
(JSC::PropertySlot::setValue):
(JSC::PropertySlot::setCustom):
(JSC::PropertySlot::setCacheableCustom):
(JSC::PropertySlot::setCustomIndex):
(JSC::PropertySlot::setGetterSlot):
(JSC::PropertySlot::setCacheableGetterSlot):
- slotBase is a JSObject*, make setGetterSlot set slotBase for consistency.
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayEntry::get):
- Pass an object through to setGetterSlot.
* runtime/SparseArrayValueMap.h:
- Pass an object through to setGetterSlot.
2013-07-31 Yi Shen
Reduce JSC API static value setter/getter overhead.
https://bugs.webkit.org/show_bug.cgi?id=119277
Reviewed by Geoffrey Garen.
Add property name to the static value entry, so that OpaqueJSString::create() doesn't
need to get called every time when set or get the static value.
* API/JSCallbackObjectFunctions.h:
(JSC::::put):
(JSC::::putByIndex):
(JSC::::getStaticValue):
* API/JSClassRef.cpp:
(OpaqueJSClassContextData::OpaqueJSClassContextData):
* API/JSClassRef.h:
(StaticValueEntry::StaticValueEntry):
2013-07-31 Kwang Yul Seo
Use emptyString instead of String("")
https://bugs.webkit.org/show_bug.cgi?id=119335
Reviewed by Darin Adler.
Use emptyString() instead of String("") because it is better style and
faster. This is a followup to r116908, removing all occurrences of
String("") from WebKit.
* runtime/RegExpConstructor.cpp:
(JSC::constructRegExp):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncMatch):
(JSC::stringProtoFuncSearch):
2013-07-31 Ruth Fong
Mac UI behaviour
and https://bugs.webkit.org/show_bug.cgi?id=61276
Reviewed by Brady Eidson.
* Configurations/FeatureDefines.xcconfig: Enabled INPUT_TYPE_COLOR.
2013-07-31 Mark Hahnenberg
DFG doesn't account for inlining of functions with switch statements that haven't been executed by the baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=119349
Reviewed by Geoffrey Garen.
Prior to this patch, the baseline JIT was responsible for resizing the ctiOffsets Vector for
SimpleJumpTables to be equal to the size of the branchOffsets Vector. The DFG implicitly relied
on code it compiled with any switch statements to have been run in the baseline JIT first.
However, if the DFG chooses to inline a function that has never been compiled by the baseline
JIT then this resizing never happens and we crash at link time in the DFG.
We can fix this by also doing the resize in the DFG to catch this case.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
2013-07-31 Gavin Barraclough
Speculative Windows build fix.
Reviewed by NOBODY
* runtime/JSString.cpp:
(JSC::JSRopeString::getIndexSlowCase):
* runtime/JSString.h:
2013-07-30 Gavin Barraclough
Some cleanup in JSValue::get
https://bugs.webkit.org/show_bug.cgi?id=119343
Reviewed by Geoff Garen.
JSValue::get is implemented to:
1) Check if the value is a cell – if not, synthesize a prototype to search,
2) call getOwnPropertySlot on the cell,
3) if this returns false, cast to JSObject to get the prototype, and walk the prototype chain.
By all rights this should crash when passed a string and accessing a property that does not exist, because
the string is a cell, getOwnPropertySlot should return false, and the cast to JSObject should be unsafe.
To work around this, JSString::getOwnPropertySlot actually implements 'get' functionality - searching the
prototype chain, and faking out a return value of undefined if no property is found.
This is a huge hazard, since fixing JSString::getOwnPropertySlot or calling getOwnPropertySlot on cells
from elsewhere would introduce bugs. Fortunately it is only ever called in this one place.
The fix here is to move getOwnPropertySlot onto JSObjecte and end this madness - cells don't have property
slots anyway.
Interesting changes are in JSCJSValueInlines.h, JSString.cpp - the rest is pretty much all JSCell -> JSObject.
2013-07-31 Michael Saboff
[Win] JavaScript crash.
https://bugs.webkit.org/show_bug.cgi?id=119339
Reviewed by Mark Hahnenberg.
* jit/JITStubsX86.h: Implement ctiVMThrowTrampoline and
ctiVMThrowTrampolineSlowpath the same way as the gcc x86 version does.
2013-07-30 Mark Hahnenberg
GetByVal on Arguments does the wrong size load when checking the Arguments object length
https://bugs.webkit.org/show_bug.cgi?id=119281
Reviewed by Geoffrey Garen.
This leads to out of bounds accesses and subsequent crashes.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2013-07-30 Oliver Hunt
Add an assertion to SpeculateCellOperand
https://bugs.webkit.org/show_bug.cgi?id=119276
Reviewed by Michael Saboff.
More assertions are better
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::compile):
2013-07-30 Mark Lam
Fix problems with divot and lineStart mismatches.
https://bugs.webkit.org/show_bug.cgi?id=118662.
Reviewed by Oliver Hunt.
r152494 added the recording of lineStart values for divot positions.
This is needed for the computation of column numbers. Similarly, it also
added the recording of line numbers for the divot positions. One problem
with the approach taken was that the line and lineStart values were
recorded independently, and hence were not always guaranteed to be
sampled at the same place that the divot position is recorded. This
resulted in potential mismatches that cause some assertions to fail.
The solution is to introduce a JSTextPosition abstraction that records
the divot position, line, and lineStart as a single quantity. Wherever
we record the divot position as an unsigned int previously, we now record
its JSTextPosition which captures all 3 values in one go. This ensures
that the captured line and lineStart will always match the captured divot
position.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitCallVarargs):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitDebugHook):
- Use JSTextPosition instead of passing line and lineStart explicitly.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitExpressionInfo):
- Use JSTextPosition instead of passing line and lineStart explicitly.
* bytecompiler/NodesCodegen.cpp:
(JSC::ThrowableExpressionData::emitThrowReferenceError):
(JSC::ResolveNode::emitBytecode):
(JSC::BracketAccessorNode::emitBytecode):
(JSC::DotAccessorNode::emitBytecode):
(JSC::NewExprNode::emitBytecode):
(JSC::EvalFunctionCallNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionCallResolveNode::emitBytecode):
(JSC::FunctionCallBracketNode::emitBytecode):
(JSC::FunctionCallDotNode::emitBytecode):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::PostfixNode::emitResolve):
(JSC::PostfixNode::emitBracket):
(JSC::PostfixNode::emitDot):
(JSC::DeleteResolveNode::emitBytecode):
(JSC::DeleteBracketNode::emitBytecode):
(JSC::DeleteDotNode::emitBytecode):
(JSC::PrefixNode::emitResolve):
(JSC::PrefixNode::emitBracket):
(JSC::PrefixNode::emitDot):
(JSC::UnaryOpNode::emitBytecode):
(JSC::BinaryOpNode::emitStrcat):
(JSC::BinaryOpNode::emitBytecode):
(JSC::ThrowableBinaryOpNode::emitBytecode):
(JSC::InstanceOfNode::emitBytecode):
(JSC::emitReadModifyAssignment):
(JSC::ReadModifyResolveNode::emitBytecode):
(JSC::AssignResolveNode::emitBytecode):
(JSC::AssignDotNode::emitBytecode):
(JSC::ReadModifyDotNode::emitBytecode):
(JSC::AssignBracketNode::emitBytecode):
(JSC::ReadModifyBracketNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::ThrowNode::emitBytecode):
- Use JSTextPosition instead of passing line and lineStart explicitly.
* parser/ASTBuilder.h:
- Replaced ASTBuilder::PositionInfo with JSTextPosition.
(JSC::ASTBuilder::BinaryOpInfo::BinaryOpInfo):
(JSC::ASTBuilder::AssignmentInfo::AssignmentInfo):
(JSC::ASTBuilder::createResolve):
(JSC::ASTBuilder::createBracketAccess):
(JSC::ASTBuilder::createDotAccess):
(JSC::ASTBuilder::createRegExp):
(JSC::ASTBuilder::createNewExpr):
(JSC::ASTBuilder::createAssignResolve):
(JSC::ASTBuilder::createExprStatement):
(JSC::ASTBuilder::createForInLoop):
(JSC::ASTBuilder::createReturnStatement):
(JSC::ASTBuilder::createBreakStatement):
(JSC::ASTBuilder::createContinueStatement):
(JSC::ASTBuilder::createLabelStatement):
(JSC::ASTBuilder::createWithStatement):
(JSC::ASTBuilder::createThrowStatement):
(JSC::ASTBuilder::appendBinaryExpressionInfo):
(JSC::ASTBuilder::appendUnaryToken):
(JSC::ASTBuilder::unaryTokenStackLastStart):
(JSC::ASTBuilder::assignmentStackAppend):
(JSC::ASTBuilder::createAssignment):
(JSC::ASTBuilder::setExceptionLocation):
(JSC::ASTBuilder::makeDeleteNode):
(JSC::ASTBuilder::makeFunctionCallNode):
(JSC::ASTBuilder::makeBinaryNode):
(JSC::ASTBuilder::makeAssignNode):
(JSC::ASTBuilder::makePrefixNode):
(JSC::ASTBuilder::makePostfixNode):
- Use JSTextPosition instead of passing line and lineStart explicitly.
* parser/Lexer.cpp:
(JSC::::lex):
- Added support for capturing the appropriate JSTextPositions instead
of just the character offset.
* parser/Lexer.h:
(JSC::Lexer::currentPosition):
(JSC::::lexExpectIdentifier):
- Added support for capturing the appropriate JSTextPositions instead
of just the character offset.
* parser/NodeConstructors.h:
(JSC::Node::Node):
(JSC::ResolveNode::ResolveNode):
(JSC::EvalFunctionCallNode::EvalFunctionCallNode):
(JSC::FunctionCallValueNode::FunctionCallValueNode):
(JSC::FunctionCallResolveNode::FunctionCallResolveNode):
(JSC::FunctionCallBracketNode::FunctionCallBracketNode):
(JSC::FunctionCallDotNode::FunctionCallDotNode):
(JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
(JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
(JSC::PostfixNode::PostfixNode):
(JSC::DeleteResolveNode::DeleteResolveNode):
(JSC::DeleteBracketNode::DeleteBracketNode):
(JSC::DeleteDotNode::DeleteDotNode):
(JSC::PrefixNode::PrefixNode):
(JSC::ReadModifyResolveNode::ReadModifyResolveNode):
(JSC::ReadModifyBracketNode::ReadModifyBracketNode):
(JSC::AssignBracketNode::AssignBracketNode):
(JSC::AssignDotNode::AssignDotNode):
(JSC::ReadModifyDotNode::ReadModifyDotNode):
(JSC::AssignErrorNode::AssignErrorNode):
(JSC::WithNode::WithNode):
(JSC::ForInNode::ForInNode):
- Use JSTextPosition instead of passing line and lineStart explicitly.
* parser/Nodes.cpp:
(JSC::StatementNode::setLoc):
- Use JSTextPosition instead of passing line and lineStart explicitly.
* parser/Nodes.h:
(JSC::Node::lineNo):
(JSC::Node::startOffset):
(JSC::Node::lineStartOffset):
(JSC::Node::position):
(JSC::ThrowableExpressionData::ThrowableExpressionData):
(JSC::ThrowableExpressionData::setExceptionSourceCode):
(JSC::ThrowableExpressionData::divot):
(JSC::ThrowableExpressionData::divotStart):
(JSC::ThrowableExpressionData::divotEnd):
(JSC::ThrowableSubExpressionData::ThrowableSubExpressionData):
(JSC::ThrowableSubExpressionData::setSubexpressionInfo):
(JSC::ThrowableSubExpressionData::subexpressionDivot):
(JSC::ThrowableSubExpressionData::subexpressionStart):
(JSC::ThrowableSubExpressionData::subexpressionEnd):
(JSC::ThrowablePrefixedSubExpressionData::ThrowablePrefixedSubExpressionData):
(JSC::ThrowablePrefixedSubExpressionData::setSubexpressionInfo):
(JSC::ThrowablePrefixedSubExpressionData::subexpressionDivot):
(JSC::ThrowablePrefixedSubExpressionData::subexpressionStart):
(JSC::ThrowablePrefixedSubExpressionData::subexpressionEnd):
- Use JSTextPosition instead of passing line and lineStart explicitly.
* parser/Parser.cpp:
(JSC::::Parser):
(JSC::::parseInner):
- Use JSTextPosition instead of passing line and lineStart explicitly.
(JSC::::didFinishParsing):
- Remove setting of m_lastLine value. We always pass in the value from
m_lastLine anyway. So, this assignment is effectively a nop.
(JSC::::parseVarDeclaration):
(JSC::::parseVarDeclarationList):
(JSC::::parseForStatement):
(JSC::::parseBreakStatement):
(JSC::::parseContinueStatement):
(JSC::::parseReturnStatement):
(JSC::::parseThrowStatement):
(JSC::::parseWithStatement):
(JSC::::parseTryStatement):
(JSC::::parseBlockStatement):
(JSC::::parseFunctionDeclaration):
(JSC::LabelInfo::LabelInfo):
(JSC::::parseExpressionOrLabelStatement):
(JSC::::parseExpressionStatement):
(JSC::::parseAssignmentExpression):
(JSC::::parseBinaryExpression):
(JSC::::parseProperty):
(JSC::::parsePrimaryExpression):
(JSC::::parseMemberExpression):
(JSC::::parseUnaryExpression):
- Use JSTextPosition instead of passing line and lineStart explicitly.
* parser/Parser.h:
(JSC::Parser::next):
(JSC::Parser::nextExpectIdentifier):
(JSC::Parser::getToken):
(JSC::Parser::tokenStartPosition):
(JSC::Parser::tokenEndPosition):
(JSC::Parser::lastTokenEndPosition):
(JSC::::parse):
- Use JSTextPosition instead of passing line and lineStart explicitly.
* parser/ParserTokens.h:
(JSC::JSTextPosition::JSTextPosition):
(JSC::JSTextPosition::operator+):
(JSC::JSTextPosition::operator-):
(JSC::JSTextPosition::operator int):
- Added JSTextPosition.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::makeFunctionCallNode):
(JSC::SyntaxChecker::makeAssignNode):
(JSC::SyntaxChecker::makePrefixNode):
(JSC::SyntaxChecker::makePostfixNode):
(JSC::SyntaxChecker::makeDeleteNode):
(JSC::SyntaxChecker::createResolve):
(JSC::SyntaxChecker::createBracketAccess):
(JSC::SyntaxChecker::createDotAccess):
(JSC::SyntaxChecker::createRegExp):
(JSC::SyntaxChecker::createNewExpr):
(JSC::SyntaxChecker::createAssignResolve):
(JSC::SyntaxChecker::createForInLoop):
(JSC::SyntaxChecker::createReturnStatement):
(JSC::SyntaxChecker::createBreakStatement):
(JSC::SyntaxChecker::createContinueStatement):
(JSC::SyntaxChecker::createWithStatement):
(JSC::SyntaxChecker::createLabelStatement):
(JSC::SyntaxChecker::createThrowStatement):
(JSC::SyntaxChecker::appendBinaryExpressionInfo):
(JSC::SyntaxChecker::operatorStackPop):
- Use JSTextPosition instead of passing line and lineStart explicitly.
2013-07-29 Carlos Garcia Campos
Unreviewed. Fix make distcheck.
* GNUmakefile.list.am: Add missing files to compilation.
* bytecode/CodeBlock.cpp: Add a ENABLE(FTL_JIT) #if block to
include FTL header files not included in the compilation.
* dfg/DFGDriver.cpp: Ditto.
* dfg/DFGPlan.cpp: Ditto.
2013-07-29 Chris Curtis
Eager stack trace for error objects.
https://bugs.webkit.org/show_bug.cgi?id=118918
Reviewed by Geoffrey Garen.
Chrome and Firefox give error objects the stack property and we wanted to match
that functionality. This allows developers to see the stack without throwing an object.
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
For error objects that are not thrown as an exception, we pass the stackTrace in
as a parameter. This allows the error object to have the stack property.
* interpreter/Interpreter.cpp:
(JSC::stackTraceAsString):
Helper function used to eliminate duplicate code.
(JSC::Interpreter::addStackTraceIfNecessary):
When an error object is created by the user the vm->exceptionStack is not set.
If the user throws this error object later the stack that is in the error object
may not be the correct stack for the throw, so when we set the vm->exception stack,
the stack property on the error object is set as well.
* runtime/ErrorConstructor.cpp:
(JSC::constructWithErrorConstructor):
(JSC::callErrorConstructor):
* runtime/NativeErrorConstructor.cpp:
(JSC::constructWithNativeErrorConstructor):
(JSC::callNativeErrorConstructor):
These functions indicate that the user created an error object. For all error objects
that the user explicitly creates, the topCallFrame is at a new frame created to
handle the user's call. In this case though, the error object needs the caller's
frame to create the stack trace correctly.
* interpreter/Interpreter.h:
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::create):
2013-07-29 Gavin Barraclough
Some cleanup in PropertySlot
https://bugs.webkit.org/show_bug.cgi?id=119189
Reviewed by Geoff Garen.
PropertySlot represents a property in one of four states - value, getter, custom, or custom-index.
The state is currently tracked redundantly by two mechanisms - the custom getter function (m_getValue)
is set to a special value to indicate the type (other than custom), and the type is also tracked by
an enum - but only if cacheable. Cacheability can typically be determined by the value of m_offset
(this is invalidOffset if not cacheable).
* Internally, always track the type of the property using an enum value, PropertyType.
* Use m_offset to indicate cacheable.
* Keep the external interface (CachedPropertyType) unchanged.
* Better pack data into the m_data union.
Performance neutral.
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryCacheGetByID):
(JSC::DFG::tryBuildGetByIDList):
- cachedPropertyType() -> isCacheable*()
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompileGetByIdProto):
(JSC::JIT::privateCompileGetByIdSelfList):
(JSC::JIT::privateCompileGetByIdProtoList):
(JSC::JIT::privateCompileGetByIdChainList):
(JSC::JIT::privateCompileGetByIdChain):
- cachedPropertyType() -> isCacheable*()
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::privateCompileGetByIdProto):
(JSC::JIT::privateCompileGetByIdSelfList):
(JSC::JIT::privateCompileGetByIdProtoList):
(JSC::JIT::privateCompileGetByIdChainList):
(JSC::JIT::privateCompileGetByIdChain):
- cachedPropertyType() -> isCacheable*()
* jit/JITStubs.cpp:
(JSC::tryCacheGetByID):
- cachedPropertyType() -> isCacheable*()
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
- cachedPropertyType() -> isCacheable*()
* runtime/PropertySlot.cpp:
(JSC::PropertySlot::functionGetter):
- refactoring described above.
* runtime/PropertySlot.h:
(JSC::PropertySlot::PropertySlot):
(JSC::PropertySlot::getValue):
(JSC::PropertySlot::isCacheable):
(JSC::PropertySlot::isCacheableValue):
(JSC::PropertySlot::isCacheableGetter):
(JSC::PropertySlot::isCacheableCustom):
(JSC::PropertySlot::cachedOffset):
(JSC::PropertySlot::customGetter):
(JSC::PropertySlot::setValue):
(JSC::PropertySlot::setCustom):
(JSC::PropertySlot::setCacheableCustom):
(JSC::PropertySlot::setCustomIndex):
(JSC::PropertySlot::setGetterSlot):
(JSC::PropertySlot::setCacheableGetterSlot):
(JSC::PropertySlot::setUndefined):
(JSC::PropertySlot::slotBase):
(JSC::PropertySlot::setBase):
- refactoring described above.
2013-07-28 Oliver Hunt
REGRESSION: Crash when opening Facebook.com
https://bugs.webkit.org/show_bug.cgi?id=119155
Reviewed by Andreas Kling.
Scope nodes are always objects, so we should be using SpecObjectOther
rather than SpecCellOther. Marking Scopes as CellOther leads to a
contradiction in the CFA, resulting in bogus codegen.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
2013-07-26 Oliver Hunt
REGRESSION(FTL?): Crashes in plugin tests
https://bugs.webkit.org/show_bug.cgi?id=119141
Reviewed by Michael Saboff.
Re-export getStackTrace
* interpreter/Interpreter.h:
2013-07-26 Filip Pizlo
REGRESSION: Crash when opening a message on Gmail
https://bugs.webkit.org/show_bug.cgi?id=119105
Reviewed by Oliver Hunt and Mark Hahnenberg.
- GetById patching in the DFG needs to be more disciplined about how it derives the
slow path.
- Fix some dumping code thread safety issues.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::dump):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* dfg/DFGRepatch.cpp:
(JSC::DFG::getPolymorphicStructureList):
(JSC::DFG::tryBuildGetByIDList):
2013-07-26 Balazs Kilvady
[mips] Fix LLINT build for mips backend
https://bugs.webkit.org/show_bug.cgi?id=119152
Reviewed by Oliver Hunt.
* offlineasm/mips.rb:
2013-07-19 Mark Hahnenberg
Setting a large numeric property on an object causes it to allocate a huge backing store
https://bugs.webkit.org/show_bug.cgi?id=118914
Reviewed by Geoffrey Garen.
There are two distinct actions that we're trying to optimize for:
new Array(100000);
and:
a = [];
a[100000] = 42;
In the first case, the programmer has indicated that they expect this Array to be very big,
so they should get a contiguous array up until some threshold, above which we perform density
calculations to see if it is indeed dense enough to warrant being contiguous.
In the second case, the programmer hasn't indicated anything about the size of the Array, so
we should be more conservative and assume it should be sparse until we've proven otherwise.
Currently both of those cases are handled by MIN_SPARSE_ARRAY_INDEX. We should distinguish
between them for the purposes of not over-allocating large backing stores like we see on
http://www.peekanalytics.com/burgerjoints/
The way that we'll do this is to keep the MIN_SPARSE_ARRAY_INDEX for the first case, and
introduce a new heuristic for the second case. If we are putting to an index above a certain
threshold (say, 1000) and it is beyond the length of the array, then we will use a sparse
map instead. So for example, in the second case above the empty array has a blank indexing
type and a length of 0. We put-by-val to an index > 1000 and > a.length, so we'll use a sparse map.
This fix is ~800x speedup on the accompanying regression test :-o
* runtime/ArrayConventions.h:
(JSC::indexIsSufficientlyBeyondLengthForSparseMap):
* runtime/JSObject.cpp:
(JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putByIndexBeyondVectorLength):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
2013-07-26 Julien Brianceau
REGRESSION(FTL): Fix lots of crashes in sh4 baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=119148
Reviewed by Csaba Osztrogonác.
* jit/JSInterfaceJIT.h: "secondArgumentRegister" is wrong for sh4.
* llint/LowLevelInterpreter32_64.asm: "move t0, a0" is missing
in nativeCallTrampoline for sh4. Reuse MIPS implementation to avoid
code duplication.
2013-07-26 Julien Brianceau
REGRESSION(FTL): Crash in sh4 baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=119138
Reviewed by Csaba Osztrogonác.
This crash is due to incomplete report of r150146 and r148474.
* jit/JITStubsSH4.h:
2013-07-26 Zan Dobersek
Unreviewed.
* Target.pri: Adding missing DFG files to the Qt build.
2013-07-25 Csaba Osztrogonác
GTK and Qt buildfix after the intrusive win buildfix r153360.
* GNUmakefile.list.am:
* Target.pri:
2013-07-25 Gyuyoung Kim
Unreviewed, fix build break after r153360.
* CMakeLists.txt: Add CommonSlowPathsExceptions.cpp.
2013-07-25 Roger Fong
Unreviewed build fix, AppleWin port.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.vcxproj/copy-files.cmd:
2013-07-25 Roger Fong
Unreviewed. Followup to r153360.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2013-07-25 Michael Saboff
[Windows] Speculative build fix.
Moved interpreterThrowInCaller() out of LLintExceptions.cpp into new CommonSlowPathsExceptions.cpp
that is always compiled. Made LLInt::returnToThrow() conditional on LLINT being enabled.
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntExceptions.cpp:
* llint/LLIntExceptions.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPathsExceptions.cpp: Added.
(JSC::CommonSlowPaths::interpreterThrowInCaller):
* runtime/CommonSlowPathsExceptions.h: Added.
2013-07-25 Brent Fulgham
[Windows] Unreviewed build fix.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add missing IntendedStructureChange.h,.cpp and
parser/SourceCode.h,.cpp.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
2013-07-25 Anders Carlsson
ASSERT(m_vm->apiLock().currentThreadIsHoldingLock()); fails for Safari on current ToT
https://bugs.webkit.org/show_bug.cgi?id=119108
Reviewed by Mark Hahnenberg.
Add a currentThreadIsHoldingAPILock() function to VM that checks if the current thread is the exclusive API thread.
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::tryAllocateSlowCase):
* heap/Heap.cpp:
(JSC::Heap::protect):
(JSC::Heap::unprotect):
(JSC::Heap::collect):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCase):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/VM.h:
(JSC::VM::currentThreadIsHoldingAPILock):
2013-07-25 Zan Dobersek
REGRESSION(FTL): Most layout tests crashes
https://bugs.webkit.org/show_bug.cgi?id=119089
Reviewed by Oliver Hunt.
* runtime/ExecutionHarness.h:
(JSC::prepareForExecution): Move prepareForExecutionImpl call into its own statement. This prevents the GCC-compiled
code to create the PassOwnPtr<:jitcode> (intended as a parameter to the installOptimizedCode call) from the jitCode
RefPtr<:jitcode> parameter before the latter was actually given a proper value through the prepareForExecutionImpl call.
Currently it's created beforehand and therefor holds a null pointer before it's anchored as the JIT code in
JSC::CodeBlock::setJITCode, which later indirectly causes assertions in JSC::CodeBlock::jitCompile.
(JSC::prepareFunctionForExecution): Ditto for prepareFunctionForExecutionImpl.
2013-07-25 Brent Fulgham
[Windows] Unreviewed build fix.
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Add missing 'ftl'
include path.
2013-07-25 Brent Fulgham
[Windows] Unreviewed build fix.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add some missing files:
runtime/VM.h,.cpp; Remove deleted JSGlobalData.h,.cpp.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
2013-07-25 Oliver Hunt
Make all jit & non-jit combos build cleanly
https://bugs.webkit.org/show_bug.cgi?id=119102
Reviewed by Anders Carlsson.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::counterValueForOptimizeSoon):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::optimizeAfterWarmUp):
(JSC::CodeBlock::numberOfDFGCompiles):
2013-07-25 Oliver Hunt
32 bit portion of load validation logic
https://bugs.webkit.org/show_bug.cgi?id=118878
Reviewed by NOBODY (Build fix).
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2013-07-25 Oliver Hunt
More 32bit build fixes
- Apparnetly some compilers don't track the fastcall directive everywhere we expect
* API/APICallbackFunction.h:
(JSC::APICallbackFunction::call):
* bytecode/CodeBlock.cpp:
* runtime/Structure.cpp:
2013-07-25 Yi Shen
Optimize the thread locks for API Shims
https://bugs.webkit.org/show_bug.cgi?id=118573
Reviewed by Geoffrey Garen.
Remove the thread lock from API Shims if the VM has an exclusive thread (e.g. the VM
only used by WebCore's main thread).
* API/APIShims.h:
(JSC::APIEntryShim::APIEntryShim):
(JSC::APICallbackShim::APICallbackShim):
* runtime/JSLock.cpp:
(JSC::JSLockHolder::JSLockHolder):
(JSC::JSLockHolder::init):
(JSC::JSLockHolder::~JSLockHolder):
(JSC::JSLock::DropAllLocks::DropAllLocks):
(JSC::JSLock::DropAllLocks::~DropAllLocks):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2013-07-25 Christophe Dumez
Unreviewed build fix after r153218.
Broke the EFL port build with gcc 4.7.
* interpreter/StackIterator.cpp:
(JSC::printif):
2013-07-25 Julien Brianceau
Build fix: add missing #include.
https://bugs.webkit.org/show_bug.cgi?id=119087
Reviewed by Allan Sandfeld Jensen.
* bytecode/ArrayProfile.cpp:
2013-07-25 Ryuan Choi
Unreviewed, build fix on the EFL port.
* CMakeLists.txt: Added JSCTestRunnerUtils.cpp.
2013-07-25 Julien Brianceau
[sh4] Add missing store8(TrustedImm32, void*) implementation in baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=119083
Reviewed by Allan Sandfeld Jensen.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::store8):
2013-07-25 Allan Sandfeld Jensen
[Qt] Fix test build after FTL upstream
Unreviewed build fix.
* Target.pri:
2013-07-25 Allan Sandfeld Jensen
[Qt] Build fix after FTL.
Un Reviewed build fix.
* Target.pri:
* interpreter/StackIterator.cpp:
(JSC::StackIterator::Frame::print):
2013-07-25 Gabor Rapcsanyi
Unreviewed build fix after FTL upstream.
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::~Worklist):
2013-07-25 Ryuan Choi
Unreviewed, build fix on the EFL port.
* CMakeLists.txt:
Added SourceCode.cpp and removed BlackBerry file.
* jit/JITCode.h:
(JSC::JITCode::nextTierJIT):
Fixed to build break because of -Werror=return-type
* parser/Lexer.cpp: Includes JSFunctionInlines.h
* runtime/JSScope.h:
(JSC::makeType):
Fixed to build break because of -Werror=return-type
2013-07-25 Ãdám Kallai
Unreviewed build fixing after FTL upstream.
* runtime/Executable.cpp:
(JSC::FunctionExecutable::produceCodeBlockFor):
2013-07-25 Julien Brianceau
Add missing implementation of bxxxnz in sh4 LLINT.
https://bugs.webkit.org/show_bug.cgi?id=119079
Reviewed by Allan Sandfeld Jensen.
* offlineasm/sh4.rb:
2013-07-25 Gabor Rapcsanyi
Unreviewed, build fix on the Qt port.
* Target.pri: Add additional build files for the FTL.
2013-07-25 Ãdám Kallai
Unreviewed buildfix after FTL upstream..
* interpreter/StackIterator.cpp:
(JSC::StackIterator::Frame::codeType):
(JSC::StackIterator::Frame::functionName):
(JSC::StackIterator::Frame::sourceURL):
(JSC::StackIterator::Frame::logicalFrame):
2013-07-25 Zan Dobersek
Unreviewed.
* heap/CopyVisitor.cpp: Include CopiedSpaceInlines header so the CopiedSpace::recycleEvacuatedBlock
method is not left undefined, causing build failures on (at least) the GTK port.
2013-07-25 Zan Dobersek
Unreviewed, further build fixing on the GTK port.
* GNUmakefile.list.am: Add CompilationResult source files to the build.
2013-07-25 Zan Dobersek
Unreviewed GTK build fixing.
* GNUmakefile.am: Make the shared libjsc library depend on any changes to the build target list.
* GNUmakefile.list.am: Add additional build targets for files that were introduced by the FTL branch merge.
2013-07-25 Csaba Osztrogonác
Buildfix after this error:
error: 'pathName' may be used uninitialized in this function [-Werror=uninitialized]
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
2013-07-25 Csaba Osztrogonác
One more buildfix after FTL upstream.
Return a dummy value after RELEASE_ASSERT_NOT_REACHED() to make GCC happy.
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::getValue):
(JSC::DFG::LazyJSValue::strictEqual):
2013-07-25 Julien Brianceau
Fix "Unhandled opcode localAnnotation" build error in sh4 and mips LLINT.
https://bugs.webkit.org/show_bug.cgi?id=119076
Reviewed by Allan Sandfeld Jensen.
* offlineasm/mips.rb:
* offlineasm/sh4.rb:
2013-07-25 Zan Dobersek
Unreviewed GTK build fix.
* GNUmakefile.list.am: Adding JSCTestRunnerUtils files to the build.
2013-07-25 Zan Dobersek
Unreviewed. Further build fixing for the GTK port. Adding the forwarding header
for JSCTestRunnerUtils.h as required by the DumpRenderTree compilation.
* ForwardingHeaders/JavaScriptCore/JSCTestRunnerUtils.h: Added.
2013-07-25 Zan Dobersek
Unreviewed. Fixing the GTK build after the FTL merging by updating the build targets list.
* GNUmakefile.am:
* GNUmakefile.list.am:
2013-07-25 Ãdám Kallai
Unreviewed buildfix after FTL upstream.
* runtime/JSScope.h:
(JSC::needsVarInjectionChecks):
2013-07-25 Csaba Osztrogonác
One more fix after FTL upstream.
* Target.pri:
* bytecode/CodeBlock.h:
* bytecode/GetByIdStatus.h:
(JSC::GetByIdStatus::GetByIdStatus):
2013-07-24 Csaba Osztrogonác
Unreviewed buildfix after FTL upstream.
Add ftl directory as include path.
* CMakeLists.txt:
* JavaScriptCore.pri:
2013-07-24 Csaba Osztrogonác
Unreviewed buildfix after FTL upstream for non C++11 builds.
* interpreter/CallFrame.h:
* interpreter/StackIteratorPrivate.h:
(JSC::StackIterator::end):
2013-07-24 Oliver Hunt
Endeavour to fix CMakelist builds
* CMakeLists.txt:
2013-07-24 Filip Pizlo
fourthTier: DFG IR dumps should be easier to read
https://bugs.webkit.org/show_bug.cgi?id=119050
Reviewed by Mark Hahnenberg.
Added a DumpContext that includes support for printing an endnote
that describes all structures in full, while the main flow of the
dump just uses made-up names for the structures. This is helpful
since Structure::dump() may print a lot. The stuff it prints is
useful, but if it's all inline with the surrounding thing you're
dumping (often, a node in the DFG), then you get a ridiculously
long print-out. All classes that dump structures (including
Structure itself) now have dumpInContext() methods that use
inContext() for dumping anything that might transitively print a
structure. If Structure::dumpInContext() is called with a NULL
context, it just uses dump() like before. Hence you don't have to
know anything about DumpContext unless you want to.
inContext(*structure, context) dumps something like %B4:Array,
and the endnote will have something like:
%B4:Array = 0x10e91a180:[Array, {Edge:100, Normal:101, Line:102, NumPx:103, LastPx:104}, ArrayWithContiguous, Proto:0x10e99ffe0]
where B4 is the inferred name that StringHashDumpContext came up
with.
Also shortened a bunch of other dumps, removing information that
isn't so important.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ArrayProfile.cpp:
(JSC::dumpArrayModes):
* bytecode/CodeBlockHash.cpp:
(JSC):
(JSC::CodeBlockHash::CodeBlockHash):
(JSC::CodeBlockHash::dump):
* bytecode/CodeOrigin.cpp:
(JSC::CodeOrigin::dumpInContext):
(JSC):
(JSC::InlineCallFrame::dumpInContext):
(JSC::InlineCallFrame::dump):
* bytecode/CodeOrigin.h:
(CodeOrigin):
(InlineCallFrame):
* bytecode/Operands.h:
(JSC::OperandValueTraits::isEmptyForDump):
(Operands):
(JSC::Operands::dump):
(JSC):
* bytecode/OperandsInlines.h: Added.
(JSC):
(JSC::::dumpInContext):
* bytecode/StructureSet.h:
(JSC::StructureSet::dumpInContext):
(JSC::StructureSet::dump):
(StructureSet):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::dump):
(DFG):
(JSC::DFG::AbstractValue::dumpInContext):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::operator!):
(AbstractValue):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::performBlockCFA):
* dfg/DFGCommon.cpp:
* dfg/DFGCommon.h:
(JSC::DFG::NodePointerTraits::isEmptyForDump):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::createDumpList):
* dfg/DFGDisassembler.h:
(Disassembler):
* dfg/DFGFlushFormat.h:
(WTF::inContext):
(WTF):
* dfg/DFGFlushLivenessAnalysisPhase.cpp:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dumpCodeOrigin):
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::dumpBlockHeader):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::dumpInContext):
(JSC::DFG::LazyJSValue::dump):
(DFG):
* dfg/DFGLazyJSValue.h:
(LazyJSValue):
* dfg/DFGNode.h:
(JSC::DFG::nodeMapDump):
(WTF::inContext):
(WTF):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::dumpInContext):
(JSC::DFG::StructureAbstractValue::dump):
(StructureAbstractValue):
* ftl/FTLExitValue.cpp:
(JSC::FTL::ExitValue::dumpInContext):
(JSC::FTL::ExitValue::dump):
(FTL):
* ftl/FTLExitValue.h:
(ExitValue):
* ftl/FTLLowerDFGToLLVM.cpp:
* ftl/FTLValueSource.cpp:
(JSC::FTL::ValueSource::dumpInContext):
(FTL):
* ftl/FTLValueSource.h:
(ValueSource):
* runtime/DumpContext.cpp: Added.
(JSC):
(JSC::DumpContext::DumpContext):
(JSC::DumpContext::~DumpContext):
(JSC::DumpContext::isEmpty):
(JSC::DumpContext::dump):
* runtime/DumpContext.h: Added.
(JSC):
(DumpContext):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dump):
(JSC):
(JSC::JSValue::dumpInContext):
* runtime/JSCJSValue.h:
(JSC):
(JSValue):
* runtime/Structure.cpp:
(JSC::Structure::dumpInContext):
(JSC):
(JSC::Structure::dumpBrief):
(JSC::Structure::dumpContextHeader):
* runtime/Structure.h:
(JSC):
(Structure):
2013-07-22 Filip Pizlo
fourthTier: DFG should do a high-level LICM before going to FTL
https://bugs.webkit.org/show_bug.cgi?id=118749
Reviewed by Oliver Hunt.
Implements LICM hoisting for nodes that never write anything and never read
things that are clobbered by the loop. There are some other preconditions for
hoisting, see DFGLICMPhase.cpp.
Also did a few fixes:
- ClobberSet::add was failing to switch Super entries to Direct entries in
some cases.
- DFGClobberize.cpp needed to #include "Operations.h".
- DCEPhase needs to process the graph in reverse DFS order, when we're in SSA.
- AbstractInterpreter can now execute a Node without knowing its indexInBlock.
Knowing the indexInBlock is an optional optimization that all other clients
of AI still opt into, but LICM doesn't.
This makes the FTL a 2.19x speed-up on imaging-gaussian-blur.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreter.h:
(AbstractInterpreter):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
(JSC::DFG::::execute):
(DFG):
(JSC::DFG::::clobberWorld):
(JSC::DFG::::clobberStructures):
* dfg/DFGAtTailAbstractState.cpp: Added.
(DFG):
(JSC::DFG::AtTailAbstractState::AtTailAbstractState):
(JSC::DFG::AtTailAbstractState::~AtTailAbstractState):
(JSC::DFG::AtTailAbstractState::createValueForNode):
(JSC::DFG::AtTailAbstractState::forNode):
* dfg/DFGAtTailAbstractState.h: Added.
(DFG):
(AtTailAbstractState):
(JSC::DFG::AtTailAbstractState::initializeTo):
(JSC::DFG::AtTailAbstractState::forNode):
(JSC::DFG::AtTailAbstractState::variables):
(JSC::DFG::AtTailAbstractState::block):
(JSC::DFG::AtTailAbstractState::isValid):
(JSC::DFG::AtTailAbstractState::setDidClobber):
(JSC::DFG::AtTailAbstractState::setIsValid):
(JSC::DFG::AtTailAbstractState::setBranchDirection):
(JSC::DFG::AtTailAbstractState::setFoundConstants):
(JSC::DFG::AtTailAbstractState::haveStructures):
(JSC::DFG::AtTailAbstractState::setHaveStructures):
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::insertBeforeLast):
* dfg/DFGBasicBlockInlines.h:
(DFG):
* dfg/DFGClobberSet.cpp:
(JSC::DFG::ClobberSet::add):
(JSC::DFG::ClobberSet::addAll):
* dfg/DFGClobberize.cpp:
(JSC::DFG::doesWrites):
* dfg/DFGClobberize.h:
(DFG):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::DCEPhase):
(JSC::DFG::DCEPhase::run):
(JSC::DFG::DCEPhase::fixupBlock):
(DCEPhase):
* dfg/DFGEdgeDominates.h: Added.
(DFG):
(EdgeDominates):
(JSC::DFG::EdgeDominates::EdgeDominates):
(JSC::DFG::EdgeDominates::operator()):
(JSC::DFG::EdgeDominates::result):
(JSC::DFG::edgesDominate):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::checkArray):
* dfg/DFGLICMPhase.cpp: Added.
(LICMPhase):
(JSC::DFG::LICMPhase::LICMPhase):
(JSC::DFG::LICMPhase::run):
(JSC::DFG::LICMPhase::attemptHoist):
(DFG):
(JSC::DFG::performLICM):
* dfg/DFGLICMPhase.h: Added.
(DFG):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
2013-07-21 Filip Pizlo
fourthTier: DFG Nodes should be able to abstractly tell you what they read and what they write
https://bugs.webkit.org/show_bug.cgi?id=118910
Reviewed by Sam Weinig.
Add the notion of AbstractHeap to the DFG. This is analogous to the AbstractHeap in
the FTL, except that the FTL's AbstractHeaps are used during LLVM lowering and are
engineered to obey LLVM TBAA logic. The FTL's AbstractHeaps are also engineered to
be inexpensive to use (they just give you a TBAA node) but expensive to create (you
create them all up front). FTL AbstractHeaps also don't actually give you the
ability to reason about aliasing; they are *just* a mechanism for lowering to TBAA.
The DFG's AbstractHeaps are engineered to be both cheap to create and cheap to use.
They also give you aliasing machinery. The DFG AbstractHeaps are represented
internally by a int64_t. Many comparisons between them are just integer comaprisons.
AbstractHeaps form a three-level hierarchy (World is the supertype of everything,
Kind with a TOP payload is a direct subtype of World, and Kind with a non-TOP
payload is the direct subtype of its corresponding TOP Kind).
Add the notion of a ClobberSet. This is the set of AbstractHeaps that you had
clobbered. It represents the set that results from unifying a bunch of
AbstractHeaps, and is intended to quickly answer overlap questions: does the given
AbstractHeap overlap any AbstractHeap in the ClobberSet? To this end, if you add an
AbstractHeap to a set, it "directly" adds the heap itself, and "super" adds all of
its ancestors. An AbstractHeap is said to overlap a set if any direct or super
member is equal to it, or if any of its ancestors are equal to a direct member.
Example #1:
- I add Variables(5). I.e. Variables is the Kind and 5 is the payload. This
is a subtype of Variables, which is a subtype of World.
- You query Variables. I.e. Variables with a TOP payload, which is the
supertype of Variables(X) for any X, and a subtype of World.
The set will have Variables(5) as a direct member, and Variables and World as
super members. The Variables query will immediately return true, because
Variables is indeed a super member.
Example #2:
- I add Variables(5)
- You query NamedProperties
NamedProperties is not a member at all (neither direct or super). We next
query World. World is a member, but it's a super member, so we return false.
Example #3:
- I add Variables
- You query Variables(5)
The set will have Variables as a direct member, and World as a super member.
The Variables(5) query will not find Variables(5) in the set, but then it
will query Variables. Variables is a direct member, so we return true.
Example #4:
- I add Variables
- You query NamedProperties(5)
Neither NamedProperties nor NamedProperties(5) are members. We next query
World. World is a member, but it's a super member, so we return false.
Overlap queries require that either the heap being queried is in the set (either
direct or super), or that one of its ancestors is a direct member. Another way to
think about how this works is that two heaps A and B are said to overlap if
A.isSubtypeOf(B) or B.isSubtypeOf(A). This is sound since heaps form a
single-inheritance heirarchy. Consider that we wanted to implement a set that holds
heaps and answers the question, "is any member in the set an ancestor (i.e.
supertype) of some other heap". We would have the set contain the heaps themselves,
and we would satisfy the query "A.isSubtypeOfAny(set)" by walking the ancestor
chain of A, and repeatedly querying its membership in the set. This is what the
"direct" members of our set do. Now consider the other part, where we want to ask if
any member of the set is a descendent of a heap, or "A.isSupertypeOfAny(set)". We
would implement this by implementing set.add(B) as adding not just B but also all of
B's ancestors; then we would answer A.isSupertypeOfAny(set) by just checking if A is
in the set. With two such sets - one that answers isSubtypeOfAny() and another that
answers isSupertypeOfAny() - we could answer the "do any of my heaps overlap your
heap" question. ClobberSet does this, but combines the two sets into a single
HashMap. The HashMap's value, "direct", means that the key is a member of both the
supertype set and the subtype set; if it's false then it's only a member of one of
them.
Finally, this adds a functorized clobberize() method that adds the read and write
clobbers of a DFG::Node to read and write functors. Common functors for adding to
ClobberSets, querying overlap, and doing nothing are provided. Convenient wrappers
are also provided. This allows you to say things like:
ClobberSet set;
addWrites(graph, node1, set);
if (readsOverlap(graph, node2, set))
// We know that node1 may write to something that node2 may read from.
Currently this facility is only used to improve graph dumping, but it will be
instrumental in both LICM and GVN. In the future, I want to completely kill the
NodeClobbersWorld and NodeMightClobber flags, and eradicate CSEPhase's hackish way
of accomplishing almost exactly what AbstractHeap gives you.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractHeap.cpp: Added.
(DFG):
(JSC::DFG::AbstractHeap::Payload::dump):
(JSC::DFG::AbstractHeap::dump):
(WTF):
(WTF::printInternal):
* dfg/DFGAbstractHeap.h: Added.
(DFG):
(AbstractHeap):
(Payload):
(JSC::DFG::AbstractHeap::Payload::Payload):
(JSC::DFG::AbstractHeap::Payload::top):
(JSC::DFG::AbstractHeap::Payload::isTop):
(JSC::DFG::AbstractHeap::Payload::value):
(JSC::DFG::AbstractHeap::Payload::valueImpl):
(JSC::DFG::AbstractHeap::Payload::operator==):
(JSC::DFG::AbstractHeap::Payload::operator!=):
(JSC::DFG::AbstractHeap::Payload::operator
fourthTier: It should be easy to figure out which blocks nodes belong to
https://bugs.webkit.org/show_bug.cgi?id=118957
Reviewed by Sam Weinig.
* dfg/DFGGraph.cpp:
(DFG):
(JSC::DFG::Graph::initializeNodeOwners):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGNode.h:
2013-07-21 Filip Pizlo
fourthTier: NodeExitsForward shouldn't be duplicated in NodeType
https://bugs.webkit.org/show_bug.cgi?id=118956
Reviewed by Sam Weinig.
We had two way of expressing that something exits forward: the NodeExitsForward
flag and the word 'Forward' in the NodeType. That's kind of dumb. This patch
makes it just be a flag.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::int32ToDoubleCSE):
(JSC::DFG::CSEPhase::checkStructureElimination):
(JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
(JSC::DFG::CSEPhase::putStructureStoreElimination):
(JSC::DFG::CSEPhase::checkArrayElimination):
(JSC::DFG::CSEPhase::performNodeCSE):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
* dfg/DFGMinifiedNode.h:
(JSC::DFG::belongsInMinifiedGraph):
(JSC::DFG::MinifiedNode::hasChild):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToStructureTransitionWatchpoint):
(JSC::DFG::Node::hasStructureSet):
(JSC::DFG::Node::hasStructure):
(JSC::DFG::Node::hasArrayMode):
(JSC::DFG::Node::willHaveCodeGenOrOSR):
* dfg/DFGNodeType.h:
(DFG):
(JSC::DFG::needsOSRForwardRewiring):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
2013-07-21 Filip Pizlo
fourthTier: It should be possible for a DFG::Node to claim to exit to one CodeOrigin, but then claim that it belongs to a different CodeOrigin for all other purposes
https://bugs.webkit.org/show_bug.cgi?id=118946
Reviewed by Geoffrey Garen.
We want to decouple the exit target code origin of a node from the code origin
for all other purposes. The purposes of code origins are:
- Where the node will exit, if it exits. The exit target should be consistent with
the surrounding nodes, in that if you just looked at the code origins of nodes in
the graph, they would be consistent with the code origins in bytecode. This is
necessary for live-at-bytecode analyses to work, and to preserve the original
bytecode semantics when exiting.
- What kind of code the node came from, for semantics thingies. For example, we
might use the code origin to find the node's global object for doing an original
array check. Or we might use it to determine if the code is in strict mode. Or
other similar things. When we use the code origin in this way, we're basically
using it as a way of describing the node's meta-data without putting it into the
node directly, to save space. In the absurd extreme you could imagine nodes not
even having NodeTypes or NodeFlags, and just using the CodeOrigin to determine
what bytecode the node originated from. We won't do that, but you can think of
this use of code origins as just a way of compressing meta-data.
- What code origin we should supply profiling to, if we exit. This is closely
related to the semantics thingies, in that the exit profiling is a persistent
kind of semantic meta-data that survives between recompiles, and the only way to
do that is to ascribe it to the original bytecode via the code origin.
If we hoist a node, we need to change the exit target code origin, but we must not
change the code origin for other purposes. The best way to do this is to decouple
the two kinds of code origin.
OSR exit data structures already do this, because they may edit the exit target
code origin while keeping the code origin for profiling intact. This happens for
forward exits. So, we just need to thread separation all the way back to DFG::Node.
That's what this patch does.
* dfg/DFGNode.h:
(JSC::DFG::Node::Node):
(Node):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::OSRExitBase):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::appendOSRExit):
(LowerDFGToLLVM):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExit::OSRExit):
* ftl/FTLOSRExit.h:
(OSRExit):
2013-07-20 Filip Pizlo
fourthTier: each DFG node that relies on other nodes to do their type checks should be able to tell you if those type checks happened
https://bugs.webkit.org/show_bug.cgi?id=118866
Reviewed by Sam Weinig.
Adds a safeToExecute() method that takes a node and an abstract state and tells you
if the node will run without crashing under that state.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* dfg/DFGCFAPhase.cpp:
(CFAPhase):
(JSC::DFG::CFAPhase::CFAPhase):
(JSC::DFG::CFAPhase::run):
(JSC::DFG::CFAPhase::performBlockCFA):
(JSC::DFG::CFAPhase::performForwardCFA):
* dfg/DFGSafeToExecute.h: Added.
(DFG):
(SafeToExecuteEdge):
(JSC::DFG::SafeToExecuteEdge::SafeToExecuteEdge):
(JSC::DFG::SafeToExecuteEdge::operator()):
(JSC::DFG::SafeToExecuteEdge::result):
(JSC::DFG::safeToExecute):
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::isValidOffset):
(StructureAbstractValue):
* runtime/Options.h:
(JSC):
2013-07-20 Filip Pizlo
fourthTier: FTL should be able to generate LLVM IR that uses an intrinsic for OSR exit
https://bugs.webkit.org/show_bug.cgi?id=118948
Reviewed by Sam Weinig.
- Add the ability to generate LLVM IR but then not use it, via --llvmAlwaysFails=true.
This allows doing "what if" experiments with IR generation, even if the generated IR
can't yet execute.
- Add an OSR exit path that just calls an intrinsic that combines the branch and the
off-ramp.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* ftl/FTLFail.cpp: Added.
(FTL):
(JSC::FTL::fail):
* ftl/FTLFail.h: Added.
(FTL):
* ftl/FTLIntrinsicRepository.h:
(FTL):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
* runtime/Options.h:
(JSC):
2013-07-19 Filip Pizlo
fourthTier: StringObjectUse uses structures, and CSE should know that
https://bugs.webkit.org/show_bug.cgi?id=118940
Reviewed by Geoffrey Garen.
This is asymptomatic right now, but we should fix it.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::putStructureStoreElimination):
* dfg/DFGEdgeUsesStructure.h: Added.
(DFG):
(EdgeUsesStructure):
(JSC::DFG::EdgeUsesStructure::EdgeUsesStructure):
(JSC::DFG::EdgeUsesStructure::operator()):
(JSC::DFG::EdgeUsesStructure::result):
(JSC::DFG::edgesUseStructure):
* dfg/DFGUseKind.h:
(DFG):
(JSC::DFG::usesStructure):
2013-07-19 Filip Pizlo
fourthTier: String GetByVal out-of-bounds handling is so wrong
https://bugs.webkit.org/show_bug.cgi?id=118935
Reviewed by Geoffrey Garen.
Bunch of String GetByVal out-of-bounds fixes:
- Even if the string proto chain is sane, we need to watch out for negative
indices. They may get values or call getters in the prototypes, since proto
sanity doesn't check for negative indexed properties, as they are not
technically indexed properties.
- GetByVal String out-of-bounds does in fact clobberWorld(). CSE should be
given this information.
- GetByVal String out-of-bounds does in fact clobberWorld(). CFA should be
given this information.
Also fixed some other things:
- If the DFG is disabled, the testRunner should pretend that we've done a
bunch of DFG compiles. That's necessary to prevent the tests from timing
out.
- Disassembler shouldn't try to dump source code since it's not safe in the
concurrent JIT.
* API/JSCTestRunnerUtils.cpp:
(JSC::numberOfDFGCompiles):
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::dumpHeader):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::byValIsPure):
* dfg/DFGSaneStringGetByValSlowPathGenerator.h: Added.
(DFG):
(SaneStringGetByValSlowPathGenerator):
(JSC::DFG::SaneStringGetByValSlowPathGenerator::SaneStringGetByValSlowPathGenerator):
(JSC::DFG::SaneStringGetByValSlowPathGenerator::generateInternal):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
2013-07-19 Filip Pizlo
fourthTier: Structure::isValidOffset() should be able to tell you if you're loading a valid JSValue, and not just not crashing
https://bugs.webkit.org/show_bug.cgi?id=118911
Reviewed by Geoffrey Garen.
We could also have a separate method like "willNotCrash(offset)", but that's not
what isValidOffset() is intended to mean.
* runtime/Structure.h:
(JSC::Structure::isValidOffset):
2013-07-19 Filip Pizlo
fourthTier: Structure should be able to tell you if it's valid to load at a given offset from any object with that structure
https://bugs.webkit.org/show_bug.cgi?id=118878
Reviewed by Oliver Hunt.
- Change Structure::isValidOffset() to actually answer the question "If I attempted
to load from an object of this structure, at this offset, would I commit suicide
or would I get back some kind of value?"
- Change StorageAccessData::offset to use a PropertyOffset. It should have been that
way from the start.
- Fix PutStructure so that it sets haveStructures in all of the cases that it should.
- Make GetByOffset also reference the base object in addition to the butterfly.
The future use of this power will be to answer questions like "If I hoisted this
GetByOffset or PutByOffset to this point, would it cause crashes, or would it be
fine?"
I don't currently plan to use this power to perform validation, since the CSE has
the power to eliminate CheckStructure's that the CFA wouldn't be smart enough to
remove - both in the case of StructureSets where size >= 2 and in the case of
CheckStructures that match across PutStructures. At first I tried to write a
validator that was aware of this, but the validation code got way too complicated
and I started having nightmares of spurious assertion bugs being filed against me.
This also changes some of the code for how we hash FunctionExecutable's for debug
dumps, since that code still had some thread-safety issues. Basically, the
concurrent JIT needs to use the CodeBlock's precomputed hash and never call anything
that could transitively try to compute the hash from the source code. The source
code is a string that may be lazily computed, and that involves all manner of thread
unsafe things.
* bytecode/CodeOrigin.cpp:
(JSC::InlineCallFrame::hash):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetByOffset):
(JSC::DFG::ByteCodeParser::handlePutByOffset):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::performBlockCFA):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(StorageAccessData):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToGetByOffset):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
(JSC::FTL::LowerDFGToLLVM::compilePutByOffset):
* runtime/FunctionExecutableDump.cpp:
(JSC::FunctionExecutableDump::dump):
* runtime/Structure.h:
(Structure):
(JSC::Structure::isValidOffset):
2013-07-18 Filip Pizlo
fourthTier: AbstractInterpreter should explicitly ask AbstractState to create new AbstractValues for newly born nodes
https://bugs.webkit.org/show_bug.cgi?id=118880
Reviewed by Sam Weinig.
It should be possible to have an AbstractState that is backed by a HashMap. But to
do this, the AbstractInterpreter should explicitly ask for new nodes to be added to
the map, since otherwise the idiom of getting a reference to the AbstractValue
returned by forNode() would cause really subtle memory corruption bugs.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGInPlaceAbstractState.h:
(JSC::DFG::InPlaceAbstractState::createValueForNode):
(InPlaceAbstractState):
2013-07-18 Filip Pizlo
fourthTier: Decouple the way that CFA stores its state from the way it does abstract interpretation
https://bugs.webkit.org/show_bug.cgi?id=118835
Reviewed by Oliver Hunt.
This separates AbstractState into two things:
- InPlaceAbstractState, which can tell you the abstract state of anything you
might care about, and uses the old AbstractState's algorithms and data
structures for doing so.
- AbstractInterpreter, which can execute a DFG::Node* with
respect to an AbstractStateType. Currently we always use
AbstractStateType = InPlaceAbstractState. But we could drop in an other
class that supports basic primitives like forNode() and variables().
This is important because:
- We want to hoist things out of loops.
- We don't know what things rely on what type checks.
- We only want to hoist type checks out of loops if they aren't clobbered.
- We may want to still hoist things that depended on those type checks, if it's
safe to do those things based on the CFA state at the tail of the loop
pre-header.
- We don't want things to rely on their type checks by way of a token, because
that's just weird.
So, we want to be able to have a special form of the CFA that can
incrementally update a basic block's state-at-tail, and we want to be able to
do this for multiple blocks simultaneously. This requires *not* storing the
per-node state in the nodes themselves, but instead using the at-tail HashMap
directly.
Hence we need to have a way of making the abstract interpreter (i.e.
AbstractState::execute) polymorphic with respect to state representation. Put
another way, we need to separate the way that abstract state is represented
from the way DFG IR is abstractly interpreted.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreter.h: Added.
(DFG):
(AbstractInterpreter):
(JSC::DFG::AbstractInterpreter::forNode):
(JSC::DFG::AbstractInterpreter::variables):
(JSC::DFG::AbstractInterpreter::needsTypeCheck):
(JSC::DFG::AbstractInterpreter::filterEdgeByUse):
(JSC::DFG::AbstractInterpreter::filter):
(JSC::DFG::AbstractInterpreter::filterArrayModes):
(JSC::DFG::AbstractInterpreter::filterByValue):
(JSC::DFG::AbstractInterpreter::trySetConstant):
(JSC::DFG::AbstractInterpreter::filterByType):
* dfg/DFGAbstractInterpreterInlines.h: Added.
(DFG):
(JSC::DFG::::AbstractInterpreter):
(JSC::DFG::::~AbstractInterpreter):
(JSC::DFG::::booleanResult):
(JSC::DFG::::startExecuting):
(JSC::DFG::::executeEdges):
(JSC::DFG::::verifyEdge):
(JSC::DFG::::verifyEdges):
(JSC::DFG::::executeEffects):
(JSC::DFG::::execute):
(JSC::DFG::::clobberWorld):
(JSC::DFG::::clobberCapturedVars):
(JSC::DFG::::clobberStructures):
(JSC::DFG::::dump):
(JSC::DFG::::filter):
(JSC::DFG::::filterArrayModes):
(JSC::DFG::::filterByValue):
* dfg/DFGAbstractState.cpp: Removed.
* dfg/DFGAbstractState.h: Removed.
* dfg/DFGArgumentsSimplificationPhase.cpp:
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::CFAPhase):
(JSC::DFG::CFAPhase::performBlockCFA):
(CFAPhase):
* dfg/DFGCFGSimplificationPhase.cpp:
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::ConstantFoldingPhase):
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(ConstantFoldingPhase):
* dfg/DFGInPlaceAbstractState.cpp: Added.
(DFG):
(JSC::DFG::InPlaceAbstractState::InPlaceAbstractState):
(JSC::DFG::InPlaceAbstractState::~InPlaceAbstractState):
(JSC::DFG::InPlaceAbstractState::beginBasicBlock):
(JSC::DFG::setLiveValues):
(JSC::DFG::InPlaceAbstractState::initialize):
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
(JSC::DFG::InPlaceAbstractState::reset):
(JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
(JSC::DFG::InPlaceAbstractState::merge):
(JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
(JSC::DFG::InPlaceAbstractState::mergeVariableBetweenBlocks):
* dfg/DFGInPlaceAbstractState.h: Added.
(DFG):
(InPlaceAbstractState):
(JSC::DFG::InPlaceAbstractState::forNode):
(JSC::DFG::InPlaceAbstractState::variables):
(JSC::DFG::InPlaceAbstractState::block):
(JSC::DFG::InPlaceAbstractState::didClobber):
(JSC::DFG::InPlaceAbstractState::isValid):
(JSC::DFG::InPlaceAbstractState::setDidClobber):
(JSC::DFG::InPlaceAbstractState::setIsValid):
(JSC::DFG::InPlaceAbstractState::setBranchDirection):
(JSC::DFG::InPlaceAbstractState::setFoundConstants):
(JSC::DFG::InPlaceAbstractState::haveStructures):
(JSC::DFG::InPlaceAbstractState::setHaveStructures):
* dfg/DFGMergeMode.h: Added.
(DFG):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::backwardTypeCheck):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::compileToStringOnCell):
(JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
(JSC::DFG::SpeculativeJIT::speculateStringObject):
(JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::needsTypeCheck):
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
* ftl/FTLLowerDFGToLLVM.cpp:
(FTL):
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::appendTypeCheck):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::speculateNumber):
(JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
(LowerDFGToLLVM):
2013-07-18 Filip Pizlo
fourthTier: DFG shouldn't create CheckStructures for array accesses except if the ArrayMode implies an original array access
https://bugs.webkit.org/show_bug.cgi?id=118867
Reviewed by Mark Hahnenberg.
This allows us to kill off a bunch of code in the parser, in fixup, and to simplify
ArrayProfile.
It also makes it easier to ask any array-using node how to create its type check.
Doing this required fixing a bug in LowLevelInterpreter64, where it was storing into
an array profile, thinking that it was storing into a value profile. Reshuffling the
fields in ArrayProfile revealed this.
* bytecode/ArrayProfile.cpp:
(JSC::ArrayProfile::computeUpdatedPrediction):
(JSC::ArrayProfile::briefDescriptionWithoutUpdating):
* bytecode/ArrayProfile.h:
(JSC::ArrayProfile::ArrayProfile):
(ArrayProfile):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::updateAllArrayPredictions):
(JSC::CodeBlock::updateAllPredictions):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::updateAllArrayPredictions):
* dfg/DFGArrayMode.h:
(ArrayMode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(FixupPhase):
(JSC::DFG::FixupPhase::checkArray):
(JSC::DFG::FixupPhase::blessArrayOperation):
* llint/LowLevelInterpreter64.asm:
2013-07-18 Filip Pizlo
fourthTier: CFA should consider live-at-head for clobbering and dumping
https://bugs.webkit.org/show_bug.cgi?id=118857
Reviewed by Mark Hahnenberg.
- clobberStructures() was not considering nodes live-at-head when in SSA
form. This means it would fail to clobber some structures.
- dump() was not considering nodes live-at-head when in SSA form. This
means it wouldn't dump everything that you might be interested in.
- AbstractState::m_currentNode is a useless variable and we should get
rid of it.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::AbstractState):
(JSC::DFG::AbstractState::beginBasicBlock):
(JSC::DFG::AbstractState::reset):
(JSC::DFG::AbstractState::startExecuting):
(JSC::DFG::AbstractState::clobberStructures):
(JSC::DFG::AbstractState::dump):
* dfg/DFGAbstractState.h:
(AbstractState):
2013-07-16 Filip Pizlo
fourthTier: Add a phase to create loop pre-headers
https://bugs.webkit.org/show_bug.cgi?id=118778
Reviewed by Oliver Hunt.
Add a loop pre-header creation phase. Any loop that doesn't already have
just one predecessor that isn't part of the loop has a pre-header
prepended. All non-loop predecessors then jump to that pre-header.
Also fix a handful of bugs:
- DFG::Analysis should set m_valid before running the analysis, since that
makes it easier to use ASSERT(m_valid) in the analysis' methods, which
may be called by the analysis before the analysis completes. NaturalLoops
does this with loopsOf().
- NaturalLoops::headerOf() was missing a check for innerMostLoopOf()
returning 0, since that'll happen if the block isn't in any loop.
- Change BlockInsertionSet to dethread the graph, since anyone using it
will want to do so.
- Change dethreading to ignore SSA form graphs.
This also adds NaturalLoops::belongsTo(), which I always used in the
pre-header creation phase. I didn't end up using it but I'll probably use
it in the near future.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAnalysis.h:
(JSC::DFG::Analysis::computeIfNecessary):
* dfg/DFGBlockInsertionSet.cpp:
(JSC::DFG::BlockInsertionSet::execute):
* dfg/DFGCriticalEdgeBreakingPhase.cpp:
(JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dethread):
* dfg/DFGLoopPreHeaderCreationPhase.cpp: Added.
(DFG):
(LoopPreHeaderCreationPhase):
(JSC::DFG::LoopPreHeaderCreationPhase::LoopPreHeaderCreationPhase):
(JSC::DFG::LoopPreHeaderCreationPhase::run):
(JSC::DFG::performLoopPreHeaderCreation):
* dfg/DFGLoopPreHeaderCreationPhase.h: Added.
(DFG):
* dfg/DFGNaturalLoops.h:
(NaturalLoop):
(JSC::DFG::NaturalLoops::headerOf):
(JSC::DFG::NaturalLoops::innerMostLoopOf):
(JSC::DFG::NaturalLoops::innerMostOuterLoop):
(JSC::DFG::NaturalLoops::belongsTo):
(NaturalLoops):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
2013-07-16 Filip Pizlo
fourthTier: Rationalize Node::replacement
https://bugs.webkit.org/show_bug.cgi?id=118774
Reviewed by Oliver Hunt.
- Clearing of replacements is now done in Graph::clearReplacements().
- New nodes now have replacement set to 0.
- Node::replacement is now part of a 'misc' union. I'll be putting at least
one other field into that union as part of LICM work (see
https://bugs.webkit.org/show_bug.cgi?id=118749).
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::run):
(JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
(JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::run):
(JSC::DFG::CSEPhase::setReplacement):
(JSC::DFG::CSEPhase::performBlockCSE):
* dfg/DFGGraph.cpp:
(DFG):
(JSC::DFG::Graph::clearReplacements):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::performSubstitutionForEdge):
(Graph):
* dfg/DFGNode.h:
(JSC::DFG::Node::Node):
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
2013-07-16 Filip Pizlo
fourthTier: NaturalLoops should be able to quickly answer questions like "what loops own this basic block"
https://bugs.webkit.org/show_bug.cgi?id=118750
Reviewed by Mark Hahnenberg.
* dfg/DFGBasicBlock.h:
(BasicBlock):
* dfg/DFGNaturalLoops.cpp:
(JSC::DFG::NaturalLoops::compute):
(JSC::DFG::NaturalLoops::loopsOf):
* dfg/DFGNaturalLoops.h:
(DFG):
(JSC::DFG::NaturalLoop::NaturalLoop):
(NaturalLoop):
(JSC::DFG::NaturalLoop::index):
(JSC::DFG::NaturalLoop::isOuterMostLoop):
(JSC::DFG::NaturalLoop::addBlock):
(JSC::DFG::NaturalLoops::headerOf):
(JSC::DFG::NaturalLoops::innerMostLoopOf):
(NaturalLoops):
(JSC::DFG::NaturalLoops::innerMostOuterLoop):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
2013-07-16 Filip Pizlo
fourthTier: don't GC when shutting down the VM
https://bugs.webkit.org/show_bug.cgi?id=118751
Reviewed by Mark Hahnenberg.
* heap/Heap.h:
(Heap):
* runtime/VM.cpp:
(JSC::VM::~VM):
2013-07-12 Filip Pizlo
fourthTier: DFG should have an SSA form for use by FTL
https://bugs.webkit.org/show_bug.cgi?id=118338
Reviewed by Mark Hahnenberg.
Adds an SSA form to the DFG. We can convert ThreadedCPS form into SSA form
after breaking critical edges. The conversion algorithm follows Aycock and
Horspool, and the SSA form itself follows something I've done before, where
instead of having Phi functions specify input nodes corresponding to block
predecessors, we instead have Upsilon functions in the predecessors that
specify which value in that block goes into which subsequent Phi. Upsilons
don't have to dominate Phis (usually they don't) and they correspond to a
non-SSA "mov" into the Phi's "variable". This gives all of the good
properties of SSA, while ensuring that a bunch of CFG transformations don't
have to be SSA-aware.
So far the only DFG phases that are SSA-aware are DCE and CFA. CFG
simplification is probably SSA-aware by default, though I haven't tried it.
Constant folding probably needs a few tweaks, but is likely ready. Ditto
for CSE, though it's not clear that we'd want to use block-local CSE when
we could be doing GVN.
Currently only the FTL can generate code from the SSA form, and there is no
way to convert from SSA to ThreadedCPS or LoadStore. There probably will
never be such a capability.
In order to handle OSR exit state in the SSA, we place MovHints at Phi
points. Other than that, you can reconstruct state-at-exit by forward
propagating MovHints. Note that MovHint is the new SetLocal in SSA.
SetLocal and GetLocal only survive into SSA if they are on captured
variables, or in the case of flushes. A "live SetLocal" will be
NodeMustGenerate and will always correspond to a flush. Computing the
state-at-exit requires running SSA liveness analysis, OSR availability
analysis, and flush liveness analysis. The FTL runs all of these prior to
generating code. While OSR exit continues to be tricky, much of the logic
is now factored into separate phases and the backend has to do less work
to reason about what happened outside of the basic block that is being
lowered.
Conversion from DFG SSA to LLVM SSA is done by ensuring that we generate
code in depth-first order, thus guaranteeing that a node will always be
lowered (and hence have a LValue) before any of the blocks dominated by
that node's block have code generated. For Upsilon/Phi, we just use
alloca's. We could do something more clever there, but it's probably not
worth it, at least not now.
Finally, while the SSA form is currently only being converted to LLVM IR,
there is nothing that prevents us from considering other backends in the
future - with the caveat that this form is designed to be first lowered to
a lower-level SSA before actual machine code generation commences. So we
ought to either use LLVM (the intended path) or we will have to write our
own SSA low-level backend.
This runs all of the code that the FTL was known to run previously. No
change in performance for now. But it does open some exciting
possibilities!
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/Operands.h:
(JSC::OperandValueTraits::dump):
(JSC::Operands::fill):
(Operands):
(JSC::Operands::clear):
(JSC::Operands::operator==):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::beginBasicBlock):
(JSC::DFG::setLiveValues):
(DFG):
(JSC::DFG::AbstractState::initialize):
(JSC::DFG::AbstractState::endBasicBlock):
(JSC::DFG::AbstractState::executeEffects):
(JSC::DFG::AbstractState::mergeStateAtTail):
(JSC::DFG::AbstractState::merge):
* dfg/DFGAbstractState.h:
(AbstractState):
* dfg/DFGAdjacencyList.h:
(JSC::DFG::AdjacencyList::justOneChild):
(AdjacencyList):
* dfg/DFGBasicBlock.cpp: Added.
(DFG):
(JSC::DFG::BasicBlock::BasicBlock):
(JSC::DFG::BasicBlock::~BasicBlock):
(JSC::DFG::BasicBlock::ensureLocals):
(JSC::DFG::BasicBlock::isInPhis):
(JSC::DFG::BasicBlock::isInBlock):
(JSC::DFG::BasicBlock::removePredecessor):
(JSC::DFG::BasicBlock::replacePredecessor):
(JSC::DFG::BasicBlock::dump):
(JSC::DFG::BasicBlock::SSAData::SSAData):
(JSC::DFG::BasicBlock::SSAData::~SSAData):
* dfg/DFGBasicBlock.h:
(BasicBlock):
(JSC::DFG::BasicBlock::operator[]):
(JSC::DFG::BasicBlock::successor):
(JSC::DFG::BasicBlock::successorForCondition):
(SSAData):
* dfg/DFGBasicBlockInlines.h:
(DFG):
* dfg/DFGBlockInsertionSet.cpp: Added.
(DFG):
(JSC::DFG::BlockInsertionSet::BlockInsertionSet):
(JSC::DFG::BlockInsertionSet::~BlockInsertionSet):
(JSC::DFG::BlockInsertionSet::insert):
(JSC::DFG::BlockInsertionSet::insertBefore):
(JSC::DFG::BlockInsertionSet::execute):
* dfg/DFGBlockInsertionSet.h: Added.
(DFG):
(BlockInsertionSet):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::run):
* dfg/DFGCFGSimplificationPhase.cpp:
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
* dfg/DFGCommon.cpp:
(WTF::printInternal):
* dfg/DFGCommon.h:
(JSC::DFG::doesKill):
(DFG):
(JSC::DFG::killStatusForDoesKill):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::isCapturedAtOrAfter):
* dfg/DFGCriticalEdgeBreakingPhase.cpp: Added.
(DFG):
(CriticalEdgeBreakingPhase):
(JSC::DFG::CriticalEdgeBreakingPhase::CriticalEdgeBreakingPhase):
(JSC::DFG::CriticalEdgeBreakingPhase::run):
(JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
(JSC::DFG::performCriticalEdgeBreaking):
* dfg/DFGCriticalEdgeBreakingPhase.h: Added.
(DFG):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::run):
(JSC::DFG::DCEPhase::findTypeCheckRoot):
(JSC::DFG::DCEPhase::countNode):
(DCEPhase):
(JSC::DFG::DCEPhase::countEdge):
(JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGEdge.cpp:
(JSC::DFG::Edge::dump):
* dfg/DFGEdge.h:
(JSC::DFG::Edge::Edge):
(JSC::DFG::Edge::setNode):
(JSC::DFG::Edge::useKindUnchecked):
(JSC::DFG::Edge::setUseKind):
(JSC::DFG::Edge::setProofStatus):
(JSC::DFG::Edge::willNotHaveCheck):
(JSC::DFG::Edge::willHaveCheck):
(Edge):
(JSC::DFG::Edge::killStatusUnchecked):
(JSC::DFG::Edge::killStatus):
(JSC::DFG::Edge::setKillStatus):
(JSC::DFG::Edge::doesKill):
(JSC::DFG::Edge::doesNotKill):
(JSC::DFG::Edge::shift):
(JSC::DFG::Edge::makeWord):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGFlushFormat.cpp: Added.
(WTF):
(WTF::printInternal):
* dfg/DFGFlushFormat.h: Added.
(DFG):
(JSC::DFG::resultFor):
(JSC::DFG::useKindFor):
(WTF):
* dfg/DFGFlushLivenessAnalysisPhase.cpp: Added.
(DFG):
(FlushLivenessAnalysisPhase):
(JSC::DFG::FlushLivenessAnalysisPhase::FlushLivenessAnalysisPhase):
(JSC::DFG::FlushLivenessAnalysisPhase::run):
(JSC::DFG::FlushLivenessAnalysisPhase::process):
(JSC::DFG::FlushLivenessAnalysisPhase::setForNode):
(JSC::DFG::FlushLivenessAnalysisPhase::flushFormat):
(JSC::DFG::performFlushLivenessAnalysis):
* dfg/DFGFlushLivenessAnalysisPhase.h: Added.
(DFG):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::dumpBlockHeader):
(DFG):
(JSC::DFG::Graph::addForDepthFirstSort):
(JSC::DFG::Graph::getBlocksInDepthFirstOrder):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::convertToConstant):
(JSC::DFG::Graph::valueProfileFor):
(Graph):
* dfg/DFGInsertionSet.h:
(DFG):
(JSC::DFG::InsertionSet::execute):
* dfg/DFGLivenessAnalysisPhase.cpp: Added.
(DFG):
(LivenessAnalysisPhase):
(JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase):
(JSC::DFG::LivenessAnalysisPhase::run):
(JSC::DFG::LivenessAnalysisPhase::process):
(JSC::DFG::LivenessAnalysisPhase::addChildUse):
(JSC::DFG::performLivenessAnalysis):
* dfg/DFGLivenessAnalysisPhase.h: Added.
(DFG):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::hasVariableAccessData):
(DFG):
* dfg/DFGNode.h:
(DFG):
(Node):
(JSC::DFG::Node::hasLocal):
(JSC::DFG::Node::variableAccessData):
(JSC::DFG::Node::hasPhi):
(JSC::DFG::Node::phi):
(JSC::DFG::Node::takenBlock):
(JSC::DFG::Node::notTakenBlock):
(JSC::DFG::Node::successor):
(JSC::DFG::Node::successorForCondition):
(JSC::DFG::nodeComparator):
(JSC::DFG::nodeListDump):
(JSC::DFG::nodeMapDump):
* dfg/DFGNodeFlags.cpp:
(JSC::DFG::dumpNodeFlags):
* dfg/DFGNodeType.h:
(DFG):
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp: Added.
(DFG):
(OSRAvailabilityAnalysisPhase):
(JSC::DFG::OSRAvailabilityAnalysisPhase::OSRAvailabilityAnalysisPhase):
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
(JSC::DFG::performOSRAvailabilityAnalysis):
* dfg/DFGOSRAvailabilityAnalysisPhase.h: Added.
(DFG):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSSAConversionPhase.cpp: Added.
(DFG):
(SSAConversionPhase):
(JSC::DFG::SSAConversionPhase::SSAConversionPhase):
(JSC::DFG::SSAConversionPhase::run):
(JSC::DFG::SSAConversionPhase::forwardPhiChildren):
(JSC::DFG::SSAConversionPhase::forwardPhi):
(JSC::DFG::SSAConversionPhase::forwardPhiEdge):
(JSC::DFG::SSAConversionPhase::deduplicateChildren):
(JSC::DFG::SSAConversionPhase::addFlushedLocalOp):
(JSC::DFG::SSAConversionPhase::addFlushedLocalEdge):
(JSC::DFG::performSSAConversion):
* dfg/DFGSSAConversionPhase.h: Added.
(DFG):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
(Validate):
(JSC::DFG::Validate::validateCPS):
* dfg/DFGVariableAccessData.h:
(JSC::DFG::VariableAccessData::flushFormat):
(VariableAccessData):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::createPhiVariables):
(JSC::FTL::LowerDFGToLLVM::compileBlock):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileUpsilon):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compilePhi):
(JSC::FTL::LowerDFGToLLVM::compileJSConstant):
(JSC::FTL::LowerDFGToLLVM::compileWeakJSConstant):
(JSC::FTL::LowerDFGToLLVM::compileGetArgument):
(JSC::FTL::LowerDFGToLLVM::compileGetLocal):
(JSC::FTL::LowerDFGToLLVM::compileSetLocal):
(JSC::FTL::LowerDFGToLLVM::compileAdd):
(JSC::FTL::LowerDFGToLLVM::compileArithSub):
(JSC::FTL::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::LowerDFGToLLVM::compileArithDiv):
(JSC::FTL::LowerDFGToLLVM::compileArithMod):
(JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
(JSC::FTL::LowerDFGToLLVM::compileArithAbs):
(JSC::FTL::LowerDFGToLLVM::compileArithNegate):
(JSC::FTL::LowerDFGToLLVM::compileBitAnd):
(JSC::FTL::LowerDFGToLLVM::compileBitOr):
(JSC::FTL::LowerDFGToLLVM::compileBitXor):
(JSC::FTL::LowerDFGToLLVM::compileBitRShift):
(JSC::FTL::LowerDFGToLLVM::compileBitLShift):
(JSC::FTL::LowerDFGToLLVM::compileBitURShift):
(JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
(JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble):
(JSC::FTL::LowerDFGToLLVM::compileGetButterfly):
(JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
(JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar):
(JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
(JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
(JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
(JSC::FTL::LowerDFGToLLVM::compileCompareLess):
(JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
(JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
(JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):
(JSC::FTL::LowerDFGToLLVM::compileLogicalNot):
(JSC::FTL::LowerDFGToLLVM::speculateBackward):
(JSC::FTL::LowerDFGToLLVM::lowInt32):
(JSC::FTL::LowerDFGToLLVM::lowCell):
(JSC::FTL::LowerDFGToLLVM::lowBoolean):
(JSC::FTL::LowerDFGToLLVM::lowDouble):
(JSC::FTL::LowerDFGToLLVM::lowJSValue):
(JSC::FTL::LowerDFGToLLVM::lowStorage):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::speculateBoolean):
(JSC::FTL::LowerDFGToLLVM::isLive):
(JSC::FTL::LowerDFGToLLVM::use):
(JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
(JSC::FTL::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
(JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
(JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
(JSC::FTL::LowerDFGToLLVM::setInt32):
(JSC::FTL::LowerDFGToLLVM::setJSValue):
(JSC::FTL::LowerDFGToLLVM::setBoolean):
(JSC::FTL::LowerDFGToLLVM::setStorage):
(JSC::FTL::LowerDFGToLLVM::setDouble):
(JSC::FTL::LowerDFGToLLVM::isValid):
* ftl/FTLLoweredNodeValue.h: Added.
(FTL):
(LoweredNodeValue):
(JSC::FTL::LoweredNodeValue::LoweredNodeValue):
(JSC::FTL::LoweredNodeValue::isSet):
(JSC::FTL::LoweredNodeValue::operator!):
(JSC::FTL::LoweredNodeValue::value):
(JSC::FTL::LoweredNodeValue::block):
* ftl/FTLValueFromBlock.h:
(JSC::FTL::ValueFromBlock::ValueFromBlock):
(ValueFromBlock):
* ftl/FTLValueSource.cpp:
(JSC::FTL::ValueSource::dump):
* ftl/FTLValueSource.h:
2013-07-11 Mark Lam
Resurrect the CLoop LLINT on the FTL branch.
https://bugs.webkit.org/show_bug.cgi?id=118144.
Reviewed by Mark Hahnenberg.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::jitType):
- Fix the CodeBlock jitType to be InterpreterThunk when !ENABLE_JIT.
* bytecode/JumpTable.h:
(JSC::SimpleJumpTable::clear):
* interpreter/StackIterator.cpp:
(JSC::StackIterator::Frame::bytecodeOffset):
(JSC::StackIterator::Frame::print):
* jit/JITCode.cpp:
(JSC):
* jit/JITExceptions.cpp:
(JSC::getExceptionLocation):
* llint/LowLevelInterpreter.cpp:
* offlineasm/cloop.rb:
* runtime/Structure.cpp:
2013-07-08 Filip Pizlo
NaturalLoops + Profiler = Crash
https://bugs.webkit.org/show_bug.cgi?id=118486
Reviewed by Geoffrey Garen.
I borked dominators in:
http://trac.webkit.org/changeset/152431/branches/dfgFourthTier/Source/JavaScriptCore/dfg/DFGDominators.h
This patch also adds some debug support, and fixes the loop that adds a block to
an already-existing natural loop. Note that we currently don't take that path in
most programs, but it will arise, for example if you use 'continue' - though you'd
have to use it rather cleverly since the bytecode will not jump to the loop header
in most uses of 'continue'.
* dfg/DFGDominators.cpp:
(JSC::DFG::Dominators::dump):
(DFG):
* dfg/DFGDominators.h:
(JSC::DFG::Dominators::dominates):
(Dominators):
* dfg/DFGNaturalLoops.cpp:
(JSC::DFG::NaturalLoops::compute):
2013-07-08 Filip Pizlo
fourthTier: DFG::AbstractState::beginBasicBlock() should set m_haveStructures if any of the valuesAtHead have either a current known structure or a non-top/non-bottom array modes
https://bugs.webkit.org/show_bug.cgi?id=118489
Reviewed by Mark Hahnenberg.
* bytecode/ArrayProfile.h:
(JSC::arrayModesAreClearOrTop):
(JSC):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::beginBasicBlock):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::hasClobberableState):
(AbstractValue):
2013-07-08 Mark Hahnenberg
CheckArray should call the right version of filterArrayModes
https://bugs.webkit.org/show_bug.cgi?id=118488
Reviewed by Filip Pizlo.
Currently in the CFA CheckArray doesn't call the right filterArrayMode which can cause
the CFA to ignore when it sees a contradiction.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
2013-07-07 Filip Pizlo
fourthTier: Graph::clearAndDerefChild() makes no sense anymore, and neither does Nop
https://bugs.webkit.org/show_bug.cgi?id=118452
Reviewed by Sam Weinig.
Noticed that ArgumentsSimplificationPhase was converting something to a Nop and then
resetting its children using clearAndDerefChild(). Using Nop instead of Phantom is a
holdover from back when we needed a no-MustGenerate no-op. We don't anymore. Using
clearAndDerefChild() was necessary back when we did eager reference counting. We
don't need to do that anymore, and in fact clearAndDerefChild() appeared to not do
any reference counting, so it was badly named to begin with.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::performNodeCSE):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGNode.h:
(JSC::DFG::Node::willHaveCodeGenOrOSR):
* dfg/DFGNodeType.h:
(DFG):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2013-07-04 Filip Pizlo
fourthTier: FTL should better report its compile-times and it should be able to run in a mode where it doesn't spend time generating OSR exits
https://bugs.webkit.org/show_bug.cgi?id=118401
Reviewed by Sam Weinig.
Add two new OSR exit modes, which are useful only for playing with compile times:
- All OSR exits are llvm.trap().
- OSR exits don't take arguments and have no exit value marshaling.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPlan.h:
(Plan):
* ftl/FTLIntrinsicRepository.h:
(FTL):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::appendOSRExit):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
* ftl/FTLOutput.h:
(JSC::FTL::Output::trap):
* runtime/Options.h:
(JSC):
2013-07-04 Filip Pizlo
fourthTier: DFG should refer to BasicBlocks by BasicBlock* and not BlockIndex
https://bugs.webkit.org/show_bug.cgi?id=118339
Reviewed by Michael Saboff.
This accomplishes two goals:
1) Simplifies a bunch of code. You can now much more directly get to a successor
or predecessor, since you just get the pointer directly. The backend(s) always
hold onto a pointer to the block they're on, so you don't have to do work to
get the block from the index.
2) It allows for the possibility of inserting blocks into the program.
Previously, if you did that, you'd have to edit all references to blocks since
those references would have outdated indexing after an insertion. Now, if you
change the indexing, you just have to invalidate some analyses and make sure
that you change each block's BasicBlock::index accordingly.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::initialize):
(JSC::DFG::AbstractState::endBasicBlock):
(JSC::DFG::AbstractState::mergeToSuccessors):
* dfg/DFGAbstractState.h:
(AbstractState):
* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::run):
* dfg/DFGBasicBlock.h:
(DFG):
(JSC::DFG::BasicBlock::BasicBlock):
(JSC::DFG::BasicBlock::size):
(JSC::DFG::BasicBlock::isEmpty):
(JSC::DFG::BasicBlock::at):
(JSC::DFG::BasicBlock::operator[]):
(JSC::DFG::BasicBlock::last):
(JSC::DFG::BasicBlock::resize):
(JSC::DFG::BasicBlock::grow):
(BasicBlock):
(JSC::DFG::BasicBlock::append):
(JSC::DFG::BasicBlock::numSuccessors):
(JSC::DFG::BasicBlock::successor):
(JSC::DFG::BasicBlock::successorForCondition):
(JSC::DFG::BasicBlock::dump):
(UnlinkedBlock):
(JSC::DFG::UnlinkedBlock::UnlinkedBlock):
(JSC::DFG::getBytecodeBeginForBlock):
(JSC::DFG::blockForBytecodeOffset):
* dfg/DFGByteCodeParser.cpp:
(ByteCodeParser):
(InlineStackEntry):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::linkBlock):
(JSC::DFG::ByteCodeParser::linkBlocks):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::performBlockCFA):
(JSC::DFG::CFAPhase::performForwardCFA):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::run):
(JSC::DFG::CFGSimplificationPhase::convertToJump):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlocks):
(JSC::DFG::CPSRethreadingPhase::propagatePhis):
(CPSRethreadingPhase):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::run):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::run):
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::run):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::Disassembler):
(JSC::DFG::Disassembler::createDumpList):
* dfg/DFGDisassembler.h:
(JSC::DFG::Disassembler::setForBlockIndex):
* dfg/DFGDominators.cpp:
(JSC::DFG::Dominators::compute):
(JSC::DFG::Dominators::iterateForBlock):
* dfg/DFGDominators.h:
(JSC::DFG::Dominators::dominates):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::run):
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::dumpBlockHeader):
(JSC::DFG::Graph::handleSuccessor):
(JSC::DFG::Graph::determineReachability):
(JSC::DFG::Graph::resetReachability):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::numBlocks):
(JSC::DFG::Graph::block):
(JSC::DFG::Graph::lastBlock):
(Graph):
(JSC::DFG::Graph::appendBlock):
(JSC::DFG::Graph::killBlock):
(DFG):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::setForBlockIndex):
* dfg/DFGNaturalLoops.cpp:
(JSC::DFG::NaturalLoop::dump):
(JSC::DFG::NaturalLoops::compute):
(JSC::DFG::NaturalLoops::loopsOf):
* dfg/DFGNaturalLoops.h:
(JSC::DFG::NaturalLoop::NaturalLoop):
(JSC::DFG::NaturalLoop::addBlock):
(JSC::DFG::NaturalLoop::header):
(JSC::DFG::NaturalLoop::at):
(JSC::DFG::NaturalLoop::operator[]):
(JSC::DFG::NaturalLoop::contains):
(NaturalLoop):
(JSC::DFG::NaturalLoops::headerOf):
(NaturalLoops):
* dfg/DFGNode.h:
(DFG):
(JSC::DFG::SwitchCase::SwitchCase):
(JSC::DFG::SwitchCase::withBytecodeIndex):
(SwitchCase):
(JSC::DFG::SwitchCase::targetBytecodeIndex):
(JSC::DFG::SwitchData::SwitchData):
(JSC::DFG::SwitchData::setFallThroughBytecodeIndex):
(JSC::DFG::SwitchData::fallThroughBytecodeIndex):
(SwitchData):
(JSC::DFG::Node::setTakenBlock):
(JSC::DFG::Node::setNotTakenBlock):
(JSC::DFG::Node::takenBlock):
(JSC::DFG::Node::notTakenBlock):
(JSC::DFG::Node::successor):
(JSC::DFG::Node::successorForCondition):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagateForward):
(JSC::DFG::PredictionPropagationPhase::propagateBackward):
(JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
(JSC::DFG::SpeculativeJIT::nonSpeculativeCompare):
(JSC::DFG::SpeculativeJIT::nonSpeculativeStrictEq):
(JSC::DFG::SpeculativeJIT::compilePeepHoleDoubleBranch):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleIntegerBranch):
(JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::createOSREntries):
(JSC::DFG::SpeculativeJIT::linkOSREntries):
(JSC::DFG::SpeculativeJIT::compileStrictEqForConstant):
(JSC::DFG::SpeculativeJIT::compileStrictEq):
(JSC::DFG::SpeculativeJIT::compileRegExpExec):
(JSC::DFG::SpeculativeJIT::addBranch):
(JSC::DFG::SpeculativeJIT::linkBranches):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::nextBlock):
(SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
(JSC::DFG::SpeculativeJIT::branchDouble):
(JSC::DFG::SpeculativeJIT::branchDoubleNonZero):
(JSC::DFG::SpeculativeJIT::branch32):
(JSC::DFG::SpeculativeJIT::branchTest32):
(JSC::DFG::SpeculativeJIT::branch64):
(JSC::DFG::SpeculativeJIT::branch8):
(JSC::DFG::SpeculativeJIT::branchPtr):
(JSC::DFG::SpeculativeJIT::branchTestPtr):
(JSC::DFG::SpeculativeJIT::branchTest8):
(JSC::DFG::SpeculativeJIT::jump):
(JSC::DFG::SpeculativeJIT::addBranch):
(JSC::DFG::SpeculativeJIT::StringSwitchCase::StringSwitchCase):
(StringSwitchCase):
(JSC::DFG::SpeculativeJIT::BranchRecord::BranchRecord):
(BranchRecord):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::emitBranch):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::emitBranch):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
(JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
* dfg/DFGUnificationPhase.cpp:
(JSC::DFG::UnificationPhase::run):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
(JSC::DFG::Validate::checkOperand):
(JSC::DFG::Validate::reportValidationContext):
* dfg/DFGVirtualRegisterAllocationPhase.cpp:
(JSC::DFG::VirtualRegisterAllocationPhase::run):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileBlock):
(JSC::FTL::LowerDFGToLLVM::compileJump):
(JSC::FTL::LowerDFGToLLVM::compileBranch):
(JSC::FTL::LowerDFGToLLVM::lowBlock):
2013-07-04 Filip Pizlo
Unreviewed, add a helpful comment for why DCE is needed in the FTL.
I believe I've now twice down the experiment of disabling DCE in the FTL,
only to realize that this can't work, and that DCE is needed. I'd kind of
like to not make that mistake again.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
2013-07-02 Filip Pizlo
fourthTier: DFG::Node::m_opInfo2 should also be a uintptr_t
https://bugs.webkit.org/show_bug.cgi?id=118340
Reviewed by Sam Weinig.
* dfg/DFGNode.h:
(JSC::DFG::Node::Node):
2013-07-02 Filip Pizlo
Unreviewed, fix 32-bit build.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::comparePtr):
(MacroAssembler):
* dfg/DFGBinarySwitch.cpp:
(JSC::DFG::BinarySwitch::advance):
* dfg/DFGBinarySwitch.h:
(JSC::DFG::BinarySwitch::caseValue):
2013-07-02 Filip Pizlo
fourthTier: Have fewer Arrayify's
https://bugs.webkit.org/show_bug.cgi?id=118335
Reviewed by Mark Hahnenberg.
A lot of Arrayify's arise because some program saw Int32 arrays early on in
execution, but then they all got converted to Double arrays and the program
will never see Int32 arrays ever again. Prior to this change you would always
have an Arrayify in this case. But with this change, the first time that an
ArrayProfile is about to go polymorphic in computeUpdatedPrediction(), it
instead forcibly monomorphises itself to the latest-seen structure.
Thereafter it will never again perform this monomorphisation. This is
controlled by ArrayProfile::m_didPerformFirstRunPruning. This is a 5%
speed-up on Kraken/imaging-gaussian-blur with the FTL enabled, and it
unblocks a bunch of stuff we want to do in the future because it makes a
bunch of loops effect-free.
We will still want to implement Arrayify hoisting in the future, but this is
great anyway because it's better to not have Arrayifications than it is to
have hoisted Arrayifications.
* bytecode/ArrayProfile.cpp:
(JSC::ArrayProfile::computeUpdatedPrediction):
(JSC::ArrayProfile::briefDescription):
(JSC):
(JSC::ArrayProfile::briefDescriptionWithoutUpdating):
* bytecode/ArrayProfile.h:
(JSC::ArrayProfile::ArrayProfile):
(ArrayProfile):
2013-07-02 Filip Pizlo