Google Git
Sign in
webkit / WebKit / 2cfd376d07b8ad4ebbcb316d30ad71ad3ab46882 / . / Source / JavaScriptCore / ChangeLog
blob: 4dfcc8f9788194a76d57d37e13e59f126a2cb19d [file] [log] [blame]
2013-08-05 Oliver Hunt <oliver@apple.com>
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 <paroga@webkit.org>
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 <dfarler@apple.com>
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 <paroga@webkit.org>
Build fix for ARM MSVC after r153222 and r153648.
* jit/JITStubsARM.h: Added ctiVMThrowTrampolineSlowpath.
2013-08-06 Patrick Gansterer <paroga@webkit.org>
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 <oliver@apple.com>
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 <fpizlo@apple.com>
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 <zdobersek@igalia.com>
[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 <fpizlo@apple.com>
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 <chris_curtis@apple.com>
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 <oliver@apple.com>
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 <barraclough@apple.com>
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 <mhahnenberg@apple.com>
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 <chris_curtis@apple.com>
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 <jbrianceau@nds.com>
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 <fpizlo@apple.com>
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 <jbrianceau@nds.com>
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 <msaboff@apple.com>
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 <paroga@webkit.org>
Add JSCTestRunnerUtils to the list of forwarding headers to fix build.
* CMakeLists.txt:
2013-08-01 Ruth Fong <ruth_fong@apple.com>
[Forms: color] <input type='color'> popover color well implementation
<rdar://problem/14411008> 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 <oliver@apple.com>
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 <msaboff@apple.com>
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 <jbrianceau@nds.com>
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 <barraclough@apple.com>
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 <max.hong.shen@gmail.com>
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 <skyul@company100.net>
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 <ruth_fong@apple.com>
<input type=color> Mac UI behaviour
<rdar://problem/10269922> 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 <mhahnenberg@apple.com>
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 <barraclough@apple.com>
Speculative Windows build fix.
Reviewed by NOBODY
* runtime/JSString.cpp:
(JSC::JSRopeString::getIndexSlowCase):
* runtime/JSString.h:
2013-07-30 Gavin Barraclough <barraclough@apple.com>
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 <msaboff@apple.com>
[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 <mhahnenberg@apple.com>
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 <oliver@apple.com>
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 <mark.lam@apple.com>
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 <cgarcia@igalia.com>
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 <chris_curtis@apple.com>
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 <barraclough@apple.com>
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 <oliver@apple.com>
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 <oliver@apple.com>
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 <fpizlo@apple.com>
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 <kilvadyb@homejinni.com>
[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 <mhahnenberg@apple.com>
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 <jbrianceau@nds.com>
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 <jbrianceau@nds.com>
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 <zdobersek@igalia.com>
Unreviewed.
* Target.pri: Adding missing DFG files to the Qt build.
2013-07-25 Csaba Osztrogonác <ossy@webkit.org>
GTK and Qt buildfix after the intrusive win buildfix r153360.
* GNUmakefile.list.am:
* Target.pri:
2013-07-25 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Unreviewed, fix build break after r153360.
* CMakeLists.txt: Add CommonSlowPathsExceptions.cpp.
2013-07-25 Roger Fong <roger_fong@apple.com>
Unreviewed build fix, AppleWin port.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.vcxproj/copy-files.cmd:
2013-07-25 Roger Fong <roger_fong@apple.com>
Unreviewed. Followup to r153360.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2013-07-25 Michael Saboff <msaboff@apple.com>
[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 <bfulgham@apple.com>
[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 <andersca@apple.com>
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 <zdobersek@igalia.com>
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<JSC::JITCode> (intended as a parameter to the installOptimizedCode call) from the jitCode
RefPtr<JSC::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 <bfulgham@apple.com>
[Windows] Unreviewed build fix.
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Add missing 'ftl'
include path.
2013-07-25 Brent Fulgham <bfulgham@apple.com>
[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 <oliver@apple.com>
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 <oliver@apple.com>
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 <oliver@apple.com>
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 <max.hong.shen@gmail.com>
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 <ch.dumez@sisa.samsung.com>
Unreviewed build fix after r153218.
Broke the EFL port build with gcc 4.7.
* interpreter/StackIterator.cpp:
(JSC::printif):
2013-07-25 Julien Brianceau <jbrianceau@nds.com>
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 <ryuan.choi@samsung.com>
Unreviewed, build fix on the EFL port.
* CMakeLists.txt: Added JSCTestRunnerUtils.cpp.
2013-07-25 Julien Brianceau <jbrianceau@nds.com>
[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 <allan.jensen@digia.com>
[Qt] Fix test build after FTL upstream
Unreviewed build fix.
* Target.pri:
2013-07-25 Allan Sandfeld Jensen <allan.jensen@digia.com>
[Qt] Build fix after FTL.
Un Reviewed build fix.
* Target.pri:
* interpreter/StackIterator.cpp:
(JSC::StackIterator::Frame::print):
2013-07-25 Gabor Rapcsanyi <rgabor@webkit.org>
Unreviewed build fix after FTL upstream.
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::~Worklist):
2013-07-25 Ryuan Choi <ryuan.choi@samsung.com>
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 <kadam@inf.u-szeged.hu>
Unreviewed build fixing after FTL upstream.
* runtime/Executable.cpp:
(JSC::FunctionExecutable::produceCodeBlockFor):
2013-07-25 Julien Brianceau <jbrianceau@nds.com>
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 <rgabor@webkit.org>
Unreviewed, build fix on the Qt port.
* Target.pri: Add additional build files for the FTL.
2013-07-25 Ádám Kallai <kadam@inf.u-szeged.hu>
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 <zdobersek@igalia.com>
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 <zdobersek@igalia.com>
Unreviewed, further build fixing on the GTK port.
* GNUmakefile.list.am: Add CompilationResult source files to the build.
2013-07-25 Zan Dobersek <zdobersek@igalia.com>
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 <ossy@webkit.org>
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 <ossy@webkit.org>
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 <jbrianceau@nds.com>
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 <zdobersek@igalia.com>
Unreviewed GTK build fix.
* GNUmakefile.list.am: Adding JSCTestRunnerUtils files to the build.
2013-07-25 Zan Dobersek <zdobersek@igalia.com>
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 <zdobersek@igalia.com>
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 <kadam@inf.u-szeged.hu>
Unreviewed buildfix after FTL upstream.
* runtime/JSScope.h:
(JSC::needsVarInjectionChecks):
2013-07-25 Csaba Osztrogonác <ossy@webkit.org>
One more fix after FTL upstream.
* Target.pri:
* bytecode/CodeBlock.h:
* bytecode/GetByIdStatus.h:
(JSC::GetByIdStatus::GetByIdStatus):
2013-07-24 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed buildfix after FTL upstream.
Add ftl directory as include path.
* CMakeLists.txt:
* JavaScriptCore.pri:
2013-07-24 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed buildfix after FTL upstream for non C++11 builds.
* interpreter/CallFrame.h:
* interpreter/StackIteratorPrivate.h:
(JSC::StackIterator::end):
2013-07-24 Oliver Hunt <oliver@apple.com>
Endeavour to fix CMakelist builds
* CMakeLists.txt:
2013-07-24 Filip Pizlo <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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<):
(JSC::DFG::AbstractHeap::Payload::isDisjoint):
(JSC::DFG::AbstractHeap::Payload::overlaps):
(JSC::DFG::AbstractHeap::AbstractHeap):
(JSC::DFG::AbstractHeap::operator!):
(JSC::DFG::AbstractHeap::kind):
(JSC::DFG::AbstractHeap::payload):
(JSC::DFG::AbstractHeap::isDisjoint):
(JSC::DFG::AbstractHeap::overlaps):
(JSC::DFG::AbstractHeap::supertype):
(JSC::DFG::AbstractHeap::hash):
(JSC::DFG::AbstractHeap::operator==):
(JSC::DFG::AbstractHeap::operator!=):
(JSC::DFG::AbstractHeap::operator<):
(JSC::DFG::AbstractHeap::isHashTableDeletedValue):
(JSC::DFG::AbstractHeap::payloadImpl):
(JSC::DFG::AbstractHeap::encode):
(JSC::DFG::AbstractHeapHash::hash):
(JSC::DFG::AbstractHeapHash::equal):
(AbstractHeapHash):
(WTF):
* dfg/DFGClobberSet.cpp: Added.
(DFG):
(JSC::DFG::ClobberSet::ClobberSet):
(JSC::DFG::ClobberSet::~ClobberSet):
(JSC::DFG::ClobberSet::add):
(JSC::DFG::ClobberSet::addAll):
(JSC::DFG::ClobberSet::contains):
(JSC::DFG::ClobberSet::overlaps):
(JSC::DFG::ClobberSet::clear):
(JSC::DFG::ClobberSet::direct):
(JSC::DFG::ClobberSet::super):
(JSC::DFG::ClobberSet::dump):
(JSC::DFG::ClobberSet::setOf):
(JSC::DFG::addReads):
(JSC::DFG::addWrites):
(JSC::DFG::addReadsAndWrites):
(JSC::DFG::readsOverlap):
(JSC::DFG::writesOverlap):
* dfg/DFGClobberSet.h: Added.
(DFG):
(ClobberSet):
(JSC::DFG::ClobberSet::isEmpty):
(ClobberSetAdd):
(JSC::DFG::ClobberSetAdd::ClobberSetAdd):
(JSC::DFG::ClobberSetAdd::operator()):
(ClobberSetOverlaps):
(JSC::DFG::ClobberSetOverlaps::ClobberSetOverlaps):
(JSC::DFG::ClobberSetOverlaps::operator()):
(JSC::DFG::ClobberSetOverlaps::result):
* dfg/DFGClobberize.cpp: Added.
(DFG):
(JSC::DFG::didWrites):
* dfg/DFGClobberize.h: Added.
(DFG):
(JSC::DFG::clobberize):
(NoOpClobberize):
(JSC::DFG::NoOpClobberize::NoOpClobberize):
(JSC::DFG::NoOpClobberize::operator()):
(CheckClobberize):
(JSC::DFG::CheckClobberize::CheckClobberize):
(JSC::DFG::CheckClobberize::operator()):
(JSC::DFG::CheckClobberize::result):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
2013-07-21 Filip Pizlo <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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<AbstractStateType>, 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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <mark.lam@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <mhahnenberg@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
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 <fpizlo@apple.com>
fourthTier: add option to disable OSR entry in loops
https://bugs.webkit.org/show_bug.cgi?id=118329
Reviewed by Mark Hahnenberg.
This adds that option, and also makes the OSR exit reoptimization trigger rely less on
OSR entry failing. Now even if we never attempt OSR entry but our execution counter gets
high after a small number of OSR exits, we will recompile.
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::handleExitCounts):
* dfg/DFGOperations.cpp:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
* runtime/Options.h:
(JSC):
2013-07-02 Filip Pizlo <fpizlo@apple.com>
fourthTier: since the FTL disassembly hacks cannot distinguish between code and data, the LLVM disassembler symbol table callback should be able to deal gracefully with arbitrary garbage
https://bugs.webkit.org/show_bug.cgi?id=118313
Reviewed by Mark Hahnenberg.
Give it a mode where we can still crash on unrecognized reference types, so that we might
implement them in the future, but by default just print some stuff and keep going.
* disassembler/LLVMDisassembler.cpp:
(JSC):
(JSC::symbolLookupCallback):
2013-07-02 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should use the equivalent of llvm opt -O2 by default
https://bugs.webkit.org/show_bug.cgi?id=118311
Reviewed by Mark Hahnenberg.
Use a PassManagerBuilder instead of rolling our own.
This boosts our speed-up by another 5% or so.
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* runtime/Options.h:
(JSC):
2013-07-01 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should run LICM after AA setup
https://bugs.webkit.org/show_bug.cgi?id=118277
Reviewed by Maciej Stachowiak.
LICM queries alias analysis. Hence, just like GVN, it should run after
we have set up the alias analysis.
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
2013-07-01 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should run AA passes before GVN
https://bugs.webkit.org/show_bug.cgi?id=118276
Rubber stamped by Geoffrey Garen.
These enable load elimination in GVN.
Immediately gives us a speed-up on a bunch of benchmarks I hacked to run
properly in the FTL. One example is 20% on imaging-gaussian-blur. (Fair
warning: the stock version of that benchmark won't see speed-ups -
probably slow-downs instead - because the FTL can't do OSR entry yet.)
Another example is the findGraphNode function, which now sees a 7%
speed-up, and that's without even doing LICM or other good things.
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
2013-06-27 Filip Pizlo <fpizlo@apple.com>
Make Graph::substituteGetLocal() out-of-line
Rubber stamped by Geoffrey Garen.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::substituteGetLocal):
(DFG):
* dfg/DFGGraph.h:
(Graph):
2013-06-27 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should know how to find natural loops
https://bugs.webkit.org/show_bug.cgi?id=118152
Reviewed by Mark Hahnenberg.
There are a bunch of things we can do when we know where the loops are.
Previously we didn't. With this patch, we do.
This patch adds the classic dominator based natural loop finder.
The only client of this right now is the DFG::Disassembler. It prints out
a summary of the analysis for each block.
This will become more important when I do
https://bugs.webkit.org/show_bug.cgi?id=118151, which definitely requires
this kind of analysis, at least if we want to do the optimization over
DFG IR (and I'm pretty sure we do).
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAnalysis.h: Added.
(DFG):
(Analysis):
(JSC::DFG::Analysis::Analysis):
(JSC::DFG::Analysis::invalidate):
(JSC::DFG::Analysis::computeIfNecessary):
(JSC::DFG::Analysis::isValid):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::run):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::createDumpList):
* dfg/DFGDominators.cpp:
(JSC::DFG::Dominators::Dominators):
(JSC::DFG::Dominators::compute):
* dfg/DFGDominators.h:
(Dominators):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dumpBlockHeader):
(JSC::DFG::Graph::invalidateCFG):
(DFG):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGNaturalLoops.cpp: Added.
(DFG):
(JSC::DFG::NaturalLoop::dump):
(JSC::DFG::NaturalLoops::NaturalLoops):
(JSC::DFG::NaturalLoops::~NaturalLoops):
(JSC::DFG::NaturalLoops::compute):
(JSC::DFG::NaturalLoops::loopsOf):
(JSC::DFG::NaturalLoops::dump):
* dfg/DFGNaturalLoops.h: Added.
(DFG):
(NaturalLoop):
(JSC::DFG::NaturalLoop::NaturalLoop):
(JSC::DFG::NaturalLoop::addBlock):
(JSC::DFG::NaturalLoop::header):
(JSC::DFG::NaturalLoop::size):
(JSC::DFG::NaturalLoop::at):
(JSC::DFG::NaturalLoop::operator[]):
(JSC::DFG::NaturalLoop::contains):
(NaturalLoops):
(JSC::DFG::NaturalLoops::numLoops):
(JSC::DFG::NaturalLoops::loop):
(JSC::DFG::NaturalLoops::headerOf):
2013-06-27 Filip Pizlo <fpizlo@apple.com>
fourthTier: JSC's disassembly infrastructure should be able to disassemble the code that LLVM generates
https://bugs.webkit.org/show_bug.cgi?id=118148
Reviewed by Anders Carlsson.
Oh boy. UDis86 cannot disassemble the AVX (or whatever it's called) stuff
that LLVM generates for floating point. So the right decision is to
switch to the LLVM disassembler, right? Wrong!! LLVM's disassembler
cannot disassemble the load-from-absolute-address-into-%rax instructions
that our JIT generates quite a lot of.
So, this keeps the UDis86 disassembler, but adds the LLVM disassembler,
and requires the caller of disassemble() to hint which one is likely to
be less wrong for the given code.
Maybe in the future LLVM will catch up to UDis86, but it's definitely not
there right now.
This now allows us to disassemble all of the code that LLVM generates.
* JavaScriptCore.xcodeproj/project.pbxproj:
* disassembler/Disassembler.cpp:
(JSC::disassemble):
* disassembler/Disassembler.h:
(JSC::tryToDisassemble):
(JSC):
* disassembler/LLVMDisassembler.cpp: Added.
(JSC):
(JSC::symbolLookupCallback):
(JSC::tryToDisassembleWithLLVM):
* disassembler/LLVMDisassembler.h: Added.
(JSC):
(JSC::tryToDisassembleWithLLVM):
* disassembler/UDis86Disassembler.cpp:
(JSC::tryToDisassembleWithUDis86):
* disassembler/UDis86Disassembler.h: Added.
(JSC):
(JSC::tryToDisassembleWithUDis86):
* disassembler/X86Disassembler.cpp: Added.
(JSC):
(JSC::tryToDisassemble):
* ftl/FTLAbbreviatedTypes.h:
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLJITCode.h:
* ftl/FTLJITFinalizer.h:
* ftl/FTLLLVMHeaders.h: Removed.
* ftl/FTLLink.cpp:
* runtime/InitializeThreading.cpp:
(JSC::initializeThreadingOnce):
* runtime/Options.h:
(JSC):
2013-06-27 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should be able to dump disassembly
https://bugs.webkit.org/show_bug.cgi?id=118141
Reviewed by Geoffrey Garen.
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
2013-06-27 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix build for LLVM ToT.
This doesn't affect those using the binary drops, but if you're building from
LLVM ToT you'll get link errors. These arise because we expect there to be a
libLLVMArchive, but that is no longer built by LLVM ToT. This casues the linker
to fall back on the system's libLLVMArchive, which is incompatible with the
other LLVM libs we pull in.
Also, we didn't need that library anyway and shouldn't have been linking
against it.
* Configurations/JavaScriptCore.xcconfig:
2013-06-26 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support hole/OOB PutByVal's
https://bugs.webkit.org/show_bug.cgi?id=118112
Reviewed by Geoffrey Garen.
Added a common code generator for the out-of-bounds case that is reused by
all contiguous-like arrays (Int32, Double, Contiguous).
This is relatively straight-forward, except that it's the first time that
the FTL has to call DFG operations that take more than two arguments.
* ftl/FTLAbbreviations.h:
(JSC::FTL::functionType):
(JSC::FTL::buildCall):
* ftl/FTLAbstractHeapRepository.h:
(FTL):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
(FTL):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compilePutByVal):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::contiguousPutByValOutOfBounds):
(JSC::FTL::LowerDFGToLLVM::vmCall):
* ftl/FTLOutput.h:
(JSC::FTL::Output::call):
2013-06-26 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL::canCompile(Graph&) should not consider nodes that won't be compiled
https://bugs.webkit.org/show_bug.cgi?id=118097
Reviewed by Mark Hahnenberg.
This increases coverage to include programs that have unprofiled paths. Those paths will
often have nodes that appear to do untyped speculations, and the FTL sometimes doesn't
support those; except that it doesn't matter since the reason why they were untyped is
that they were unprofiled and anyway we won't run them because we'll exit before them.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
2013-06-26 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support ArrayifyToStructure
https://bugs.webkit.org/show_bug.cgi?id=118095
Reviewed by Mark Hahnenberg.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
(FTL):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
(LowerDFGToLLVM):
2013-06-26 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support ForwardCheckStructure/ForwardStructureTransitionWatchpoint and doing so shouldn't break V8/crypto
https://bugs.webkit.org/show_bug.cgi?id=118091
Reviewed by Mark Hahnenberg.
I was going to just add ForwardCheckStructure/ForwardStructureTransitionWatchpoint support,
which is trivial. But doing so increases coverage a lot, and revealed long-standing bugs in
the FTL. I then fixed those bugs, also:
- The FTL should not attempt to compile a block that is not reachable according to the CFA.
This is analogous to terminating basic block compilation if the CFA becomes !isValid().
Attempting to compile such a block means that you're running on broken CFA state, and the
CFA will become inconsistent with the code you're generating, leading to some
strangeness. For example, the FTL relies on the CFA to tell it that we gave up compiling
a node and hence don't have LValue's for that node (by virtue of us giving up due to
!isValid()). But the CFA's isValid() bit will not be set correctly for blocks that
weren't visited by the CFA at all, and the CFA expects you to know this because it
expects that you already checked BasicBlock::cfaHasVisited.
- SetLocal needs to change the ValueSource of the operand to indicate that its value has
been stashed in the local (i.e. the "reference" corresponding to the operand in FTL
speak). This is because although OSR exit already knows that the value of the operand is
stored in the Node, and it already knows what LValue corresponds to the node, OSR exit
will also assume that if the Node dies then the value-at-exit for that operand should be
Dead (i.e. jsUndefined). But the Node dying, and the local dying, are two distinct
things; in particular the local always outlives the Node in the case of a SetLocal. So,
we just need to have SetLocal have the ValueSource be BlahInLocal rather than HaveNode,
to ensure that OSR exit knows that the darn thing is really live until the end of the
basic block, as opposed to until whenever the Node dies (which could be at any time).
- PutByOffset was erroneously storing to an offset from the base object, rather than an
offset from the storage. Note that the storage will be the base object (exactly - i.e.
same node, same value) for inline stores, but will be a distinct thing for out-of-line
stores.
- At-head set-up of OSR exit state was using ValueInLocals for variables forced double,
when it should have been using DoubleInLocals.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileBlock):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileSetLocal):
(JSC::FTL::LowerDFGToLLVM::compilePutByOffset):
(JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
(JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
2013-06-26 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support PutByVal
https://bugs.webkit.org/show_bug.cgi?id=118075
Reviewed by Mark Hahnenberg.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compilePutByVal):
2013-06-25 Filip Pizlo <fpizlo@apple.com>
fourthTier: Convert versus AsIs should have no bearing on whether we can do the SaneChain optimization for double array GetByVals
https://bugs.webkit.org/show_bug.cgi?id=118028
Reviewed by Sam Weinig.
The SaneChain optimization allows us to get rid of the NaN check on loading from
a double array, if the result is used in an arithmetic op that wouldn't
distinguish between NaN and undefined. Normally the NaN check would be needed
because NaN is the hole marker.
The SaneChain optimization definitely requires that you're an Original array,
since we need to watchpoint the array prototype chain. And so it also needs to
be a JSArray, and not an object that has indexed double properties. We also
require an in-bounds access, since the backend is only capable of the
optimization in the in-bounds case (though we could extend it to OOB in the
future). But whether the array is being converted or is as-is isn't relevant.
Either way, if it's a double original array in-bounds access by the time that
the array check (or conversion!) completes, we can do the optimization.
Ever-so-slight speed-up on Kraken/imaging-gaussian-blur.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2013-06-25 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should support switch_string
https://bugs.webkit.org/show_bug.cgi?id=117967
Reviewed by Sam Weinig.
Add a reusable binary switch creator.
Implement switch on string using three modes:
- Binary switch on StringImpl* in the case of identifiers.
- Trie of binary switches on characters in the case of a not-too-big
switch over not-too-big 8-bit strings.
- Hash lookup if all else fails.
Anywhere from a 2x to 3x speed-up on microbenchmarks that stress
string switches. 25-35% speed-up on HashMap tests. 4% speed-up on
pdfjs.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/JumpTable.h:
(StringJumpTable):
(JSC::StringJumpTable::clear):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGBinarySwitch.cpp: Added.
(DFG):
(JSC::DFG::BinarySwitch::BinarySwitch):
(JSC::DFG::BinarySwitch::advance):
(JSC::DFG::BinarySwitch::build):
* dfg/DFGBinarySwitch.h: Added.
(DFG):
(BinarySwitch):
(JSC::DFG::BinarySwitch::caseIndex):
(JSC::DFG::BinarySwitch::caseValue):
(JSC::DFG::BinarySwitch::fallThrough):
(JSC::DFG::BinarySwitch::Case::Case):
(Case):
(JSC::DFG::BinarySwitch::Case::operator<):
(JSC::DFG::BinarySwitch::BranchCode::BranchCode):
(BranchCode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::getValue):
(JSC::DFG::equalToStringImpl):
(DFG):
(JSC::DFG::LazyJSValue::strictEqual):
(JSC::DFG::LazyJSValue::dump):
* dfg/DFGLazyJSValue.h:
(JSC::DFG::LazyJSValue::knownStringImpl):
(LazyJSValue):
(JSC::DFG::LazyJSValue::stringImpl):
(JSC::DFG::LazyJSValue::switchLookupValue):
* dfg/DFGNode.cpp:
(WTF::printInternal):
* dfg/DFGNode.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchChar):
(JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
(DFG):
(JSC::DFG::SpeculativeJIT::emitBinarySwitchStringRecurse):
(JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
(JSC::DFG::SpeculativeJIT::emitSwitchString):
(JSC::DFG::SpeculativeJIT::emitSwitch):
(JSC::DFG::SpeculativeJIT::addBranch):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(JSC::DFG::SpeculativeJIT::branch8):
(SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::StringSwitchCase::StringSwitchCase):
(StringSwitchCase):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileSwitch):
* runtime/Options.h:
(JSC):
2013-06-24 Filip Pizlo <fpizlo@apple.com>
fourthTier: Count external memory usage towards heap footprint
https://bugs.webkit.org/show_bug.cgi?id=117948
Reviewed by Geoffrey Garen.
Currently just count strings. Strings get counted in such a way that we won't re-count strings
that are aliased, by dividing by the reference count. This then ups the GC footprint and allows
the collector to appropriately amortize itself.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::size):
(JSC::Heap::collect):
* heap/Heap.h:
(Heap):
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryUsage):
(JSC):
* runtime/JSString.cpp:
(JSC::JSString::visitChildren):
2013-06-23 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should optimize identifier string equality
https://bugs.webkit.org/show_bug.cgi?id=117920
Reviewed by Sam Weinig.
This is a 20% speed-up for string equality comparisons when both strings are
identifiers.
This is important for two reasons:
1) Using strings as enumerations is an idiom. A great example is typeof. It
would be great if this performed better.
2) When I implement switch_string in the DFG, it would be great to optimize
the case where the switched-on value is an identifier. That would involve
a simple binary switch rather than a more complicated trie-switch over
characters.
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
(JSC::speculationToAbbreviatedString):
(JSC::speculationFromCell):
* bytecode/SpeculatedType.h:
(JSC):
(JSC::isStringIdentSpeculation):
(JSC::isStringSpeculation):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateStringIdent):
(Node):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
(JSC::DFG::SpeculativeJIT::compare):
(JSC::DFG::SpeculativeJIT::compileStrictEq):
(JSC::DFG::SpeculativeJIT::compileStringEquality):
(JSC::DFG::SpeculativeJIT::compileStringIdentEquality):
(DFG):
(JSC::DFG::SpeculativeJIT::speculateString):
(JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
(JSC::DFG::SpeculativeJIT::speculateStringIdent):
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::isCell):
2013-06-22 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG shouldn't exit just because a String GetByVal went out-of-bounds
https://bugs.webkit.org/show_bug.cgi?id=117906
Reviewed by Mark Hahnenberg.
This does the obvious thing, but also makes sure that out-of-bounds accesses
don't fall off into a C call, but try to do the fast thing if the prototype
chain is sane. We ought to probably do this for other array accesses in the
future, as well, since it's so darn easy.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::objectPrototypeIsSane):
(JSC):
(JSC::JSGlobalObject::arrayPrototypeChainIsSane):
(JSC::JSGlobalObject::stringPrototypeChainIsSane):
* runtime/JSGlobalObject.h:
(JSGlobalObject):
2013-06-22 Filip Pizlo <fpizlo@apple.com>
fourthTier: GC's put_by_id transition fixpoint should converge more quickly
https://bugs.webkit.org/show_bug.cgi?id=117912
Reviewed by Mark Hahnenberg.
This was a rookie mistake. The GC does a classic forward data flow fixpoint. These work well so long as you
iterate the program in program order, or at least something close to program order. Because I enjoy reverse
loops ("while (n--) blah"), I ended up iterating in *reverse* of program order which ensured worst-case
pathologies every single time. And unsurprisingly, this slowed down a program, namely pdfjs.
Flipping the loops to iterate forward fixes a 90% regression in Octane/pdfjs and is otherwise neutral.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::propagateTransitions):
2013-06-21 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should CSE MakeRope
https://bugs.webkit.org/show_bug.cgi?id=117905
Reviewed by Geoffrey Garen.
Adds MakeRope to the CSE phase and removes the comment that says that
we could do it but aren't doing it.
Also fixed SpeculatedType dumping so that if you have a Cell type then
it just prints "Cell" and if you just have Object then it just prints
"Object", instead of printing the long list of types.
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::performNodeCSE):
2013-06-21 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should't exit just because it GetByVal'd a big character
https://bugs.webkit.org/show_bug.cgi?id=117899
Reviewed by Mark Hahnenberg.
Add a slow path. Also clarify handling of GetByVal in PutStructure elimination.
Previously it would fail due to canExit() but now we can also fail because
GetByVal(String) can allocate. Just make it so GetByVal is totally poisoned, in
a very explicit way.
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::putStructureStoreElimination):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(SpeculativeJIT):
2013-06-21 Filip Pizlo <fpizlo@apple.com>
fourthTier: Small strings shouldn't get GC'd
https://bugs.webkit.org/show_bug.cgi?id=117897
Reviewed by Mark Hahnenberg.
Kill off the code needed to allocate them lazily and finalize them.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
* heap/Heap.cpp:
(JSC::Heap::collect):
* runtime/JSString.h:
(JSC::jsSingleCharacterString):
(JSC::jsSingleCharacterSubstring):
(JSC::jsString):
(JSC::jsSubstring8):
(JSC::jsSubstring):
(JSC::jsOwnedString):
* runtime/NumberPrototype.cpp:
(JSC::integerValueToString):
* runtime/SmallStrings.cpp:
(JSC):
(JSC::SmallStrings::initializeCommonStrings):
(JSC::SmallStrings::visitStrongReferences):
* runtime/SmallStrings.h:
(JSC::SmallStrings::singleCharacterString):
(SmallStrings):
2013-06-20 Filip Pizlo <fpizlo@apple.com>
fourthTier: Structure should have a dump()
https://bugs.webkit.org/show_bug.cgi?id=117859
Reviewed by Geoffrey Garen.
This is pretty cool. Anywhere we previously printed Structure pointers in dumps,
we now print a bunch of other info as well. For example, for an object literal
like "{f:42, g:64, h:24}", when we print the structure we'll now get:
0x107a0af80:[Object, {f:0, g:1, h:2}, NonArray, Proto:0x107a8fff0]
This also changes a bunch of places to use the dump method.
* bytecode/StructureSet.h:
(JSC::StructureSet::dump):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::dump):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dump):
* runtime/Structure.cpp:
(JSC::Structure::dump):
(JSC):
* runtime/Structure.h:
(Structure):
2013-06-20 Filip Pizlo <fpizlo@apple.com>
fourthTier: There should only be one table of SimpleJumpTables
https://bugs.webkit.org/show_bug.cgi?id=117856
Reviewed by Geoffrey Garen.
Having multiple tables of SimpleJumpTables just means we have to duplicate a
ton of code. This patch deduplicates all of it.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::shrinkToFit):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfSwitchJumpTables):
(JSC::CodeBlock::addSwitchJumpTable):
(JSC::CodeBlock::switchJumpTable):
(JSC::CodeBlock::clearSwitchJumpTables):
(RareData):
* bytecode/PreciseJumpTargets.cpp:
(JSC):
(JSC::computePreciseJumpTargets):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::shrinkToFit):
(JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables):
(JSC::UnlinkedCodeBlock::addSwitchJumpTable):
(JSC::UnlinkedCodeBlock::switchJumpTable):
(RareData):
* bytecompiler/BytecodeGenerator.cpp:
(JSC):
(JSC::prepareJumpTableForSwitch):
(JSC::BytecodeGenerator::endSwitch):
* dfg/DFGByteCodeParser.cpp:
(InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JITCompiler):
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
(DFG):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2013-06-20 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should clear character switch jump tables
https://bugs.webkit.org/show_bug.cgi?id=117852
Reviewed by Sam Weinig.
The FTL just uses LLVM's switch, which results in LLVM allocating its own switch
jump tables as needed.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::clearCharacterSwitchJumpTables):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
2013-06-20 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support SwitchChar
https://bugs.webkit.org/show_bug.cgi?id=117849
Reviewed by Geoffrey Garen.
This adds Switch(SwitchChar) to the FTL and also implicitly does some other things.
SwitchChar requires calling a slow path to resolve ropes. Previously the FTL had no
support for calling slow paths, and we avoided adding coverage that would require
that. Well, this patch adds the ability to call slow paths and just uses that for
resolving ropes for SwitchChar. Also SwitchChar required adding awareness of strings,
so I did that, too.
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::addCodeOrigin):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGNode.cpp:
(WTF):
(WTF::printInternal):
* dfg/DFGNode.h:
(WTF):
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* ftl/FTLAbbreviations.h:
(JSC::FTL::int16Type):
(JSC::FTL::constInt):
* ftl/FTLAbstractHeapRepository.h:
(FTL):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
* ftl/FTLCommonValues.h:
(CommonValues):
* ftl/FTLIntrinsicRepository.cpp:
(JSC::FTL::IntrinsicRepository::IntrinsicRepository):
(FTL):
* ftl/FTLIntrinsicRepository.h:
(FTL):
(IntrinsicRepository):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
(JSC::FTL::LowerDFGToLLVM::compileJump):
(JSC::FTL::LowerDFGToLLVM::compileBranch):
(JSC::FTL::LowerDFGToLLVM::compileSwitch):
(JSC::FTL::LowerDFGToLLVM::buildSwitch):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lowString):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::isObject):
(JSC::FTL::LowerDFGToLLVM::isNotString):
(JSC::FTL::LowerDFGToLLVM::isString):
(JSC::FTL::LowerDFGToLLVM::isNotObject):
(JSC::FTL::LowerDFGToLLVM::speculateObject):
(JSC::FTL::LowerDFGToLLVM::speculateString):
(JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
(JSC::FTL::LowerDFGToLLVM::vmCall):
(JSC::FTL::LowerDFGToLLVM::callPreflight):
(JSC::FTL::LowerDFGToLLVM::callCheck):
(JSC::FTL::LowerDFGToLLVM::lowBlock):
* ftl/FTLOutput.h:
(JSC::FTL::Output::constBool):
(JSC::FTL::Output::constInt8):
(JSC::FTL::Output::constInt32):
(JSC::FTL::Output::constIntPtr):
(JSC::FTL::Output::constInt64):
(JSC::FTL::Output::load16):
(JSC::FTL::Output::isNull):
(JSC::FTL::Output::notNull):
(JSC::FTL::Output::testIsZero32):
(JSC::FTL::Output::testNonZero32):
(Output):
(JSC::FTL::Output::operation):
(JSC::FTL::Output::crash):
2013-06-18 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should have switch_char
https://bugs.webkit.org/show_bug.cgi?id=117710
Reviewed by Michael Saboff.
Add op_switch_char. Most of this is fairly simple, except for the whole
LazyJSValue thing.
It's long been the case that anytime you wanted the DFG to speak of a string
that didn't appear in the constant pool, you would have a hard time since
the DFG isn't allowed to allocate in the GC heap. For example, if you know
that you want to speak of a single character string, you might find that
the one you wanted to speak of had been GC'd. Another example is if you
wanted to add constant folding for string concatenation - something we don't
have yet but will want eventually.
I solve this by finally adding the notion of LazyJSValue. In the future I
anticipate using this for a variety of string-related things. The idea here
is that the DFG can either say that it already knows what the value is, or
it can describe the value. For example, in this patch I needed to be able to
describe single-character strings.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
* bytecode/JumpTable.h:
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::run):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGPRInfo.h:
(JSC::DFG::JSValueRegs::payloadGPR):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::jumpTable):
(DFG):
(JSC::DFG::JITCompiler::numberOfJumpTables):
(JSC::DFG::JITCompiler::linkSwitches):
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JITCompiler):
* dfg/DFGLazyJSValue.cpp: Added.
(DFG):
(JSC::DFG::LazyJSValue::getValue):
(JSC::DFG::equalToSingleCharacter):
(JSC::DFG::LazyJSValue::strictEqual):
(JSC::DFG::LazyJSValue::dump):
* dfg/DFGLazyJSValue.h: Added.
(DFG):
(LazyJSValue):
(JSC::DFG::LazyJSValue::LazyJSValue):
(JSC::DFG::LazyJSValue::singleCharacterString):
(JSC::DFG::LazyJSValue::tryGetValue):
(JSC::DFG::LazyJSValue::value):
(JSC::DFG::LazyJSValue::character):
(JSC::DFG::LazyJSValue::switchLookupValue):
* dfg/DFGNode.h:
(JSC::DFG::SwitchCase::SwitchCase):
(SwitchCase):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
(JSC::DFG::SpeculativeJIT::emitSwitchImmIntJump):
(DFG):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
(JSC::DFG::SpeculativeJIT::emitSwitchChar):
(JSC::DFG::SpeculativeJIT::emitSwitch):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
2013-06-19 Mark Hahnenberg <mhahnenberg@apple.com>
Refactor ObjCCallbackFunction to inherit directly from InternalFunction
https://bugs.webkit.org/show_bug.cgi?id=117595
Reviewed by Geoffrey Garen.
* API/APICallbackFunction.h: Added. New struct that allows JSCallbackFunction and
ObjCCallbackFunction to share their host call() implementation through the magic of
templates.
(JSC::APICallbackFunction::call):
* API/JSCallbackFunction.cpp:
(JSC::JSCallbackFunction::getCallData): Changed to get the template-ized version of
the host function.
* API/JSCallbackFunction.h:
* API/ObjCCallbackFunction.h: Now inherits directly from InternalFunction.
* API/ObjCCallbackFunction.mm:
(JSC::ObjCCallbackFunction::ObjCCallbackFunction):
(JSC::ObjCCallbackFunction::getCallData): Ditto.
* GNUmakefile.list.am: Build files!
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
2013-06-19 Michael Saboff <msaboff@apple.com>
fourthTier: Arity fixup should be done while on same stack
https://bugs.webkit.org/show_bug.cgi?id=117102
Reviewed by Oliver Hunt.
Removed the fixup part of op_call_arityCheck() and op_construct_arityCheck() and moved it to
a thunk for the JITs and as assembly for the llint. This patch provides the plumbing needed to
move to the C stack for JS execution. The fixup thunk and llint code would need to be change to
work with a stack that grows down when we do move to the C stack.
Due to an issue with the offline assembler, I moved the const at the top of LowLevelInterpreter64.asm
and LowLevelInterpreter32_64.asm to LowLevelInterpreter.asm. The problem is that a const defined in
one file that are used in a macro doesn't resolve the const if the macro is used in another file. This
seemed like the quickest path.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::linkFunction):
* dfg/DFGJITCompiler.h:
(JITCompiler):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* jit/JITStubs.h:
* jit/ThunkGenerators.cpp:
(JSC::arityFixup):
* jit/ThunkGenerators.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::arityCheckFor):
2013-06-19 Michael Saboff <msaboff@apple.com>
FTL: arm build is broken in ToT
https://bugs.webkit.org/show_bug.cgi?id=117800
Unreviewed build fixes.
* assembler/ARMv7Assembler.h:
(ARMv7Assembler): Merge of r147941
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_op_mod): Moved variable declaration back inside #ifdef where used.
2013-06-17 Michael Saboff <msaboff@apple.com>
FTL: Add another temp register regT4 to JSInterfaceJIT
https://bugs.webkit.org/show_bug.cgi?id=117719
Reviewed by Geoffrey Garen.
Made the dedicated bucketCounterRegister to be regT4 and then used regT4 wherever
bucketCounterRegister had been used. Since it is masked whenever it is used and
we are looking for some randomness in the register anyway, we can use it without
any issues.
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
(JSC::JIT::emitValueProfilingSite):
* jit/JITCall.cpp:
(JSC::JIT::emitPutCallResult):
* jit/JITCall32_64.cpp:
(JSC::JIT::emitPutCallResult):
* jit/JITInlines.h:
(JSC::JIT::emitValueProfilingSite):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_get_callee):
(JSC::JIT::emit_op_get_argument_by_val):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_get_callee):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_get_argument_by_val):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
* jit/JITStubCall.h:
(JSC::JITStubCall::callWithValueProfiling):
* jit/JSInterfaceJIT.h:
(JSInterfaceJIT):
2013-06-17 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support Switch
https://bugs.webkit.org/show_bug.cgi?id=117704
Reviewed by Oliver Hunt.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::clearImmediateSwitchJumpTables):
* ftl/FTLAbbreviations.h:
(JSC::FTL::buildFPToSI):
(JSC::FTL::buildSwitch):
(JSC::FTL::addCase):
(FTL):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileSwitch):
(LowerDFGToLLVM):
* ftl/FTLOutput.h:
(JSC::FTL::Output::fpToInt):
(JSC::FTL::Output::fpToInt32):
(Output):
(JSC::FTL::Output::switchInstruction):
* ftl/FTLSwitchCase.h: Added.
(FTL):
(SwitchCase):
(JSC::FTL::SwitchCase::SwitchCase):
(JSC::FTL::SwitchCase::value):
(JSC::FTL::SwitchCase::target):
2013-06-15 Filip Pizlo <fpizlo@apple.com>
fourthTier: Add CFG simplification for Switch
https://bugs.webkit.org/show_bug.cgi?id=117677
Reviewed by Mark Hahnenberg.
This is for completeness. It only speeds up a microbenchmark at this point.
Broadly, we want all control constructs to be known to the CFG simplifier.
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::run):
(JSC::DFG::CFGSimplificationPhase::convertToJump):
(CFGSimplificationPhase):
(JSC::DFG::CFGSimplificationPhase::noBlocks):
(JSC::DFG::CFGSimplificationPhase::oneBlock):
(JSC::DFG::CFGSimplificationPhase::mergeBlocks):
* runtime/JSCJSValue.h:
(JSValue):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::pureStrictEqual):
(JSC):
2013-06-13 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should support op_switch_imm
https://bugs.webkit.org/show_bug.cgi?id=117559
Reviewed by Oliver Hunt.
Implement integer (i.e. immediate) switches in the DFG. Reduce the minimum
threshold for using op_switch.
Also get rid of edge code support, since we haven't used it in the year since
I introduced it. It was supposed to allow us to break critical edges late in
the backend, thus enabling global register allocation from an SSA-form graph.
But we aren't doing that so I figure we should just kill the code for now. It
would have made implementing switch harder.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::timesPtr):
* assembler/MacroAssemblerCodeRef.h:
(JSC::MacroAssemblerCodePtr::dumpWithName):
(MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::dump):
(MacroAssemblerCodeRef):
(JSC::MacroAssemblerCodeRef::dump):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::shrinkToFit):
* bytecode/JumpTable.h:
(SimpleJumpTable):
(JSC::SimpleJumpTable::clear):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
(JSC::DFG::AbstractState::mergeToSuccessors):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::linkBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGCommon.h:
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::determineReachability):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JITCompiler):
(JSC::DFG::JITCompiler::blockHeads):
* dfg/DFGNode.h:
(DFG):
(JSC::DFG::SwitchCase::SwitchCase):
(SwitchCase):
(SwitchData):
(JSC::DFG::SwitchData::SwitchData):
(Node):
(JSC::DFG::Node::isSwitch):
(JSC::DFG::Node::isTerminal):
(JSC::DFG::Node::switchData):
(JSC::DFG::Node::numSuccessors):
(JSC::DFG::Node::successor):
* dfg/DFGNodeType.h:
(DFG):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::createOSREntries):
(JSC::DFG::SpeculativeJIT::emitSwitchImmIntJump):
(DFG):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitch):
(JSC::DFG::SpeculativeJIT::linkBranches):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::branchDouble):
(JSC::DFG::SpeculativeJIT::branchDoubleNonZero):
(JSC::DFG::SpeculativeJIT::branch32):
(JSC::DFG::SpeculativeJIT::branchTest32):
(JSC::DFG::SpeculativeJIT::branch64):
(JSC::DFG::SpeculativeJIT::branchPtr):
(JSC::DFG::SpeculativeJIT::branchTestPtr):
(JSC::DFG::SpeculativeJIT::branchTest8):
(JSC::DFG::SpeculativeJIT::jump):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* parser/Nodes.h:
(CaseBlockNode):
2013-06-15 Filip Pizlo <fpizlo@apple.com>
Concurrent JIT shouldn't try to recompute the CodeBlockHash as part of debug dumps, since doing so may fail if dealing with a CachedScript that doesn't have its script string handy
https://bugs.webkit.org/show_bug.cgi?id=117676
Reviewed by Sam Weinig.
CodeBlock now caches m_hash, and the DFG Driver will force its computation if we're doing debug dumps of any kind.
Also made sure that CodeBlock::CodeBlock initializes all of its fields; it was previously missing the
initialization of m_capabilityLevelState.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::hash):
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
(CodeBlock):
* bytecode/CodeBlockHash.cpp:
(JSC::CodeBlockHash::CodeBlockHash):
* bytecode/CodeBlockHash.h:
(CodeBlockHash):
(JSC::CodeBlockHash::isSet):
(JSC::CodeBlockHash::operator!):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
2013-06-11 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should support op_in and it should use patching to make it fast
https://bugs.webkit.org/show_bug.cgi?id=117385
Reviewed by Geoffrey Garen.
Implement op_in in the DFG and give it patching. The code we generate is just
a jump on the hot path, and the slow paths generate stubs and link the jump to
them. I didn't want to bother with patching structures and load offsets and
the like, although I probably could have.
This is a ginormous speed-up on microbenchmarks for "in", obviously.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpAssumingJITType):
(JSC::CodeBlock::resetStubInternal):
(JSC::structureStubInfoLessThan):
(JSC):
(JSC::CodeBlock::sortStructureStubInfos):
* bytecode/CodeBlock.h:
(CodeBlock):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::deref):
(JSC::StructureStubInfo::visitWeakReferences):
* bytecode/StructureStubInfo.h:
(JSC::isInAccess):
(JSC):
(StructureStubInfo):
(JSC::StructureStubInfo::initInList):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCCallHelpers.h:
(JSC::DFG::CCallHelpers::setupResults):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGPRInfo.h:
(JSC::DFG::JSValueRegs::payloadOnly):
(JSValueRegs):
(JSC::DFG::JSValueRegs::JSValueRegs):
(JSC::DFG::JSValueRegs::operator!):
(JSC::DFG::JSValueSource::operator!):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JSC::DFG::InRecord::InRecord):
(InRecord):
(DFG):
(JITCompiler):
(JSC::DFG::JITCompiler::addIn):
* dfg/DFGNodeType.h:
(DFG):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryRepatchIn):
(DFG):
(JSC::DFG::dfgRepatchIn):
(JSC::DFG::dfgResetIn):
* dfg/DFGRepatch.h:
(DFG):
(JSC::DFG::dfgResetIn):
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
(JSC::DFG::CallSlowPathGenerator::tearDown):
(JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::generateInternal):
(JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::generateInternal):
(JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::generateInternal):
(JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::generateInternal):
(JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::generateInternal):
(JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::generateInternal):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
(DFG):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::extractResult):
(DFG):
(SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::callOperation):
(JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult):
(JSC::DFG::SpeculativeJIT::appendCallSetResult):
(JSC::DFG::JSValueOperand::tagGPR):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dump):
* runtime/JSString.h:
(JSString):
(JSC::JSString::tryGetValueImpl):
(JSC):
* runtime/Operations.h:
(JSC::normalizePrototypeChainForChainAccess):
2013-06-12 Geoffrey Garen <ggaren@apple.com>
The Math object should not be polymorphic
https://bugs.webkit.org/show_bug.cgi?id=117576
Reviewed by Oliver Hunt.
Fill in the Math object eagerly, to avoid its structure changing during
execution. There are lots of ways to skin this cat; this one seemed
easiest, and justified given the relative hotness of math operations.
20% speedup on DSP-filtrr tests, small speedups on a few Kraken tests.
* DerivedSources.make:
* JavaScriptCore.order:
* create_hash_table:
* interpreter/CallFrame.h:
(JSC::ExecState::jsonTable): Removed the Math object's static table.
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectNativeFunctionWithoutTransition):
* runtime/JSObject.h:
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
* runtime/MathObject.h:
(JSC::MathObject::create): Set up the Math object at construction time.
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
* runtime/VM.h: Removed the Math object's static table.
2013-06-09 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolled back in http://trac.webkit.org/changeset/151342.
I filled in the missing return register loads, and tests
seem to pass now.
2013-06-07 Michael Saboff <msaboff@apple.com>
fourthTier: The baseline jit and LLint should use common slow paths
https://bugs.webkit.org/show_bug.cgi?id=116889
2013-06-07 Filip Pizlo <fpizlo@apple.com>
Unreviewed, roll out http://trac.webkit.org/changeset/151342
It broke Kraken crypto tests in debug build. That results in a pretty bad
loss of test coverage.
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JIT.cpp:
(JSC):
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
(JIT):
* jit/JITArithmetic.cpp:
(JSC::JIT::emitSlow_op_negate):
(JSC::JIT::emitSlow_op_lshift):
(JSC::JIT::emitSlow_op_rshift):
(JSC::JIT::emitSlow_op_urshift):
(JSC::JIT::emitSlow_op_bitand):
(JSC::JIT::emitSlow_op_inc):
(JSC::JIT::emitSlow_op_dec):
(JSC::JIT::emitSlow_op_mod):
(JSC::JIT::emit_op_mod):
(JSC::JIT::compileBinaryArithOpSlowCase):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emitSlow_op_mul):
(JSC::JIT::emitSlow_op_div):
(JSC::JIT::emitSlow_op_sub):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emitSlow_op_negate):
(JSC::JIT::emitSlow_op_lshift):
(JSC::JIT::emitRightShiftSlowCase):
(JSC::JIT::emitSlow_op_bitand):
(JSC::JIT::emitSlow_op_bitor):
(JSC::JIT::emitSlow_op_bitxor):
(JSC::JIT::emitSlow_op_inc):
(JSC::JIT::emitSlow_op_dec):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emitSlow_op_sub):
(JSC::JIT::emitSlow_op_mul):
(JSC::JIT::emitSlow_op_div):
(JSC::JIT::emit_op_mod):
(JSC::JIT::emitSlow_op_mod):
* jit/JITExceptions.cpp:
(JSC):
(JSC::genericThrow):
* jit/JITExceptions.h:
(ExceptionHandler):
(JSC):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_strcat):
(JSC::JIT::emitSlow_op_create_this):
(JSC::JIT::emitSlow_op_to_this):
(JSC::JIT::emitSlow_op_to_primitive):
(JSC::JIT::emitSlow_op_not):
(JSC::JIT::emitSlow_op_bitxor):
(JSC::JIT::emitSlow_op_bitor):
(JSC::JIT::emitSlow_op_stricteq):
(JSC::JIT::emitSlow_op_nstricteq):
(JSC::JIT::emitSlow_op_to_number):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileCTINativeCall):
(JSC::JIT::emitSlow_op_to_primitive):
(JSC::JIT::emit_op_strcat):
(JSC::JIT::emitSlow_op_not):
(JSC::JIT::emitSlow_op_stricteq):
(JSC::JIT::emitSlow_op_nstricteq):
(JSC::JIT::emitSlow_op_to_number):
(JSC::JIT::emit_op_create_arguments):
(JSC::JIT::emitSlow_op_create_this):
(JSC::JIT::emitSlow_op_to_this):
(JSC::JIT::emitSlow_op_get_argument_by_val):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
(JSC):
* jit/JITStubs.h:
(JSC):
* jit/JITStubsARM.h:
(JSC):
* jit/JITStubsARMv7.h:
(JSC):
* jit/JITStubsMIPS.h:
(JSC):
* jit/JITStubsSH4.h:
(JSC):
* jit/JITStubsX86.h:
(JSC):
* jit/JITStubsX86_64.h:
(JSC):
* jit/JSInterfaceJIT.h:
(JSInterfaceJIT):
* jit/SlowPathCall.h: Removed.
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(LLInt):
* llint/LLIntSlowPaths.h:
(LLInt):
(SlowPathReturnType):
(JSC::LLInt::encodeResult):
(JSC::LLInt::decodeResult):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp: Removed.
* runtime/CommonSlowPaths.h:
* runtime/JSCJSValue.h:
(JSValue):
2013-06-07 Michael Saboff <msaboff@apple.com>
fourthTier: The baseline jit and LLint should use common slow paths
https://bugs.webkit.org/show_bug.cgi?id=116889
Reviewed by Filip Pizlo.
Moved the llint_slow_paths that return JSValue along with several others to CommonSlowPaths.cpp.
Eliminated the related JIT stubs. Changes the baseline JIT to call these new common stubs.
Added a simple slow path call class that uses argument registers or the stack instead of
JITStackFrame. Changes the exception mechanism for to check for an exception after making
a slowpath call instead of returning to the handler directly form the slowpath function.
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
(JIT):
* jit/JITArithmetic.cpp:
(JSC::JIT::emitSlow_op_negate):
(JSC::JIT::emitSlow_op_lshift):
(JSC::JIT::emitSlow_op_rshift):
(JSC::JIT::emitSlow_op_urshift):
(JSC::JIT::emitSlow_op_bitand):
(JSC::JIT::emitSlow_op_inc):
(JSC::JIT::emitSlow_op_dec):
(JSC::JIT::emitSlow_op_mod):
(JSC::JIT::emit_op_mod):
(JSC::JIT::compileBinaryArithOpSlowCase):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emitSlow_op_mul):
(JSC::JIT::emitSlow_op_div):
(JSC::JIT::emitSlow_op_sub):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emitSlow_op_negate):
(JSC::JIT::emitSlow_op_lshift):
(JSC::JIT::emitRightShiftSlowCase):
(JSC::JIT::emitSlow_op_bitand):
(JSC::JIT::emitSlow_op_bitor):
(JSC::JIT::emitSlow_op_bitxor):
(JSC::JIT::emitSlow_op_inc):
(JSC::JIT::emitSlow_op_dec):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emitSlow_op_sub):
(JSC::JIT::emitSlow_op_mul):
(JSC::JIT::emitSlow_op_div):
(JSC::JIT::emit_op_mod):
(JSC::JIT::emitSlow_op_mod):
* jit/JITExceptions.cpp:
(JSC::getExceptionLocation):
(JSC::genericThrow):
(JSC::jitThrowNew):
* jit/JITExceptions.h:
(ExceptionHandler):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_strcat):
(JSC::JIT::emitSlow_op_create_this):
(JSC::JIT::emitSlow_op_to_this):
(JSC::JIT::emitSlow_op_to_primitive):
(JSC::JIT::emitSlow_op_not):
(JSC::JIT::emitSlow_op_bitxor):
(JSC::JIT::emitSlow_op_bitor):
(JSC::JIT::emitSlow_op_stricteq):
(JSC::JIT::emitSlow_op_nstricteq):
(JSC::JIT::emitSlow_op_to_number):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileCTINativeCall):
(JSC::JIT::emitSlow_op_to_primitive):
(JSC::JIT::emit_op_strcat):
(JSC::JIT::emitSlow_op_not):
(JSC::JIT::emitSlow_op_stricteq):
(JSC::JIT::emitSlow_op_nstricteq):
(JSC::JIT::emitSlow_op_to_number):
(JSC::JIT::emit_op_create_arguments):
(JSC::JIT::emitSlow_op_create_this):
(JSC::JIT::emitSlow_op_to_this):
(JSC::JIT::emitSlow_op_get_argument_by_val):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
(JSC::cti_vm_throw_slowpath):
* jit/JITStubs.h:
* jit/JITStubsARM.h:
* jit/JITStubsARMv7.h:
* jit/JITStubsMIPS.h:
* jit/JITStubsSH4.h:
* jit/JITStubsX86.h:
* jit/JITStubsX86_64.h:
* jit/JSInterfaceJIT.h:
(JSInterfaceJIT):
* jit/SlowPathCall.h: Added.
(JITSlowPathCall):
(JSC::JITSlowPathCall::JITSlowPathCall):
(JSC::JITSlowPathCall::call):
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* llint/LLIntSlowPaths.cpp:
(LLInt):
* llint/LLIntSlowPaths.h:
(LLInt):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp: Added.
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(SlowPathReturnType):
(JSC::encodeResult):
(JSC::decodeResult):
* runtime/JSCJSValue.h:
(JSValue):
2013-06-11 Geoffrey Garen <ggaren@apple.com>
Rolled back in <http://trac.webkit.org/changeset/151363>.
Rubber stamped by Phil Pizlo.
The ASSERTs were due to the bytecode parser performing a
StructureTransitionWatchpoint optimization in a case where the CFA
wouldn't because the CFA could prove that the watchpoint would contradict
a preceding CheckStructure.
I fixed this by removing the bytecode parser optimization: now, we fully
rely on CFA and constant folding to optimize structure checks when
possible.
I verified that there's no performance change vs doing the optimization
in the bytecode parser. (The optimization is very simple, so this is not
surprising.)
2013-06-10 Mark Hahnenberg <mhahnenberg@apple.com>
isContravenedByStructure is backwards
https://bugs.webkit.org/show_bug.cgi?id=117366
We should be checking if arrayModeForStructure(structure) is a
subset of arrayModesThatPassFiltering(), not the other way around.
Also renamed isContravenedByStructure to better reflect what the
function is trying to determine.
Rubber stamped by Filip Pizlo.
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::structureWouldPassArrayModeFiltering):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheckAccountingForArrayMode):
(JSC::DFG::ArrayTypeCheck::isContravenedByValue):
2013-06-10 Mark Hahnenberg <mhahnenberg@apple.com>
isContravenedByStructure is backwards
https://bugs.webkit.org/show_bug.cgi?id=117366
We should be checking if arrayModeForStructure(structure) is a
subset of arrayModesThatPassFiltering(), not the other way around.
Also renamed isContravenedByStructure to better reflect what the
function is trying to determine.
Rubber stamped by Filip Pizlo.
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::structureWouldPassArrayModeFiltering):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheckAccountingForArrayMode):
(JSC::DFG::ArrayTypeCheck::isContravenedByValue):
2013-06-11 Filip Pizlo <fpizlo@apple.com>
fourthTier: Type check hoisting phase has a dead if statement
https://bugs.webkit.org/show_bug.cgi?id=117510
Reviewed by Geoffrey Garen.
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
2013-06-10 Mark Lam <mark.lam@apple.com>
Introducing the StackIterator class.
https://bugs.webkit.org/show_bug.cgi?id=117390.
Reviewed by Geoffrey Garen.
The StackIterator class is meant to unify the way we iterate the JS
stack. It also makes it so that we don't have to copy the frame data
into the intermediate StackFrame struct before processing it.
Unfortunately we still can't get rid of StackFrame because it is used
to record frame information for the Exception stack that is expected
to persist beyond when the frames have been popped off the JS stack.
The StackIterator will iterate over all "logical" frames (i.e. including
inlined frames). As it iterates the JS stack, if it encounters a DFG
frame that has inlined frames, the iterator will canonicalize the
inlined frames before returning. Once canonicalized, the frame can be
read like any other frame.
The StackIterator implements a Frame class that inherits from CallFrame.
The StackIterator::Frame serves as reader of the CallFrame that makes
it easier to access information about the frame. The StackIterator::Frame
only adds functions, and no additional data fields.
* API/JSContextRef.cpp:
(JSContextCreateBacktrace):
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::begin):
(JSC::CallFrame::beginAt):
* interpreter/CallFrame.h:
(JSC::ExecState::setInlineCallFrame):
(ExecState):
(JSC::ExecState::end):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::dumpRegisters):
(JSC::Interpreter::unwindCallFrame):
(JSC::Interpreter::getStackTrace):
(JSC::Interpreter::throwException):
(JSC::Interpreter::debug):
* interpreter/Interpreter.h:
(Interpreter):
* interpreter/StackIterator.cpp: Added.
(JSC::StackIterator::StackIterator):
(JSC::StackIterator::beginAt):
(JSC::StackIterator::gotoNextFrame):
- Based on the deleted Interpreter::findFunctionCallFrameFromVMCode().
(JSC::StackIterator::findFrameForFunction):
- Based on the deleted Interpreter::retrieveCallerFromVMCode().
(JSC::StackIterator::Frame::codeType):
- Based on the deleted getStackFrameCodeType().
(JSC::StackIterator::Frame::functionName):
- Based on StackFrame::friendlyFunctionName().
(JSC::StackIterator::Frame::sourceURL):
- Based on StackFrame::friendlySourceURL().
(JSC::StackIterator::Frame::toString):
- Based on StackFrame::toString().
(JSC::StackIterator::Frame::bytecodeOffset):
(JSC::StackIterator::Frame::line):
- Based on StackFrame::line().
(JSC::StackIterator::Frame::column):
- Based on StackFrame::column().
(JSC::StackIterator::Frame::arguments):
- Based on the deleted Interpreter::retrieveArgumentsFromVMCode().
(JSC::StackIterator::Frame::retrieveExpressionInfo):
- Based on StackFrame::expressionInfo().
(JSC::StackIterator::Frame::logicalFrame):
- Based on the now deleted CallFrame::trueCallFrame().
(JSC::StackIterator::Frame::logicalCallerFrame):
- Based on the now deleted CallFrame::trueCallerFrame().
(JSC::jitTypeName):
(JSC::printIndents):
(JSC::printif):
(JSC::StackIterator::Frame::print):
(debugPrintCallFrame):
- Prints the contents of the frame for debugging purposes.
There are 2 versions that can be used as follows:
1. When you have a valid StackIterator, you can print
the current frame's content using the print instance
method:
iter->print(indentLevel);
2. When you have a CallFrame* that you want to dump from a debugger
console, you can print its content as follows:
(gdb) call debugPrintCallFrame(callFrame)
A sample of the output looks like this:
frame 0x1510c70b0 {
name 'shouldBe'
sourceURL 'testapi.js'
hostFlag 0
isInlinedFrame 0
callee 0x15154efb0
returnPC 0x10ed0786d
callerFrame 0x1510c7058
logicalCallerFrame 0x1510c7058
rawLocationBits 27 0x1b
codeBlock 0x7fe79b037200
bytecodeOffset 27 0x1b / 210
line 46
column 20
jitType 3 <BaselineJIT> isOptimizingJIT 0
hasCodeOrigins 0
}
* interpreter/StackIterator.h: Added.
(StackIterator::Frame):
(JSC::StackIterator::Frame::create):
(JSC::StackIterator::Frame::isJSFrame):
(JSC::StackIterator::Frame::callFrame):
* interpreter/StackIteratorPrivate.h: Added.
(StackIterator):
(JSC::StackIterator::operator*):
(JSC::StackIterator::operator->):
(JSC::StackIterator::operator==):
(JSC::StackIterator::operator!=):
(JSC::StackIterator::operator++):
(JSC::StackIterator::end):
(JSC::StackIterator::empty):
* jsc.cpp:
(functionJSCStack):
* profiler/ProfileGenerator.cpp:
(JSC::ProfileGenerator::addParentForConsoleStart):
* profiler/ProfileNode.h:
(ProfileNode):
* runtime/JSFunction.cpp:
(JSC::retrieveArguments):
(JSC::JSFunction::argumentsGetter):
(JSC::skipOverBoundFunctions):
(JSC::retrieveCallerFunction):
(JSC::JSFunction::callerGetter):
(JSC::JSFunction::getOwnPropertyDescriptor):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoGetter):
(JSC::globalFuncProtoSetter):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetPrototypeOf):
* runtime/Operations.h:
2013-06-09 Filip Pizlo <fpizlo@apple.com>
Marge trunk r146653.
2013-03-22 Filip Pizlo <fpizlo@apple.com>
DFG folding of PutById to SimpleReplace should consider the specialized function case
https://bugs.webkit.org/show_bug.cgi?id=113093
Reviewed by Geoffrey Garen and Mark Hahnenberg.
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
2013-06-09 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG GetById patching shouldn't distinguish between self lists and proto lists
https://bugs.webkit.org/show_bug.cgi?id=117377
Reviewed by Geoffrey Garen.
Previously if you did self accesses and then wanted to do a prototype access, you'd
have a bad time: the prototype accesses would be forced to take slow path because
the self list wouldn't allow prototype accesses. Likewise if you did prototype (or
chain) accesses and then wanted to do a self access, similar stupidity would ensue.
This fixes the stupidity.
I believe that this was introduced way back in the days of the old interpreter,
where distinguishing between self lists, proto lists, and chain lists was meaningful
for interpreter performance: it meant fewer branches to evaluate those lists. Then
it got mostly carried over to the old JIT since the old JIT was just initially an
optimized version of the old interpreter, and then later it got carried over to the
DFG because I didn't know any better at the time. Now I do know better and I'm
fixing it.
* bytecode/PolymorphicAccessStructureList.h:
(JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::set):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::initGetByIdSelfList):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryCacheGetByID):
(JSC::DFG::getPolymorphicStructureList):
(DFG):
(JSC::DFG::patchJumpToGetByIdStub):
(JSC::DFG::tryBuildGetByIDList):
(JSC::DFG::dfgBuildGetByIDList):
2013-06-09 Mark Lam <mark.lam@apple.com>
Fix broken no-DFG build.
https://bugs.webkit.org/show_bug.cgi?id=117381.
Reviewed by Geoffrey Garen.
* bytecode/CodeBlock.cpp:
* bytecode/CodeBlock.h:
(CodeBlock):
(ProgramCodeBlock):
(EvalCodeBlock):
(FunctionCodeBlock):
* dfg/DFGCapabilities.h:
* dfg/DFGDriver.h:
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGJITCode.cpp:
* dfg/DFGRepatch.h:
(JSC::DFG::dfgResetGetByID):
(JSC::DFG::dfgResetPutByID):
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::jettison):
* interpreter/CallFrame.h:
(ExecState):
(JSC::ExecState::trueCallFrame):
* interpreter/Interpreter.cpp:
(JSC::getCallerInfo):
* runtime/Executable.cpp:
* runtime/Executable.h:
(EvalExecutable):
(ProgramExecutable):
(FunctionExecutable):
* runtime/ExecutionHarness.h:
* runtime/VM.cpp:
(JSC::VM::~VM):
2013-06-08 Filip Pizlo <fpizlo@apple.com>
fourthTier: Recursive deadlock in DFG::ByteCodeParser
https://bugs.webkit.org/show_bug.cgi?id=117376
Reviewed by Mark Hahnenberg.
Leave the lock early to prevent a deadlock beneath get().
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2013-06-08 Mark Lam <mark.lam@apple.com>
Removed bogus assertion in CallFrame::setLocationAsBytecodeOffset().
https://bugs.webkit.org/show_bug.cgi?id=117373.
Reviewed by Oliver Hunt.
The assertion wrongly assumes that the incoming offset argument is in
units of bytes. This is not true. It is in units of Instruction*. Hence,
the assertion which checks for the low 2 bits to be clear can fail.
* interpreter/CallFrame.cpp:
(JSC::CallFrame::setLocationAsBytecodeOffset):
2013-06-07 Filip Pizlo <fpizlo@apple.com>
fourthTier: don't insert ForceOSRExits except for inadequate coverage
https://bugs.webkit.org/show_bug.cgi?id=117363
Reviewed by Mark Hahnenberg.
Previously (in http://trac.webkit.org/changeset/151303) I made it so that we
inserted ForceOSRExits more eagerly. I now think it's better to have
contradictions execute normally and exit with full OSR exit profiling. It's
better at catching the few cases where the DFG will end up with different
types than the baseline engines.
This simplifies a bunch of code. For example it gets rid of
ConstantFoldingPhase::paintUnreachableCode().
You can think of this as a partial roll-out of r151303, except that it uses
the facilities introduced by that patch to give us run-time assertions that
check the CFA's correctness: if the CFA thought that something was a
contradiction but the code didn't exit, we'll now trap.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::AbstractState):
(JSC::DFG::AbstractState::startExecuting):
(JSC::DFG::AbstractState::executeEffects):
(JSC::DFG::AbstractState::execute):
(JSC::DFG::AbstractState::filter):
(JSC::DFG::AbstractState::filterArrayModes):
(JSC::DFG::AbstractState::filterByValue):
(DFG):
* dfg/DFGAbstractState.h:
(AbstractState):
(JSC::DFG::AbstractState::filter):
(JSC::DFG::AbstractState::filterArrayModes):
(JSC::DFG::AbstractState::filterByValue):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::performBlockCFA):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::run):
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(ConstantFoldingPhase):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
2013-06-07 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix release build.
* ftl/FTLLink.cpp:
2013-06-06 Filip Pizlo <fpizlo@apple.com>
fourthTier: Reenable the DFG optimization fixpoint now that it's profitable to do so with concurrent compilation
https://bugs.webkit.org/show_bug.cgi?id=117331
Rubber stamped by Sam Weinig.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
2013-06-05 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG CFA should know when it hits a contradiction
https://bugs.webkit.org/show_bug.cgi?id=117272
Reviewed by Oliver Hunt.
This makes the DFG CFA immediately detect when it hit a contradiction. Previously
we might not know this: for example if we did an int32 type check on a known string;
the code would definitely always exit but the CFA would think that we wouldn't have
even though it would have computed a BOTTOM (i.e. contradictory) value for that
variable.
This requires two other changes:
- CFA must report contradictions as if they are frequent exit sites, since
contradictory speculations will subsequently get replaced with ForceOSRExit.
ForceOSRExit cannot itself report profiling data back to the DFG::ExitProfile. So,
we do this on behalf of the speculation, eagerly, within the CFA. This also has
the effect of speeding convergence somewhat. We may want to revisit this later;
for example we might want to instead have the notion of a ForceOSRExit that knows
the set of speculations that got folded into it.
- This revealed a bug where the CFA was modeling CheckStructure on a node that had
a known singleton m_futurePossibleStructure set somewhat differently than the
constant folder. If the CheckStructure was checking a structure set with two or
more structures in it, it would not filter the abstract value. But the constant
folder would turn this into a watchpoint on the singleton structure, thereby
filtering the value. This discrepancy meant that we wouldn't realize the
contradiction until the backend, and the AbstractState::bail() method asserts that
we always realize contradictions in the constant folder.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addFrequentExitSite):
(JSC::CodeBlock::hasExitSite):
(CodeBlock):
* bytecode/DFGExitProfile.cpp:
(JSC::DFG::ExitProfile::add):
(JSC::DFG::ExitProfile::hasExitSite):
(JSC::DFG::QueryableExitProfile::QueryableExitProfile):
(JSC::DFG::QueryableExitProfile::~QueryableExitProfile):
(DFG):
(JSC::DFG::QueryableExitProfile::initialize):
* bytecode/DFGExitProfile.h:
(JSC::DFG::FrequentExitSite::FrequentExitSite):
(ExitProfile):
(JSC::DFG::ExitProfile::hasExitSite):
(QueryableExitProfile):
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::AbstractState):
(JSC::DFG::AbstractState::beginBasicBlock):
(JSC::DFG::AbstractState::reset):
(JSC::DFG::AbstractState::startExecuting):
(JSC::DFG::AbstractState::executeEffects):
(JSC::DFG::AbstractState::execute):
(JSC::DFG::AbstractState::filter):
(DFG):
(JSC::DFG::AbstractState::filterArrayModes):
(JSC::DFG::AbstractState::filterByValue):
(JSC::DFG::AbstractState::bail):
* dfg/DFGAbstractState.h:
(AbstractState):
(JSC::DFG::AbstractState::filter):
(JSC::DFG::AbstractState::filterArrayModes):
(JSC::DFG::AbstractState::filterByValue):
(JSC::DFG::AbstractState::filterByType):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::filter):
(JSC::DFG::AbstractValue::filterArrayModes):
(DFG):
(JSC::DFG::AbstractValue::filterByValue):
(JSC::DFG::AbstractValue::normalizeClarity):
* dfg/DFGAbstractValue.h:
(AbstractValue):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::performBlockCFA):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::debugFail):
(JSC::DFG::capabilityLevel):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(ConstantFoldingPhase):
(JSC::DFG::ConstantFoldingPhase::paintUnreachableCode):
* dfg/DFGFiltrationResult.h: Added.
(DFG):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
(DFG):
* dfg/DFGOSRExitBase.cpp:
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::backwardTypeCheck):
(JSC::DFG::SpeculativeJIT::bail):
(DFG):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileToStringOnCell):
(JSC::DFG::SpeculativeJIT::speculateStringObject):
(JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::appendTypeCheck):
2013-06-07 Mark Lam <mark.lam@apple.com>
32-bit CallFrame::Location should use Instruction* for BytecodeLocation, not bytecodeOffset.
https://bugs.webkit.org/show_bug.cgi?id=117327.
Reviewed by Michael Saboff.
- Renamed CallFrame::Location's Type to TypeTag.
- Made the CallFrame::Location::TypeTag private, and provided type
specific encoder functions. This reduces verbosity in client code.
- Fixed the DFG's reifyInlinedCallFrames() on 32-bit ports to store a
bytecode Instruction* in the CallFrame location instead of a bytecode
offset.
- Fixed places in JIT and FTL code which populate the CallFrame location
(i.e. ArgumentCount tag) to use a Location encoder instead of storing
the bytecodeOffset directly. This doesn't make any semantic difference,
but it does assert that the stored value does not have bits where we
would expect Location TypeTags to be.
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::beginCall):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::setLocationAsBytecodeOffset):
* interpreter/CallFrame.h:
(Location):
* interpreter/CallFrameInlines.h:
(JSC::CallFrame::Location::encodeAsBytecodeOffset):
(JSC::CallFrame::Location::encodeAsBytecodeInstruction):
(JSC::CallFrame::Location::encodeAsCodeOriginIndex):
(JSC::CallFrame::Location::encodeAsInlinedCode):
(JSC::CallFrame::Location::isBytecodeLocation):
(JSC::CallFrame::setIsInlinedFrame):
(JSC::CallFrame::hasLocationAsBytecodeOffset):
(JSC::CallFrame::setLocationAsBytecodeOffset):
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileOpCall):
* jit/JITInlines.h:
(JSC::JIT::updateTopCallFrame):
2013-06-06 Mark Lam <mark.lam@apple.com>
Encode CallFrame::Location flags in the low bits when USE(JSVALUE32_64).
https://bugs.webkit.org/show_bug.cgi?id=117312.
Reviewed by Michael Saboff.
For USE(JSVALUE32_64), we store the location flags in the low 2 bits of
the word because we need the high bits for address bits.
* interpreter/CallFrame.cpp:
(JSC::CallFrame::setLocationAsBytecodeOffset):
* interpreter/CallFrame.h:
* interpreter/CallFrameInlines.h:
(JSC::CallFrame::Location::encode):
(JSC::CallFrame::Location::decode):
(JSC::CallFrame::Location::isCodeOriginIndex):
(JSC::CallFrame::Location::isInlinedCode):
2013-06-06 Mark Lam <mark.lam@apple.com>
CallFrame::trueCallFrame() should populate the bytecodeOffset field
when reifying inlined frames..
https://bugs.webkit.org/show_bug.cgi?id=117209.
Reviewed by Geoffrey Garen.
When reifying an inlined frame, we fill in its CodeBlock, and
bytecodeOffset. We also set the InlinedFrame bit in the location field.
This is needed in order to iterate the stack correctly. Here's why:
Let's say we have the following stack trace:
X calls A inlines B inlines C calls D
Based on the above scenario,
1. D's callerFrame points to A (not C).
2. A has a codeOriginIndex that points to C.
When iterating the stack (from D back towards X), we will encounter A
twice:
t1. when trying to find C as D's caller.
This is the time when we reify B and C using the
codeOriginIndex in A, and return C as the caller frame of D.
t2. when getting's the reified B's caller.
This time, we don't run the reification process, and
just take A as the caller frame of B.
To discern which treatment of the DFG frame (i.e. A) we need to apply,
we check if the callee is an inlined frame:
If callee is NOT an inlined frame (e.g. frame D), apply treatment t1.
If callee is an inlined frame (e.g. frame B), apply treatment t2.
Why not just reify A by replacing its codeOriginIndex with A's
bytecodeOffset?
We can't do this because D's callerFrame pointer still points to A, and
needs to remain that way because we did not deopt A. It remains a DFG
frame which inlined B and C.
If we replace the codeOriginIndex in A with A's bytecodeOffset, we will
only get to iterate the stack correctly once. If we try to iterate the
stack a second time, we will not have the information from the
codeOriginIndex to tell us that D's caller is actually the inlined C,
and not A.
To recap, when reifying frames for stack iteration purposes, the DFG
frame needs to hold on to its codeOriginIndex. This in turn means the
DFG frame will need to be treated in 2 possible ways, and we need to
know if a callee frame is an inlined frame in order to choose the
correct treatment for the DFG frame.
Other changes:
- Simplified Interpreter::getCallerInfo().
- Removed CodeBlock::codeOriginForReturn() and supporting code
which is now unneeded.
- Moved CallFrame location bit encoding from the CodeOrigin to the
new CallFrame::Location class.
- Explicitly tagged inlined frames. This is necessary in order to
iterate the stack correctly as explained above.
* bytecode/CodeBlock.cpp:
* bytecode/CodeBlock.h:
(JSC::CodeBlock::codeOrigins):
(CodeBlock):
(JSC::CodeBlock::codeOrigin):
(RareData):
* bytecode/CodeOrigin.h:
(CodeOrigin):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::beginCall):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::trueCallFrame):
(JSC::CallFrame::trueCallerFrame):
(JSC::CallFrame::bytecodeOffsetFromCodeOriginIndex):
* interpreter/CallFrame.h:
(Location):
(ExecState):
(JSC::ExecState::trueCallerFrame):
(JSC::ExecState::callerFrameNoFlags):
* interpreter/CallFrameInlines.h:
(JSC::CallFrame::Location::encode):
(JSC::CallFrame::Location::decode):
(JSC::CallFrame::Location::isBytecodeOffset):
(JSC::CallFrame::Location::isCodeOriginIndex):
(JSC::CallFrame::Location::isInlinedFrame):
(JSC::CallFrame::isInlinedFrame):
(JSC::CallFrame::setIsInlinedFrame):
(JSC::CallFrame::hasLocationAsBytecodeOffset):
(JSC::CallFrame::hasLocationAsCodeOriginIndex):
(JSC::CallFrame::locationAsBytecodeOffset):
(JSC::CallFrame::setLocationAsBytecodeOffset):
(JSC::CallFrame::locationAsCodeOriginIndex):
* interpreter/Interpreter.cpp:
(JSC::getCallerInfo):
(JSC::Interpreter::getStackTrace):
(JSC::Interpreter::findFunctionCallFrameFromVMCode):
* runtime/Arguments.cpp:
(JSC::Arguments::tearOff):
2013-06-05 Filip Pizlo <fpizlo@apple.com>
DFG CFA shouldn't filter ArrayModes with ALL_NON_ARRAY_ARRAY_MODES if the speculated type is not SpecArray
https://bugs.webkit.org/show_bug.cgi?id=117279
Reviewed by Mark Hahnenberg.
The normalization of abstract value clarity introduced in r151229 revealed a
long-standing bug where we filtered ArrayModes incorrectly and sometimes ended
up with BOTTOM incorrectly.
This patch fixes that bug, and cleans up a bunch of debugging infrastructure
that I needed to resurrect to track this down.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::resetStubInternal):
(JSC::CodeBlock::noticeIncomingCall):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::filterArrayModesByType):
* dfg/DFGCFAPhase.cpp:
(CFAPhase):
(JSC::DFG::CFAPhase::run):
(JSC::DFG::CFAPhase::performBlockCFA):
(JSC::DFG::CFAPhase::performForwardCFA):
* runtime/Options.h:
(JSC):
2013-06-05 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix release build.
* interpreter/Interpreter.cpp:
* jit/JITStubs.cpp:
2013-06-05 Mark Lam <mark.lam@apple.com>
Disambiguate between CallFrame bytecodeOffset and codeOriginIndex.
https://bugs.webkit.org/show_bug.cgi?id=117262.
Reviewed by Geoffrey Garen.
When writing to the ArgumentCount tag in CallFrame, we will set the high
bit if the written value is a codeOriginIndex.
* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeOrigin.h:
(CodeOrigin):
(JSC::CodeOrigin::isHandle):
(JSC::CodeOrigin::encodeHandle):
(JSC::CodeOrigin::decodeHandle):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::beginCall):
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryBuildGetByIDList):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::locationAsBytecodeOffset):
(JSC::CallFrame::setLocationAsBytecodeOffset):
(JSC::CallFrame::currentVPC):
(JSC::CallFrame::setCurrentVPC):
(JSC::CallFrame::trueCallFrame):
* interpreter/CallFrame.h:
(ExecState):
(JSC::ExecState::inlineCallFrame):
* interpreter/CallFrameInlines.h: Added.
(JSC::CallFrame::hasLocationAsBytecodeOffset):
(JSC::CallFrame::hasLocationAsCodeOriginIndex):
(JSC::CallFrame::locationAsRawBits):
(JSC::CallFrame::setLocationAsRawBits):
(JSC::CallFrame::locationAsBytecodeOffset):
(JSC::CallFrame::setLocationAsBytecodeOffset):
(JSC::CallFrame::locationAsCodeOriginIndex):
* interpreter/Interpreter.cpp:
(JSC::getBytecodeOffsetForCallFrame):
(JSC::getCallerInfo):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
2013-06-05 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix release build.
* interpreter/Interpreter.cpp:
* jit/JITStubs.cpp:
2013-06-04 Filip Pizlo <fpizlo@apple.com>
fourthTier: Clean up AbstractValue
https://bugs.webkit.org/show_bug.cgi?id=117217
Reviewed by Oliver Hunt.
This started as an attempt to make it so that when AbstractValue becomes empty,
its m_type always becomes SpecNone. I wanted this to happen naturally. That turns
out to be basically impossible, since AbstractValue is a set that is dynamically
computed from the intersection of several internal sets: so the value becomes
empty when any of the sets go empty. It's OK if we're imprecise here because it's
always safe for the AbstractValue to seem to overapproximate the set of values
that we see. So I mostly gave up on cleaning up that aspect of AbstractValue. But
while trying to make this happen, I encountered two bugs:
- filterValueByType() ignores the case when m_type contravenes m_value. Namely,
we might filter the AbstractValue against a SpeculatedType leading to m_value
becoming inconsistent with the new m_type. This change fixes that case. This
wasn't a symptomatic bug but it was a silly oversight.
- filterFuturePossibleStructure() was never right. The one call to this method,
in filter(Graph&, const StructureSet&), assumed that the previous notions of
what structures the value could have in the future were still relevant. This
could lead to a bug where we:
1) CheckStructure(@foo, S1)
Where S1 has a valid watchpoint. Now @foo's abstract value will have current
and future structure = S1.
2) Clobber the world.
Now @foo's abstract value will have current structure = TOP, and future
possible structure = S1.
3) CheckStructure(@foo, S2)
Now @foo's abstract value will have current structure = S2 and future
possible structure = S1 intersect S2 = BOTTOM.
Now we will think that any subsequent watchpoint on @foo is valid because the
value is effectively BOTTOM. That would only be correct if we had actually set
a watchpoint on S1. If we had done so, then (3) would only pass (i.e. @foo
would only have structure S2) if S1's watchpoint fired, in which case (3)
wouldn't have been reachable. But we didn't actually set a watchpoint on S1:
we just observed that we *could* have set the watchpoint. Hence future possible
structure should only be set to either the known structure at compile-time, or
it should be the structure we just checked; in both cases it should only be set
if the structure is watchable.
Then, in addition to all of this, I changed AbstractValue's filtering methods to
call clear() if the AbstractValue is effectively clear. This is just meant to
simplify the recognition of truly empty AbstractValues, but doesn't actually have
any other implications.
* bytecode/StructureSet.h:
(JSC::StructureSet::dump):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::filter):
(DFG):
(JSC::DFG::AbstractValue::filterArrayModes):
(JSC::DFG::AbstractValue::filterValueByType):
(JSC::DFG::AbstractValue::filterArrayModesByType):
(JSC::DFG::AbstractValue::shouldBeClear):
(JSC::DFG::AbstractValue::normalizeClarity):
(JSC::DFG::AbstractValue::checkConsistency):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::isClear):
(AbstractValue):
2013-06-04 Mark Lam <mark.lam@apple.com>
The DFG JIT should populate frame bytecodeOffsets on OSR exit.
https://bugs.webkit.org/show_bug.cgi?id=117103.
Reviewed by Geoffrey Garen.
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
2013-06-03 Filip Pizlo <fpizlo@apple.com>
fourthTier: all cached put_by_id transitions, even ones that weren't inlined by the DFG, should be propagated by the GC
https://bugs.webkit.org/show_bug.cgi?id=117170
Reviewed by Mark Hahnenberg.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitAggregate):
(JSC::CodeBlock::propagateTransitions):
(JSC):
(JSC::CodeBlock::determineLiveness):
(JSC::CodeBlock::visitWeakReferences):
(JSC::CodeBlock::finalizeUnconditionally):
* bytecode/CodeBlock.h:
(CodeBlock):
* bytecode/PolymorphicPutByIdList.h:
(JSC):
(PutByIdAccess):
(PolymorphicPutByIdList):
* bytecode/StructureStubInfo.h:
(StructureStubInfo):
* jit/JITCode.h:
(JSC::JITCode::couldBeInterpreted):
(JITCode):
2013-06-02 Filip Pizlo <fpizlo@apple.com>
fourthTier: Get rid of StructureStubInfo::bytecodeIndex
https://bugs.webkit.org/show_bug.cgi?id=117127
Reviewed by Mark Hahnenberg.
StructureStubInfo already has a CodeOrigin field, which also has a bytecodeIndex.
It makes sense to just always use the CodeOrigin.
* bytecode/StructureStubInfo.h:
(StructureStubInfo):
(JSC::getStructureStubInfoBytecodeIndex):
* jit/JIT.cpp:
(JSC::PropertyStubCompilationInfo::copyToStubInfo):
* jit/JIT.h:
(JSC::JIT::compileGetByIdProto):
(JSC::JIT::compileGetByIdSelfList):
(JSC::JIT::compileGetByIdProtoList):
(JSC::JIT::compileGetByIdChainList):
(JSC::JIT::compileGetByIdChain):
(JSC::JIT::compilePutByIdTransition):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompilePutByIdTransition):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::privateCompilePutByIdTransition):
2013-06-01 Filip Pizlo <fpizlo@apple.com>
Fix some minor issues in the DFG's profiling of heap accesses
https://bugs.webkit.org/show_bug.cgi?id=113010
Reviewed by Goeffrey Garen.
Carefully merge r146669 from trunk. This required some fiddling since it
wasn't a clean apply.
Original changelog:
1) If a CodeBlock gets jettisoned by GC, we should count the exit sites.
2) If a CodeBlock clears a structure stub during GC, it should record this, and
the DFG should prefer to not inline that access (i.e. treat it as if it had an
exit site).
3) If a PutById was seen by the baseline JIT, and the JIT attempted to cache it,
but it chose not to, then assume that it will take slow path.
4) If we frequently exited because of a structure check on a weak constant,
don't try to inline that access in the future.
5) Treat all exits that were counted as being frequent.
81% speed-up on Octane/gbemu. Small speed-ups elsewhere, and no regressions.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeUnconditionally):
(JSC):
(JSC::CodeBlock::resetStubDuringGCInternal):
(JSC::CodeBlock::reoptimize):
(JSC::CodeBlock::jettison):
(JSC::ProgramCodeBlock::jettisonImpl):
(JSC::EvalCodeBlock::jettisonImpl):
(JSC::FunctionCodeBlock::jettisonImpl):
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::tallyFrequentExitSites):
(ProgramCodeBlock):
(EvalCodeBlock):
(FunctionCodeBlock):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::StructureStubInfo):
(StructureStubInfo):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGOSRExitBase.cpp:
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
(OSRExitBase):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* runtime/Options.h:
(JSC):
2013-05-31 Filip Pizlo <fpizlo@apple.com>
Remove CodeOrigin::valueProfileOffset since it was only needed for op_call_put_result.
Rubber stamped by Mark Hahnenberg.
* bytecode/CodeOrigin.h:
(CodeOrigin):
(JSC::CodeOrigin::CodeOrigin):
(JSC::CodeOrigin::isSet):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::currentCodeOrigin):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::valueProfileFor):
2013-05-31 Filip Pizlo <fpizlo@apple.com>
Remove finalDestinationOrIgnored since it isn't called anymore.
Rubber stamped by Mark Hahnenberg.
* bytecompiler/BytecodeGenerator.h:
(BytecodeGenerator):
2013-05-31 Filip Pizlo <fpizlo@apple.com>
fourthTier: get rid of op_call_put_result
https://bugs.webkit.org/show_bug.cgi?id=117047
Reviewed by Gavin Barraclough.
op_call_put_result is an oddball. Its semantics are that it takes the return
value of a call instruction, which is set aside in regT0/regT1, and places them
into some stack slot. This is weird since there is an implicit contract with the
preceding bytecode instruction, and it's even weirder since it means that it
doesn't make sense to jump to it; for example OSR exit from the preceding call
instruction must make sure to jump over the op_call_put_result.
So this patch gets rid of op_call_put_result:
- In bytecode, all calls return a value and we always allocate a temporary for
that value even if it isn't used.
- The LLInt does the return value saving as part of dispatchAfterCall().
- The JIT and DFG do the return value saving as part of normal code generation.
The DFG already did the right thing.
- DFG->JIT OSR exit in the case of inlining will make the return PC's point at
the CallLinkInfo::callReturnLocation, rather than the machine PC associated
with the op_call_put_result instruction.
- Tons of code gets removed. The DFG had to track whether or not a call had a
return value in a bunch of places. It had to track the fact that we would
exit to after the op_call_put_result. It was a mess. That mess is now gone.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printCallOp):
(JSC::CodeBlock::dumpArrayProfiling):
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
* bytecode/Opcode.h:
(JSC):
(JSC::padOpcodeName):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallVarargs):
(JSC::BytecodeGenerator::emitConstruct):
* bytecompiler/NodesCodegen.cpp:
(JSC::NewExprNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionCallResolveNode::emitBytecode):
(JSC::FunctionCallBracketNode::emitBytecode):
(JSC::FunctionCallDotNode::emitBytecode):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::ByteCodeParser):
(ByteCodeParser):
(JSC::DFG::ByteCodeParser::currentCodeOrigin):
(JSC::DFG::ByteCodeParser::addCall):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::getPrediction):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleMinMax):
(JSC::DFG::ByteCodeParser::handleIntrinsic):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
(JIT):
* jit/JITCall.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::compileLoadVarargs):
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::emit_op_call):
(JSC):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_construct):
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_construct):
* jit/JITCall32_64.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::compileLoadVarargs):
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITOpcodes.cpp:
(JSC):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::genericCall):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.cpp:
(JSC::CLoop::execute):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2013-05-30 Filip Pizlo <fpizlo@apple.com>
fourthTier: LLInt shouldn't store an offset call PC during op_call-like calls
https://bugs.webkit.org/show_bug.cgi?id=117048
Reviewed by Mark Hahnenberg.
This just makes everything consistent in the LLInt: anytime any op calls out,
it stores its PC and never the next op's PC.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::linkIncomingCall):
(JSC::CodeBlock::bytecodeOffset):
* bytecode/CodeBlock.h:
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCallVarargs):
* llint/LLIntExceptions.cpp:
(JSC::LLInt::interpreterThrowInCaller):
(JSC::LLInt::returnToThrow):
(JSC::LLInt::callToThrow):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
(JSC::CLoop::execute):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2013-05-28 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support ArithAbs
https://bugs.webkit.org/show_bug.cgi?id=116890
Reviewed by Oliver Hunt.
Implements ArithAbs in the FTL, and cleans up the DFG implementation. The
DFG implementation was previously doing zero extensions manually when it
is probably better to just use StrictInt32Operand instead.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
(FTL):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileArithAbs):
(LowerDFGToLLVM):
* ftl/FTLOutput.h:
(JSC::FTL::Output::doubleAbs):
2013-05-28 Mark Lam <mark.lam@apple.com>
Misc JIT probe enhacements.
https://bugs.webkit.org/show_bug.cgi?id=116586.
Reviewed by Michael Saboff.
1. Added JIT probe support for ARMv7 and traditional ARM.
Built and tested on ARMv7. ARM version not tested nor built.
2. Fix the following bugs in the X86 and X86_64 probes:
a. Cannot assume that the stack pointer is already aligned when
we push args for the probe. Instead, we ensure the stack
alignment at runtime when we set up the probe call.
This is now done in the ctiMasmProbeTrampoline.
b. On return, the user probe function may have altered the stack
pointer value to be restored. Previously, if the sp restore value
points to some of the other register restore values in the
ProbeContext record, we will fail to return from the probe having
those user specified value as we're expected to do.
This is now fixed.
3. Rearranged the X86/X86_64 registers order to organize them like gdb
expects on X86_64.
4. We also now preserve the condition code registers.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARMAssembler.h:
* assembler/ARMv7Assembler.h:
(ARMRegisters):
* assembler/MacroAssemblerARM.cpp:
(JSC::isVFPPresent):
(JSC::MacroAssemblerARM::ProbeContext::dumpCPURegisters):
(JSC::MacroAssemblerARM::ProbeContext::dump):
(JSC::MacroAssemblerARM::probe):
* assembler/MacroAssemblerARM.h:
(MacroAssemblerARM):
(CPUState):
(ProbeContext):
(JSC::MacroAssemblerARM::trustedImm32FromPtr):
* assembler/MacroAssemblerARMv7.h:
(MacroAssemblerARMv7):
(CPUState):
(ProbeContext):
(JSC::MacroAssemblerARMv7::trustedImm32FromPtr):
* assembler/MacroAssemblerX86.h:
(MacroAssemblerX86):
(JSC::MacroAssemblerX86::probe):
* assembler/MacroAssemblerX86Common.cpp:
(JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::probe):
* assembler/X86Assembler.h:
* config.h:
* jit/JITStubsARM.h:
* jit/JITStubsARMv7.h:
* jit/JITStubsX86.h:
* jit/JITStubsX86Common.h:
* jit/JITStubsX86_64.h:
2013-05-28 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should call masqueradesAsUndefinedWatchpointIfIsStillValid() in all of the places where it currently calls masqueradesAsUndefinedWatchpointIsStillValid()
https://bugs.webkit.org/show_bug.cgi?id=116892
Reviewed by Oliver Hunt.
All of those places mean to plant the watchpoint if it's still valid.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
(JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
2013-05-28 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support ArithMin/ArithMax
https://bugs.webkit.org/show_bug.cgi?id=116885
Reviewed by Oliver Hunt.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
2013-05-28 Filip Pizlo <fpizlo@apple.com>
testRunner should have a way of disabling inlining of functions
https://bugs.webkit.org/show_bug.cgi?id=116875
Reviewed by Mark Hahnenberg.
* API/JSCTestRunnerUtils.cpp:
(JSC::getExecutable):
(JSC):
(JSC::numberOfDFGCompiles):
(JSC::setNeverInline):
* API/JSCTestRunnerUtils.h:
(JSC):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpAssumingJITType):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::mightInlineFunctionForCall):
(JSC::DFG::mightInlineFunctionForClosureCall):
(JSC::DFG::mightInlineFunctionForConstruct):
* runtime/Executable.h:
(JSC::ScriptExecutable::ScriptExecutable):
(ScriptExecutable):
(JSC::ScriptExecutable::setNeverInline):
(JSC::ScriptExecutable::neverInline):
(JSC::ScriptExecutable::isInliningCandidate):
2013-05-27 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support ArithMod
https://bugs.webkit.org/show_bug.cgi?id=116792
Reviewed by Oliver Hunt.
* ftl/FTLAbbreviations.h:
(JSC::FTL::buildFRem):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileArithMod):
(LowerDFGToLLVM):
* ftl/FTLOutput.h:
(JSC::FTL::Output::doubleRem):
2013-05-27 Filip Pizlo <fpizlo@apple.com>
It should be possible to record heap operations (both FastMalloc and JSC GC)
https://bugs.webkit.org/show_bug.cgi?id=116848
Reviewed by Mark Hahnenberg.
Record GC heap operations if ENABLE(ALLOCATION_LOGGING).
* API/JSManagedValue.mm:
* dfg/DFGOperations.cpp:
* heap/Heap.cpp:
(JSC::Heap::collect):
* heap/Heap.h:
(Heap):
(JSC::Heap::allocateWithNormalDestructor):
(JSC::Heap::allocateWithImmortalStructureDestructor):
(JSC::Heap::allocateWithoutDestructor):
(JSC::Heap::tryAllocateStorage):
(JSC::Heap::tryReallocateStorage):
(JSC):
(JSC::Heap::ascribeOwner):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::append):
(JSC::SlotVisitor::internalAppend):
* heap/SlotVisitor.h:
(SlotVisitor):
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::append):
(JSC::SlotVisitor::appendUnbarrieredPointer):
(JSC::SlotVisitor::appendUnbarrieredValue):
(JSC::SlotVisitor::appendUnbarrieredWeak):
(JSC::SlotVisitor::internalAppend):
(JSC):
(JSC::SlotVisitor::appendValues):
* jit/JITWriteBarrier.h:
(JSC::SlotVisitor::append):
* llint/LLIntCommon.h:
* runtime/Butterfly.h:
(Butterfly):
* runtime/ButterflyInlines.h:
(JSC::Butterfly::createUninitialized):
(JSC::Butterfly::create):
(JSC::Butterfly::growPropertyStorage):
(JSC::Butterfly::createOrGrowArrayRight):
(JSC):
(JSC::Butterfly::growArrayRight):
(JSC::Butterfly::resizeArray):
* runtime/JSArray.cpp:
(JSC::createArrayButterflyInDictionaryIndexingMode):
(JSC::JSArray::unshiftCountSlowCase):
* runtime/JSArray.h:
(JSC::createContiguousArrayButterfly):
(JSC::createArrayButterfly):
(JSC):
(JSC::JSArray::create):
(JSC::JSArray::tryCreateUninitialized):
* runtime/JSObject.cpp:
(JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
(JSC::JSObject::createInitialIndexedStorage):
(JSC::JSObject::createArrayStorage):
(JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
(JSC::JSObject::increaseVectorLength):
(JSC::JSObject::ensureLengthSlow):
(JSC::JSObject::growOutOfLineStorage):
* runtime/JSObject.h:
(JSC::JSObject::JSObject):
* runtime/Operations.h:
* runtime/RegExpMatchesArray.cpp:
(JSC::RegExpMatchesArray::create):
* runtime/StructureInlines.h:
(JSC):
* runtime/WriteBarrier.h:
(JSC):
2013-05-27 Filip Pizlo <fpizlo@apple.com>
testRunner should be able to tell you if a function is DFG compiled
https://bugs.webkit.org/show_bug.cgi?id=116847
Reviewed by Mark Hahnenberg.
* API/JSCTestRunnerUtils.cpp: Added.
(JSC):
(JSC::numberOfDFGCompiles):
* API/JSCTestRunnerUtils.h: Added.
(JSC):
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::numberOfDFGCompiles):
(JSC):
* bytecode/CodeBlock.h:
(CodeBlock):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::runThread):
* runtime/Executable.h:
(JSC):
* runtime/JSFunctionInlines.h: Added.
(JSC):
(JSC::JSFunction::JSFunction):
(JSC::JSFunction::jsExecutable):
(JSC::JSFunction::isHostFunction):
(JSC::JSFunction::nativeFunction):
(JSC::JSFunction::nativeConstructor):
* runtime/Operations.h:
2013-05-27 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG ArithMod should have the !nodeUsedAsNumber optimizations that ArithDiv has
https://bugs.webkit.org/show_bug.cgi?id=116841
Reviewed by Mark Hahnenberg.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithMod):
2013-05-26 Filip Pizlo <fpizlo@apple.com>
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2013-05-25 Filip Pizlo <fpizlo@apple.com>
fourthTier: cti_optimize shouldn't allow GCs to get in the way of it seeing the state of its CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=116748
Reviewed by Geoffrey Garen.
This fixes the following race: an optimized version of our code block could be installed
by the GC just as we return from completeAllReadyPlansForVM(), leading us to believe
that the code block isn't ready yet even though it is. Currently this triggers a
RELEASE_ASSERT. We could remove that assertion, but then this case would lead to the
code in question entering into optimizeAfterWarmUp mode. That seems pretty wasteful.
Fix the bug, and hopefully close the door on these bugs for a while, by wrapping
cti_optimize in a DeferGC. There is little downside to doing so since the only
"allocations" in cti_optimize are the ones where we inform the GC about extra memory
usage.
I had a more comprehensive solution (see the bug, "work in progress" patch) but that
one involved adding *more* raciness to cti_optimize. I decided that was a less good
approach once I came to appreciate the simplicity of just using DeferGC.
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
2013-05-25 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support ArithDiv
https://bugs.webkit.org/show_bug.cgi?id=116771
Reviewed by Oliver Hunt.
* ftl/FTLAbbreviations.h:
(JSC::FTL::buildDiv):
(JSC::FTL::buildRem):
(JSC::FTL::buildFDiv):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
* ftl/FTLCommonValues.h:
(CommonValues):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::LowerDFGToLLVM::compileArithDiv):
(LowerDFGToLLVM):
* ftl/FTLOutput.h:
(JSC::FTL::Output::div):
(JSC::FTL::Output::rem):
(JSC::FTL::Output::doubleDiv):
2013-05-25 Mark Lam <mark.lam@apple.com>
Remove Interpreter::retrieveLastCaller().
https://bugs.webkit.org/show_bug.cgi?id=116753.
Reviewed by Geoffrey Garen.
This is part of the refactoring effort to get rid of functions walking
the JS stack in their own way.
* API/JSContextRef.cpp:
(JSContextCreateBacktrace):
* interpreter/CallFrame.cpp:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::Interpreter):
(JSC::Interpreter::getStackTrace):
(JSC::Interpreter::addStackTraceIfNecessary):
* interpreter/Interpreter.h:
(StackFrame):
(JSC::StackFrame::StackFrame):
(Interpreter):
* jsc.cpp:
(functionJSCStack):
* profiler/ProfileGenerator.cpp:
(JSC::ProfileGenerator::addParentForConsoleStart):
2013-05-24 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL boolify should support ObjectOrOtherUse
https://bugs.webkit.org/show_bug.cgi?id=116741
Reviewed by Geoffrey Garen.
Just reusing what was already there in equalNullOrUndefined(). Note that we will
sometimes generate some redundant IR - like having some spurious bitNot's in
places - but it's safe to assume that LLVM will simplify those, and that it won't
be the longest pole in the tent for compile times.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
(JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
(JSC::FTL::LowerDFGToLLVM::boolify):
(JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
2013-05-24 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support LogicalNot and Branch on Int32 and Number
https://bugs.webkit.org/show_bug.cgi?id=116739
Reviewed by Gavin Barraclough.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileLogicalNot):
(JSC::FTL::LowerDFGToLLVM::compileBranch):
(JSC::FTL::LowerDFGToLLVM::boolify):
(LowerDFGToLLVM):
* ftl/FTLOutput.h:
(JSC::FTL::Output::isZero32):
(JSC::FTL::Output::notZero32):
2013-05-23 Filip Pizlo <fpizlo@apple.com>
fourthTier: add heuristics to reduce the likelihood of a trivially inlineable function being independently compiled by the concurrent JIT
https://bugs.webkit.org/show_bug.cgi?id=116557
Reviewed by Geoffrey Garen.
This introduces a fairly comprehensive mechanism for preventing trivially inlineable
functions from being compiled independently of all of the things into which they end
up being inlined.
The trick is CodeBlock::m_shouldAlwaysBeInlined, or SABI for short (that's what the
debug logging calls it). A SABI function is one that we currently believe should
never be DFG optimized because it should always be inlined into the functions that
call it. SABI follows "innocent until proven guilty": all functions start out SABI
and have SABI set to false if we see proof that that function may be called in some
possibly non-inlineable way. So long as a function is SABI, it will not tier up to
the DFG: cti_optimize will perpetually postpone its optimization. Because SABI has
such a severe effect, we make the burden of proof of guilt quite low. SABI gets
cleared if any of the following happen:
- You get called from native code (either through CallData or CachedCall).
- You get called from an eval, since eval code takes a long time to get DFG
optimized.
- You get called from global code, since often global code doesn't tier-up since
it's run-once.
- You get called recursively, where recursion is detected by a stack walk of depth
Options::maximumInliningDepth().
- You get called through an unlinked virtual call.
- You get called from DFG code, since if the caller was already DFG optimized and
didn't inline you then obviously, you might not get inlined.
- You've tiered up to the baseline JIT and you get called from the interpreter.
The idea here is that this kind of ensures that you stay SABI only if you're
called no more frequently than any of your callers.
- You get called from a code block that isn't a DFG candidate.
- You aren't an inlining candidate.
Most of the heuristics for SABI are in CodeBlock::noticeIncomingCall().
This is neutral on SunSpider and V8Spider, and appears to be a slight speed-up on
V8v7, which was previously adversely affected by concurrent compilation. I also
confirmed that for example on V8/richards, it dramatically reduces the number of
code blocks that get DFG compiled. It is a speed-up on those V8v7 benchmarks that
saw regressions from concurrent compilation.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpAssumingJITType):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::linkIncomingCall):
(JSC):
(JSC::CodeBlock::noticeIncomingCall):
* bytecode/CodeBlock.h:
(CodeBlock):
* dfg/DFGCapabilities.h:
(JSC::DFG::mightInlineFunction):
(DFG):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
* dfg/DFGRepatch.cpp:
(JSC::DFG::dfgLinkFor):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
(JSC::JIT::linkFor):
* jit/JIT.h:
(JIT):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
(JSC::lazyLinkFor):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
2013-05-23 Filip Pizlo <fpizlo@apple.com>
fourthTier: rationalize DFG::CapabilityLevel and DFGCapabilities.[h|cpp]
https://bugs.webkit.org/show_bug.cgi?id=116696
Reviewed by Sam Weinig.
Make it so that all capability calculation is funneled through one function, which tells
you everything you wanted to know: can it be inlined, and can it be compiled.
This work will help with https://bugs.webkit.org/show_bug.cgi?id=116557, since now the
JIT has a fairly authoritative answer to the "can it be inlined" question.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::ProgramCodeBlock::capabilityLevelInternal):
(JSC::EvalCodeBlock::capabilityLevelInternal):
(JSC::FunctionCodeBlock::capabilityLevelInternal):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::capabilityLevel):
(JSC::CodeBlock::capabilityLevelState):
(ProgramCodeBlock):
(EvalCodeBlock):
(FunctionCodeBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::debugFail):
(DFG):
(JSC::DFG::canInlineResolveOperations):
(JSC::DFG::capabilityLevel):
* dfg/DFGCapabilities.h:
(DFG):
(JSC::DFG::capabilityLevel):
(JSC::DFG::evalCapabilityLevel):
(JSC::DFG::programCapabilityLevel):
(JSC::DFG::functionForCallCapabilityLevel):
(JSC::DFG::functionForConstructCapabilityLevel):
(JSC::DFG::canInlineFunctionForCall):
(JSC::DFG::canInlineFunctionForClosureCall):
(JSC::DFG::canInlineFunctionForConstruct):
* dfg/DFGCommon.h:
(JSC::DFG::canCompile):
(DFG):
(JSC::DFG::canInline):
(JSC::DFG::leastUpperBound):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompilePutByIdTransition):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::privateCompilePutByIdTransition):
* tools/CodeProfile.cpp:
(JSC::CodeProfile::sample):
2013-05-22 Filip Pizlo <fpizlo@apple.com>
Rename getJITCode and getJITType to jitCode and jitType.
Rubber stampted by Mark Hahnenberg.
* assembler/RepatchBuffer.h:
(JSC::RepatchBuffer::RepatchBuffer):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dump):
(JSC::CodeBlock::visitAggregate):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::resetStubInternal):
(JSC::CodeBlock::stronglyVisitWeakReferences):
(JSC::CodeBlock::baselineVersion):
(JSC::CodeBlock::hasOptimizedReplacement):
(JSC::CodeBlock::bytecodeOffset):
(JSC::CodeBlock::codeOriginForReturn):
(JSC::ProgramCodeBlock::compileOptimized):
(JSC::EvalCodeBlock::compileOptimized):
(JSC::FunctionCodeBlock::compileOptimized):
(JSC::ProgramCodeBlock::jettison):
(JSC::EvalCodeBlock::jettison):
(JSC::FunctionCodeBlock::jettison):
(JSC::ProgramCodeBlock::jitCompileImpl):
(JSC::EvalCodeBlock::jitCompileImpl):
(JSC::FunctionCodeBlock::jitCompileImpl):
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
(JSC::CodeBlock::adjustedExitCountThreshold):
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::getCallLinkInfo):
(JSC::CodeBlock::jitCode):
(JSC::CodeBlock::jitCodeWithArityCheck):
(JSC::CodeBlock::jitType):
(JSC::CodeBlock::hasBaselineJITProfiling):
(JSC::CodeBlock::jitCompile):
(JSC::CodeBlock::addFrequentExitSite):
(JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
(JSC::ExecState::isInlineCallFrame):
* dfg/DFGAssemblyHelpers.cpp:
(JSC::DFG::AssemblyHelpers::decodedCodeMapFor):
* dfg/DFGAssemblyHelpers.h:
(JSC::DFG::AssemblyHelpers::AssemblyHelpers):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::codeLocationForRepatch):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOperations.cpp:
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExit::codeLocationForRepatch):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileFTLOSRExit):
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::~DFGCodeBlocks):
(JSC::DFGCodeBlocks::jettison):
(JSC::DFGCodeBlocks::clearMarks):
(JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
(JSC::DFGCodeBlocks::traceMarkedCodeBlocks):
* interpreter/Interpreter.cpp:
(JSC::getLineNumberForCallFrame):
(JSC::getCallerInfo):
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriateImpl):
(JSC::jitCompileFunctionIfAppropriateImpl):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::entryOSR):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Executable.cpp:
(JSC::jettisonCodeBlock):
(JSC::EvalExecutable::compileOptimized):
(JSC::EvalExecutable::jettisonOptimizedCode):
(JSC::ProgramExecutable::compileOptimized):
(JSC::ProgramExecutable::jettisonOptimizedCode):
(JSC::FunctionExecutable::baselineCodeBlockFor):
(JSC::FunctionExecutable::compileOptimizedForCall):
(JSC::FunctionExecutable::compileOptimizedForConstruct):
(JSC::FunctionExecutable::jettisonOptimizedCodeForCall):
(JSC::FunctionExecutable::jettisonOptimizedCodeForConstruct):
* tools/CodeProfile.cpp:
(JSC::CodeProfile::sample):
2013-05-22 Filip Pizlo <fpizlo@apple.com>
fourthTier: Race between LLInt->Baseline tier-up and DFG reading Baseline profiling data
https://bugs.webkit.org/show_bug.cgi?id=116633
Reviewed by Mark Hahnenberg.
Previously we would check if we had Baseline JIT profiling data by seeing if the
appropriate vector was non-empty. This is horrible if we're doing LLInt->Baseline
tier-up at the same time. This will happen for code we are inlining, if we're
deciding to inline it before the LLInt->Baseline tier-up happened for that code.
This changes things to take advantage of the fact that the very last thing that
LLInt->Baseline tier-up will do (in JITDriver.h) is setJITCode(). We now precede
the actual work in setJITCode() with a store-store fence to ensure that all
stores to modify the CodeBlock happen before setting the JITCode, and we modify
CodeBlock::getJITType() to use load-load fences to ensure that if you see
JITCode::BaselineJIT then you will also see all of those vectors. Then this
changes all of the code that scrapes Baseline JIT profiles to check if
getJITType() returns JITCode::BaselineJIT instead of checking vector sizes.
The outcome is that for the non-racy cases we behave as we did before (we fall
back on LLInt profiling if the tier-up hasn't happened) and for racy cases we
use LLInt profiling conservatively.
Note that for some (but not all!) of the cases where we scrape Baseline JIT
profiling, we would have anyway been holding the CodeBlock::m_lock so we can also
fix those cases by just having setJITCode graph that lock. This patch does that
also, mainly because although we only call setJITCode() from the main thread, in
general it's dangerous to have a pointer to a ref-counted object being modified
in a racy way. So, this patch just does the most conservative thing possible that
does we can afford to do.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::getJITType):
(JSC::CodeBlock::hasBaselineJITProfiling):
(JSC::CodeBlock::likelyToTakeSlowCase):
(JSC::CodeBlock::couldTakeSlowCase):
(JSC::CodeBlock::likelyToTakeSpecialFastCase):
(JSC::CodeBlock::couldTakeSpecialFastCase):
(JSC::CodeBlock::likelyToTakeDeepestSlowCase):
(JSC::CodeBlock::likelyToTakeAnySlowCase):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
2013-05-22 Filip Pizlo <fpizlo@apple.com>
fourthTier: It should be possible to use more than one compiler thread
https://bugs.webkit.org/show_bug.cgi?id=116630
Reviewed by Mark Hahnenberg.
This gives us the ability to use more compiler threads, but doesn't actually
enable the functionality because it isn't a speed-up on any benchmark. It can
even be a slow-down. This also adds the ability to disable concurrent
compilation if we're on a uniprocessor machine, and adds more logging to the
worklist code to allow us to investigate how many threads are active. It
appears that even on the most compiler-heavy benchmarks, we never have enough
work for more than 4 threads, and even then the 4 threads are all active for
a short time.
Something that having more threads does accomplish is that it shakes out bugs.
This patch fixes a bug with Watchpoint not being thread-safe ref-counted,
which enabling 7 compilation threads did catch.
As it stands, this patch is performance-neutral and just fixes bugs and adds
some options.
* bytecode/Watchpoint.h:
* dfg/DFGCommon.h:
(JSC::DFG::enableConcurrentJIT):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::Worklist):
(JSC::DFG::Worklist::~Worklist):
(JSC::DFG::Worklist::finishCreation):
(JSC::DFG::Worklist::create):
(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
(JSC::DFG::Worklist::dump):
(JSC::DFG::Worklist::runThread):
(JSC::DFG::initializeGlobalWorklistOnce):
* dfg/DFGWorklist.h:
* runtime/Options.cpp:
(JSC::computeNumberOfWorkerThreads):
(JSC):
(JSC::computeNumberOfGCMarkers):
* runtime/Options.h:
(JSC):
2013-05-22 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL shouldn't use the LLVM global context, and should instead create its own context for each compilation
https://bugs.webkit.org/show_bug.cgi?id=116631
Reviewed by Mark Hahnenberg.
In the future we might want to share contexts for multiple compilations, but for
now using one context per compilation is a progression over just constantly using
the global context.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
(DFG):
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPlan.h:
* ftl/FTLAbbreviatedTypes.h:
(FTL):
* ftl/FTLAbbreviations.h:
(JSC::FTL::voidType):
(JSC::FTL::int1Type):
(JSC::FTL::int8Type):
(JSC::FTL::int32Type):
(JSC::FTL::int64Type):
(JSC::FTL::intPtrType):
(JSC::FTL::doubleType):
(JSC::FTL::structType):
(JSC::FTL::mdKindID):
(JSC::FTL::mdString):
(JSC::FTL::mdNode):
(JSC::FTL::appendBasicBlock):
(JSC::FTL::insertBasicBlock):
* ftl/FTLAbstractHeap.cpp:
(JSC::FTL::AbstractHeap::tbaaMetadataSlow):
(JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
(JSC::FTL::NumberedAbstractHeap::NumberedAbstractHeap):
(JSC::FTL::AbsoluteAbstractHeap::AbsoluteAbstractHeap):
* ftl/FTLAbstractHeap.h:
(IndexedAbstractHeap):
(NumberedAbstractHeap):
(AbsoluteAbstractHeap):
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
(AbstractHeapRepository):
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
* ftl/FTLCommonValues.h:
(CommonValues):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateCodeSection):
* ftl/FTLIntrinsicRepository.cpp:
(JSC::FTL::IntrinsicRepository::IntrinsicRepository):
* ftl/FTLIntrinsicRepository.h:
(FTL):
(IntrinsicRepository):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lower):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::Output):
* ftl/FTLOutput.h:
(Output):
(JSC::FTL::Output::newBlock):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
(JSC::FTL::State::~State):
(FTL):
* ftl/FTLState.h:
(State):
* runtime/Options.h:
(JSC):
2013-05-18 Filip Pizlo <fpizlo@apple.com>
FTL should force LLVM to use our own JIT memory allocator, and we shouldn't have to keep around an LLVMExecutionEngineRef to keep code alive
https://bugs.webkit.org/show_bug.cgi?id=113619
Reviewed by Geoffrey Garen.
This uses new API that I've exposed, which allows for memory manager callbacks
from within LLVM. LLVM may allocate multiple independent chunks of memory for
a module, and we track all of those in a Vector in FTL::JITCode.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateCodeSection):
(FTL):
(JSC::FTL::mmAllocateDataSection):
(JSC::FTL::mmApplyPermissions):
(JSC::FTL::mmDestroy):
(JSC::FTL::compile):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::JITCode):
(JSC::FTL::JITCode::~JITCode):
(JSC::FTL::JITCode::addHandle):
(FTL):
(JSC::FTL::JITCode::initializeCode):
* ftl/FTLJITCode.h:
(JITCode):
(JSC::FTL::JITCode::handles):
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::~JITFinalizer):
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLJITFinalizer.h:
(JSC::FTL::JITFinalizer::initializeEntrypointLinkBuffer):
(JITFinalizer):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* ftl/FTLState.h:
(State):
2013-05-12 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL shouldn't use FastISel and Small code model should be turned off for now
https://bugs.webkit.org/show_bug.cgi?id=115998
Reviewed by Oliver Hunt.
This switches off FastISel and makes it possible to turn off Small code model.
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* runtime/Options.h:
(JSC):
2013-05-21 Filip Pizlo <fpizlo@apple.com>
fourthTier: should use ConcurrentJITLock[er] directly and not through typedef
https://bugs.webkit.org/show_bug.cgi?id=116561
Rubber stamped by Geoffrey Garen.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ArrayProfile.cpp:
(JSC::ArrayProfile::computeUpdatedPrediction):
(JSC::ArrayProfile::briefDescription):
* bytecode/ArrayProfile.h:
(ArrayProfile):
(JSC::ArrayProfile::expectedStructure):
(JSC::ArrayProfile::structureIsPolymorphic):
(JSC::ArrayProfile::hasDefiniteStructure):
(JSC::ArrayProfile::observedArrayModes):
(JSC::ArrayProfile::mayInterceptIndexedAccesses):
(JSC::ArrayProfile::mayStoreToHole):
(JSC::ArrayProfile::outOfBounds):
(JSC::ArrayProfile::usesOriginalArrayStructures):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpValueProfiling):
(JSC::CodeBlock::dumpArrayProfiling):
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::updateAllArrayPredictions):
(JSC::CodeBlock::nameForRegister):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
(CodeBlock):
* bytecode/CodeBlockLock.h: Removed.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/LazyOperandValueProfile.cpp:
(JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
(JSC::CompressedLazyOperandValueProfileHolder::add):
(JSC::LazyOperandValueProfileParser::initialize):
(JSC::LazyOperandValueProfileParser::prediction):
* bytecode/LazyOperandValueProfile.h:
(CompressedLazyOperandValueProfileHolder):
(LazyOperandValueProfileParser):
* bytecode/MethodOfGettingAValueProfile.cpp:
(JSC::MethodOfGettingAValueProfile::getSpecFailBucket):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecode/ResolveGlobalStatus.cpp:
(JSC::ResolveGlobalStatus::computeFor):
* bytecode/ValueProfile.h:
(JSC::ValueProfileBase::briefDescription):
(JSC::ValueProfileBase::computeUpdatedPrediction):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addVar):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::fromObserved):
* dfg/DFGArrayMode.h:
(ArrayMode):
(JSC::DFG::ArrayMode::withProfile):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::getArrayMode):
(JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* jit/JITInlines.h:
(JSC::JIT::chooseArrayMode):
* jit/JITStubs.cpp:
(JSC::tryCachePutByID):
(JSC::tryCacheGetByID):
(JSC::DEFINE_STUB_FUNCTION):
(JSC::lazyLinkFor):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setUpCall):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::BytecodeSequence):
* runtime/Executable.cpp:
(JSC::ProgramExecutable::addGlobalVar):
* runtime/JSActivation.cpp:
(JSC::JSActivation::getOwnNonIndexPropertyNames):
(JSC::JSActivation::symbolTablePutWithAttributes):
* runtime/JSScope.cpp:
(JSC::JSScope::resolveContainingScopeInternal):
(JSC::JSScope::resolvePut):
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::findRegisterIndex):
(JSC::JSSegmentedVariableObject::addRegisters):
* runtime/JSSegmentedVariableObject.h:
(JSSegmentedVariableObject):
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
(JSC::symbolTablePut):
(JSC::symbolTablePutWithAttributes):
* runtime/Structure.cpp:
(JSC::Structure::materializePropertyMap):
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
(JSC::Structure::addPropertyTransition):
(JSC::Structure::takePropertyTableOrCloneIfPinned):
(JSC::Structure::nonPropertyTransition):
(JSC::Structure::putSpecificValue):
(JSC::Structure::remove):
(JSC::Structure::createPropertyMap):
* runtime/Structure.h:
(Structure):
* runtime/SymbolTable.h:
(SymbolTable):
(JSC::SymbolTable::find):
(JSC::SymbolTable::get):
(JSC::SymbolTable::inlineGet):
(JSC::SymbolTable::begin):
(JSC::SymbolTable::end):
(JSC::SymbolTable::size):
(JSC::SymbolTable::add):
(JSC::SymbolTable::set):
(JSC::SymbolTable::contains):
2013-05-20 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should be able to run on a separate thread
https://bugs.webkit.org/show_bug.cgi?id=112839
Reviewed by Geoffrey Garen.
This is the final bit of concurrent JITing. The idea is that there is a
single global worklist, and a single global thread, that does all
optimizing compilation. This is the DFG::Worklist. It contains a queue of
DFG::Plans, and a map from CodeBlock* (the baseline code block we're
trying to optimize) to DFG::Plan. If the DFGDriver tries to concurrently
compile something, it puts the Plan on the Worklist. The Worklist's
thread will compile that Plan eventually, and when it's done, it will
signal its completion by (1) notifying anyone waiting for the Worklist to
be done, and (2) forcing the CodeBlock::m_jitExecuteCounter to take slow
path. The next Baseline JIT cti_optimize call will then install all ready
(i.e. compiled) Plans for that VM. Note that (1) is only for the GC and
VM shutdown, which will want to ensure that there aren't any outstanding
async compilations before proceeding. They do so by simply waiting for
all of the plans for the current VM to complete. (2) is the actual way
that code typically gets installed.
This is all very racy by design. For example, just as we try to force the
execute counter to take slow path, the main thread may be setting the
execute counter to some other value. The main thread must set it to
another value because (a) JIT code is constantly incrementing the counter
in a racy way, (b) the cti_optimize slow path will set it to some
large-ish negative value to ensure that cti_optimize isn't called
repeatedly, and (c) OSR exits from previously jettisoned code blocks may
still want to reset the counter values. This "race" is made benign, by
ensuring that while there is an asynchronous compilation, we at worse set
the counter to optimizeAfterWarmUp and never to deferIndefinitely. Hence
if the race happens then the worst case is that we wait another ~1000
counts before installing the optimized code. Another defense is that if
any CodeBlock calls into cti_optimize, then it will check for all ready
plans for the VM - so even if a code block has to wait another ~1000
executions before it calls cti_optimize to do the installation, it may
actually end up being installed sooner because a different code block had
called cti_optimize, potentially for an unrelated reason.
Special care is taken to ensure that installing plans informs the GC
about the increased memory usage, but also ensures that we don't recurse
infinitely - since at start of GC we try to install outstanding plans.
This is done by introducing a new GC deferral mechanism (the DeferGC
block-scoped thingy), which will ensure that GCs don't happen in the
scope but are allowed to happen after. This still leaves the strange
corner case that cti_optimize may install outstanding plans, then GC, and
that GC may jettison the code block that was installed. This, and the
fact that the plan that we took slow path to install could have been a
failed or invalid compile, mean that we have to take special precautions
in cti_optimize.
This patch also fixes a number of small concurrency bugs that I found
when things started running. There are probably more of those bugs still
left to fix. This patch just fixes the ones I know about.
Concurrent compilation is right now only enabled on X86_64 Mac. We need
platforms that are sufficiently CAStastic so that we can do the various
memory fence and CAS tricks that make this safe. We also need a platform
that uses JSVALUE64. And we need pthread_once. So, that pretty much means
just X64_64 for now. Enabling Linux-64_64 should be a breeze, but I'll
leave that up to the Qt and GTK+ ports to do at their discretion.
This is a solid speed-up on SunSpider (8-9%) and V8Spider (16%), our two
main compile-time benchmarks. Most peculiarly, this also appears to
reduce measurement noise, rather than increasing it as you would have
expected. I don't understand that result but I like it anyway. On the
other hand, this is a slight (1%) slow-down on V8v7. I will continue to
investigate this but I think that the results are already good enough
that we should land this as-is. So far, it appears that the slow-down is
due to this breaking the don't-compile-inlineables heuristics. See
investigation in https://bugs.webkit.org/show_bug.cgi?id=116556 and the
bug https://bugs.webkit.org/show_bug.cgi?id=116557.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::resetStubInternal):
(JSC::CodeBlock::baselineVersion):
(JSC::CodeBlock::hasOptimizedReplacement):
(JSC::CodeBlock::optimizationThresholdScalingFactor):
(JSC::CodeBlock::checkIfOptimizationThresholdReached):
(JSC::CodeBlock::optimizeNextInvocation):
(JSC::CodeBlock::dontOptimizeAnytimeSoon):
(JSC::CodeBlock::optimizeAfterWarmUp):
(JSC::CodeBlock::optimizeAfterLongWarmUp):
(JSC::CodeBlock::optimizeSoon):
(JSC::CodeBlock::forceOptimizationSlowPathConcurrently):
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::updateAllArrayPredictions):
(JSC::CodeBlock::shouldOptimizeNow):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::jitCompile):
* bytecode/CodeBlockLock.h:
(JSC):
* bytecode/ExecutionCounter.cpp:
(JSC::ExecutionCounter::forceSlowPathConcurrently):
(JSC):
(JSC::ExecutionCounter::setThreshold):
* bytecode/ExecutionCounter.h:
(ExecutionCounter):
* debugger/Debugger.cpp:
(JSC::Debugger::recompileAllJSFunctions):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
(JSC::DFG::ByteCodeParser::getArrayMode):
(JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
* dfg/DFGCommon.h:
(JSC::DFG::enableConcurrentJIT):
(DFG):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOperations.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::key):
(DFG):
* dfg/DFGPlan.h:
(DFG):
(Plan):
* dfg/DFGWorklist.cpp: Added.
(DFG):
(JSC::DFG::Worklist::Worklist):
(JSC::DFG::Worklist::~Worklist):
(JSC::DFG::Worklist::finishCreation):
(JSC::DFG::Worklist::create):
(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::compilationState):
(JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
(JSC::DFG::Worklist::removeAllReadyPlansForVM):
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
(JSC::DFG::Worklist::completeAllPlansForVM):
(JSC::DFG::Worklist::queueLength):
(JSC::DFG::Worklist::dump):
(JSC::DFG::Worklist::runThread):
(JSC::DFG::Worklist::threadFunction):
(JSC::DFG::initializeGlobalWorklistOnce):
(JSC::DFG::globalWorklist):
* dfg/DFGWorklist.h: Added.
(DFG):
(Worklist):
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::allocateBlock):
* heap/DeferGC.h: Added.
(JSC):
(DeferGC):
(JSC::DeferGC::DeferGC):
(JSC::DeferGC::~DeferGC):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::reportExtraMemoryCostSlowCase):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collect):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC):
(JSC::Heap::incrementDeferralDepth):
(JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
* heap/Heap.h:
(Heap):
(JSC::Heap::isCollecting):
(JSC):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCase):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
(JSC::LLInt::entryOSR):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* profiler/ProfilerBytecodes.h:
* runtime/ConcurrentJITLock.h: Added.
(JSC):
* runtime/ExecutionHarness.h:
(JSC::replaceWithDeferredOptimizedCode):
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::findRegisterIndex):
(JSC::JSSegmentedVariableObject::addRegisters):
* runtime/JSSegmentedVariableObject.h:
(JSSegmentedVariableObject):
* runtime/Options.h:
(JSC):
* runtime/Structure.h:
(Structure):
* runtime/StructureInlines.h:
(JSC::Structure::propertyTable):
* runtime/SymbolTable.h:
(SymbolTable):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
(JSC::VM::prepareToDiscardCode):
(JSC):
(JSC::VM::discardAllCode):
(JSC::VM::releaseExecutableMemory):
* runtime/VM.h:
(DFG):
(VM):
2013-05-17 Mark Hahnenberg <mhahnenberg@apple.com>
CheckArrays should be hoisted
https://bugs.webkit.org/show_bug.cgi?id=116353
Performance neutral. This will be more important when we start depending on CheckArray for flat arrays.
Reviewed by Filip Pizlo.
* dfg/DFGAbstractState.cpp: Add ForwardCheckArray to wherever we had a CheckArray before.
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::isContravenedByStructure): Checks if the ArrayMode derived from a specific Structure
would contradict the ArrayModes that would be filtered by the current ArrayMode. This is used to detect
if any specific CheckStructures would contradict our CheckArray so that we can defer to the CheckStructure's
judgment.
* dfg/DFGByteCodeParser.cpp: Fill in checkArrayHoistingFailed where we previously exited due to a BadIndexingType.
(JSC::DFG::ByteCodeParser::setLocal):
(JSC::DFG::ByteCodeParser::setArgument):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::checkArrayElimination):
(JSC::DFG::CSEPhase::performNodeCSE):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasArrayMode):
* dfg/DFGNodeType.h: New ForwardCheckArray node type.
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp: Refactored most of TypeCheckHoistingPhase into separate functions, some
of which are now generic to both CheckStructure and CheckArray hoisting while others are specific to one or the
other. Both of the non-zero CheckBallot values must be 1 because we use them as an index into an array of
length 2 inside the VariableAccessData.
(CheckData): Moved structure outside of TypeCheckHoistingPhase so that ArrayTypeCheck and StructureTypeCheck
can access it. Also added new fields for tracking ArrayModes. We need the m_arrayModeIsValid because there
isn't a good sentinel value for "this ArrayMode is invalid and meaningless" like there is for m_structure.
We need m_arrayModeHoistingOkay for when we want to permanently disable hoisting for that particular variable.
(JSC::DFG::CheckData::CheckData):
(JSC::DFG::CheckData::disableCheckArrayHoisting): Helper function for disabling CheckArray hoisting for a
specific CheckData.
(JSC::DFG::TypeCheckHoistingPhase::run): We now do both CheckStructure and CheckArray hoisting, although we prefer
CheckStructure hoisting when given the possibility to do both.
(TypeCheckHoistingPhase):
(JSC::DFG::TypeCheckHoistingPhase::clearVariableVotes): Clears all of the VariableAccessData votes since they
can only have two types of votes at any particular time.
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): Very similar to identifyRedundantStructureChecks,
but with a few different nodes that are important, namely CheckArray (instead of CheckStructure) and the Arrayify-like
nodes always disable hoisting since they always change the IndexingType.
(JSC::DFG::TypeCheckHoistingPhase::disableHoistingForVariablesWithInsufficientVotes):
(JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
(JSC::DFG::TypeCheckHoistingPhase::disableCheckArrayHoisting): Helper that looks up the CheckData for the
specified variable and disables CheckArray hoisting on it.
(JSC::DFG::TypeCheckHoistingPhase::shouldConsiderForHoisting):
(JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheck):
(JSC::DFG::TypeCheckHoistingPhase::noticeCheckArray):
(JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheckAccountingForArrayMode): We want to take CheckStructure nodes
into account when hoisting CheckArrays, so we make sure that if we contradict what a CheckStructure says then we
give up on hoisting the CheckArray.
(JSC::DFG::ArrayTypeCheck::isValidToHoist):
(ArrayTypeCheck): Structure that houses some of the specifics on how to hoist CheckArrays. This structure
is used a template argument to allow some of the very similar code to statically parameterized and reused
for both CheckStructure and CheckArray hoisting.
(JSC::DFG::ArrayTypeCheck::disableHoisting):
(JSC::DFG::ArrayTypeCheck::isContravenedByValue):
(JSC::DFG::ArrayTypeCheck::hasEnoughVotesToHoist):
(JSC::DFG::ArrayTypeCheck::hoistingPreviouslyFailed):
(JSC::DFG::StructureTypeCheck::isValidToHoist):
(StructureTypeCheck): Same as ArrayTypeCheck, but specific to CheckStructure hoisting.
(JSC::DFG::StructureTypeCheck::disableHoisting):
(JSC::DFG::StructureTypeCheck::isContravenedByValue):
(JSC::DFG::StructureTypeCheck::hasEnoughVotesToHoist):
(JSC::DFG::StructureTypeCheck::hoistingPreviouslyFailed):
* dfg/DFGUnificationPhase.cpp: Added merging of whether or not CheckArray hoisting failed.
(JSC::DFG::UnificationPhase::run):
* dfg/DFGVariableAccessData.h:
(JSC::DFG::VariableAccessData::VariableAccessData):
(JSC::DFG::VariableAccessData::mergeCheckArrayHoistingFailed):
(VariableAccessData):
(JSC::DFG::VariableAccessData::checkArrayHoistingFailed):
* runtime/Options.h:
2013-05-17 Filip Pizlo <fpizlo@apple.com>
fourthTier: getCTIStub should be thread-safe
https://bugs.webkit.org/show_bug.cgi?id=116126
Reviewed by Dan Bernstein.
It's called from the compilation thread. Give it locks.
* jit/JITThunks.cpp:
(JSC::JITThunks::ctiStub):
(JSC::JITThunks::hostFunctionStub):
* jit/JITThunks.h:
(JITThunks):
2013-05-17 Filip Pizlo <fpizlo@apple.com>
fourthTier: Executable and CodeBlock should be aware of DFG::Plans that complete asynchronously
https://bugs.webkit.org/show_bug.cgi?id=116350
Reviewed by Oliver Hunt.
This refactors compilation so that:
- JITStubs knows exactly what the result of compilation was. For example, if
compilation was deferred, it will now know this.
- The set of things that has to happen to install compiled code is now factored
out into JSC::installOptimizedCode().
- A bunch of the code in Executable.cpp is now made more common to reduce code
duplication. For example, the heap heuristics stuff is now in one place.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::ProgramCodeBlock::compileOptimized):
(JSC::ProgramCodeBlock::replaceWithDeferredOptimizedCode):
(JSC):
(JSC::EvalCodeBlock::compileOptimized):
(JSC::EvalCodeBlock::replaceWithDeferredOptimizedCode):
(JSC::FunctionCodeBlock::compileOptimized):
(JSC::FunctionCodeBlock::replaceWithDeferredOptimizedCode):
(JSC::ProgramCodeBlock::jitCompileImpl):
(JSC::EvalCodeBlock::jitCompileImpl):
(JSC::FunctionCodeBlock::jitCompileImpl):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::jitCompile):
(ProgramCodeBlock):
(EvalCodeBlock):
(FunctionCodeBlock):
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::numberOfIdentifiers):
(DFG):
(JSC::DFG::DesiredIdentifiers::at):
* dfg/DFGDesiredIdentifiers.h:
(JSC):
(DesiredIdentifiers):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
(JSC::DFG::tryFinalizePlan):
(DFG):
* dfg/DFGDriver.h:
(DFG):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
(JSC::DFG::tryFinalizePlan):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::finalizeCommon):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::reallyAdd):
* dfg/DFGPlan.h:
(JSC):
(Plan):
(DFG):
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriateImpl):
(JSC::jitCompileFunctionIfAppropriateImpl):
(JSC):
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
* runtime/CompilationResult.cpp: Added.
(WTF):
(WTF::printInternal):
* runtime/CompilationResult.h: Added.
(JSC):
(WTF):
* runtime/Executable.cpp:
(JSC::EvalExecutable::compileOptimized):
(JSC::EvalExecutable::jitCompile):
(JSC::EvalExecutable::compileInternal):
(JSC::EvalExecutable::replaceWithDeferredOptimizedCode):
(JSC):
(JSC::ProgramExecutable::compileOptimized):
(JSC::ProgramExecutable::jitCompile):
(JSC::ProgramExecutable::compileInternal):
(JSC::ProgramExecutable::replaceWithDeferredOptimizedCode):
(JSC::FunctionExecutable::compileOptimizedForCall):
(JSC::FunctionExecutable::compileOptimizedForConstruct):
(JSC::FunctionExecutable::jitCompileForCall):
(JSC::FunctionExecutable::jitCompileForConstruct):
(JSC::FunctionExecutable::compileForCallInternal):
(JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeForCall):
(JSC::FunctionExecutable::compileForConstructInternal):
(JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeForConstruct):
* runtime/Executable.h:
(ScriptExecutable):
(EvalExecutable):
(ProgramExecutable):
(FunctionExecutable):
(JSC::FunctionExecutable::compileOptimizedFor):
(JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeFor):
(JSC::FunctionExecutable::jitCompileFor):
* runtime/ExecutionHarness.h:
(JSC::prepareForExecutionImpl):
(JSC::prepareFunctionForExecutionImpl):
(JSC):
(JSC::installOptimizedCode):
(JSC::prepareForExecution):
(JSC::prepareFunctionForExecution):
(JSC::replaceWithDeferredOptimizedCode):
2013-05-16 Mark Hahnenberg <mhahnenberg@apple.com>
observeUseKindOnNode doesn't contain a case for KnownCellUse
https://bugs.webkit.org/show_bug.cgi?id=116130
This would just lead to us being overly conservative when deciding
whether we should unbox GetLocals with KnownCellUse UseKinds.
Reviewed by Filip Pizlo.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::observeUseKindOnNode):
2013-05-16 Mark Hahnenberg <mhahnenberg@apple.com>
fourthTier: infrequent segfault in DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks()
https://bugs.webkit.org/show_bug.cgi?id=116134
CodeBlock and JITCode should be ThreadSafeRefCounted. We're going to
start using them on more threads very soon (with concurrent
compilation). This patch also fixes the specific place where we were
superfluously creating a RefPtr.
Reviewed by Oliver Hunt.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::getJITType):
* jit/JITCode.h:
2013-05-16 Mark Lam <mark.lam@apple.com>
Implement a probe mechanism for JIT generated code.
https://bugs.webkit.org/show_bug.cgi?id=115705.
Reviewed by Geoffrey Garen.
Edit: For C++ code, you can do debugging by adding printfs to your
code. For JIT generated code, you can now do the equivalent by
inserting a probe and have it emit a call to your probe function.
The probe is in the form of a MacroAssembler pseudo instruction.
It takes 3 arguments: a ProbeFunction, and 2 void* args.
When inserted into the JIT at some code generation site, the probe
pseudo "instruction" will emit a minimal amount of code to save the
stack pointer, 1 (or more) scratch register(s), and the probe
arguments into a ProbeContext record on the stack. The emitted code
will then call a probe trampoline to do the rest of the work, which
consists of:
1. saving the remaining registers into the ProbeContext.
2. calling the ProbeFunction, and passing it the ProbeContext pointer.
3. restoring the registers from the ProbeContext after the ProbeFunction
returns, and then returning to the JIT generated code.
The ProbeContext is stack allocated and is only valid for the duration
that the ProbeFunction is executing.
If the user supplied ProbeFunction alters the register values in the
ProbeContext, the new values will be installed into the registers upon
returning from the probe. This can be useful for some debugging or
testing purposes.
The probe mechanism is built conditional on USE(MASM_PROBE) which is
defined in config.h. USE(MASM_PROBE) will off by default.
This changeset only implements the probe mechanism for X86 and X86_64.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* assembler/MacroAssembler.h:
(MacroAssembler):
(JSC::MacroAssembler::shouldBlind):
(JSC::MacroAssembler::store32):
* assembler/MacroAssemblerX86.h:
(MacroAssemblerX86):
(JSC::MacroAssemblerX86::trustedImm32FromPtr):
(JSC::MacroAssemblerX86::probe):
* assembler/MacroAssemblerX86Common.cpp: Added.
(JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters):
- CPU specific register dumper called by ProbeContext::dump().
(JSC::MacroAssemblerX86Common::ProbeContext::dump):
- Prints the ProbeContext to the DataLog.
* assembler/MacroAssemblerX86Common.h:
(MacroAssemblerX86Common):
(CPUState): Added.
(ProbeContext): Added.
* assembler/MacroAssemblerX86_64.h:
(MacroAssemblerX86_64):
(JSC::MacroAssemblerX86_64::trustedImm64FromPtr):
(JSC::MacroAssemblerX86_64::probe):
* assembler/X86Assembler.h:
* config.h: Added WTF_USE_MASM_PROBE flag.
* jit/JITStubs.cpp:
* jit/JITStubs.h:
* jit/JITStubsX86.h:
* jit/JITStubsX86Common.h: Added.
* jit/JITStubsX86_64.h:
2013-05-15 Mark Lam <mark.lam@apple.com>
Fix for broken 32-bit build in SpeculativeJIT::checkArray().
https://bugs.webkit.org/show_bug.cgi?id=116184.
Rubber stamped by Mark Hahnenberg.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArray):
2013-05-15 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should separate link phase into things that must be done concurrently and things that must be done synchronously, and have a way of passing data from one to the other
https://bugs.webkit.org/show_bug.cgi?id=116060
Reviewed by Gavin Barraclough.
This introduces the concept of a DFG::Plan, which corresponds to:
- The data that the concurrent DFG or FTL need to start compiling a CodeBlock.
This mostly includes basic things like CodeBlock*, but also a list of
must-handle values for OSR entry.
- The data that the synchronous linker need to link in code compiled by a
concurrent compilation thread. This is further encapsulated by DFG::Finalizer,
since the data, and the actions that need to be taken, are different in DFG
versus FTL. This patch also institutes the policy that the concurrent
compilation thread shall not use LinkBuffer::performFinalization(), since that
code assumes that it's running on the same thread that will actually run the
code.
- The actions that need to be taken to compile code. In other words, most of the
code that previously lived in DFGDriver.cpp now lives in
DFG::Plan::compileInThread().
- The actions that need to be taken when synchronously linking the code. This
includes "really" adding watchpoints and identifiers, checking watchpoint and
chain validity, and running the DFG::Finalizer.
Currently, DFGDriver just creates a Plan and runs it synchronously. But in the
future, we will be able to malloc some Plans and enqueue them, and have the
concurrent thread dequeue them and call Plan::compileInThread().
For now, this has no behavior or performance change.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::performFinalization):
* assembler/LinkBuffer.h:
(LinkBuffer):
(JSC::LinkBuffer::LinkBuffer):
(JSC::LinkBuffer::~LinkBuffer):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::initialize):
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::setFuturePossibleStructure):
(JSC::DFG::AbstractValue::filterFuturePossibleStructure):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addStructureTransitionCheck):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
* dfg/DFGDriver.cpp:
(DFG):
(JSC::DFG::compile):
* dfg/DFGFailedFinalizer.cpp: Added.
(DFG):
(JSC::DFG::FailedFinalizer::FailedFinalizer):
(JSC::DFG::FailedFinalizer::~FailedFinalizer):
(JSC::DFG::FailedFinalizer::finalize):
(JSC::DFG::FailedFinalizer::finalizeFunction):
* dfg/DFGFailedFinalizer.h: Added.
(DFG):
(FailedFinalizer):
* dfg/DFGFinalizer.cpp: Added.
(DFG):
(JSC::DFG::Finalizer::Finalizer):
(JSC::DFG::Finalizer::~Finalizer):
* dfg/DFGFinalizer.h: Added.
(DFG):
(Finalizer):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::dump):
(DFG):
* dfg/DFGGraph.h:
(Graph):
(JSC::DFG::Graph::masqueradesAsUndefinedWatchpointIsStillValid):
(JSC::DFG::Graph::compilation):
(JSC::DFG::Graph::identifiers):
(JSC::DFG::Graph::watchpoints):
(JSC::DFG::Graph::chains):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::linkFunction):
(DFG):
(JSC::DFG::JITCompiler::disassemble):
* dfg/DFGJITCompiler.h:
(JITCompiler):
(JSC::DFG::JITCompiler::addLazily):
* dfg/DFGJITFinalizer.cpp: Added.
(DFG):
(JSC::DFG::JITFinalizer::JITFinalizer):
(JSC::DFG::JITFinalizer::~JITFinalizer):
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
(JSC::DFG::JITFinalizer::finalizeCommon):
* dfg/DFGJITFinalizer.h: Added.
(DFG):
(JITFinalizer):
* dfg/DFGPlan.cpp: Added.
(DFG):
(JSC::DFG::dumpAndVerifyGraph):
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::~Plan):
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::isStillValid):
(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::finalize):
* dfg/DFGPlan.h: Added.
(DFG):
(Plan):
(JSC::DFG::Plan::vm):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::identifierUID):
(JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):
* ftl/FTLGeneratedFunction.h: Added.
(FTL):
* ftl/FTLJITFinalizer.cpp: Added.
(FTL):
(JSC::FTL::JITFinalizer::JITFinalizer):
(JSC::FTL::JITFinalizer::~JITFinalizer):
(JSC::FTL::JITFinalizer::finalize):
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLJITFinalizer.h: Added.
(FTL):
(JITFinalizer):
(JSC::FTL::JITFinalizer::initializeExitThunksLinkBuffer):
(JSC::FTL::JITFinalizer::initializeEntrypointLinkBuffer):
(JSC::FTL::JITFinalizer::initializeCode):
(JSC::FTL::JITFinalizer::initializeFunction):
(JSC::FTL::JITFinalizer::initializeArityCheck):
(JSC::FTL::JITFinalizer::initializeJITCode):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLink.h:
(FTL):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* ftl/FTLState.h:
(FTL):
(State):
2013-05-14 Mark Lam <mark.lam@apple.com>
Refactor JITStubs.cpp to move CPU specific parts out into their own files.
https://bugs.webkit.org/show_bug.cgi?id=116135.
Reviewed by Michael Saboff.
This mod only moves the CPU specific parts out. There is no code change.
Tested on debug builds of X86, X86_64, ARM and ARMv7. The SH4 and MIPS
ports are untested. Windows port also not tested.
* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JITStubs.cpp:
(JSC::performPlatformSpecificJITAssertions):
* jit/JITStubsARM.h: Added.
(JSC::ctiTrampoline):
(JSC::ctiTrampolineEnd):
(JSC::ctiVMThrowTrampoline):
(JSC::ctiOpThrowNotCaught):
(JSC::performARMJITAssertions):
* jit/JITStubsARMv7.h: Added.
(JSC::ctiTrampoline):
(JSC::ctiVMThrowTrampoline):
(JSC::ctiOpThrowNotCaught):
(JSC::performARMv7JITAssertions):
* jit/JITStubsMIPS.h: Added.
(JSC::performMIPSJITAssertions):
* jit/JITStubsSH4.h: Added.
* jit/JITStubsX86.h: Added.
* jit/JITStubsX86_64.h: Added.
2013-05-14 Mark Hahnenberg <mhahnenberg@apple.com>
fourthTier: Segfault in jsc with simple test program when running with profile dumping enabled
https://bugs.webkit.org/show_bug.cgi?id=116082
It's crashing because CodeBlock::baselineVersion() doesn't know how to handle the case where 'this' is the
baseline version but it hasn't been assigned to the m_blahCodeBlock field in BlahExecutable. The fix is to
check if we're the baseline version in baselineVersion() and return this if so.
Reviewed by Filip Pizlo.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::baselineVersion):
2013-05-11 Mark Hahnenberg <mhahnenberg@apple.com>
Rename StructureCheckHoistingPhase to TypeCheckHoistingPhase
https://bugs.webkit.org/show_bug.cgi?id=115938
We're going to add some more types of check hoisting soon, so let's have
the right name here.
Rubber stamped by Filip Pizlo.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGStructureCheckHoistingPhase.cpp: Removed.
* dfg/DFGStructureCheckHoistingPhase.h: Removed.
* dfg/DFGTypeCheckHoistingPhase.cpp: Added.
(DFG):
(TypeCheckHoistingPhase):
(JSC::DFG::TypeCheckHoistingPhase::TypeCheckHoistingPhase):
(JSC::DFG::TypeCheckHoistingPhase::run):
(JSC::DFG::TypeCheckHoistingPhase::shouldConsiderForHoisting):
(JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheck):
(CheckData):
(JSC::DFG::TypeCheckHoistingPhase::CheckData::CheckData):
(JSC::DFG::performTypeCheckHoisting):
* dfg/DFGTypeCheckHoistingPhase.h: Added.
2013-05-10 Mark Hahnenberg <mhahnenberg@apple.com>
SpeculativeJIT::checkArray should use the correct ExitKind
https://bugs.webkit.org/show_bug.cgi?id=115943
Currently it uses Uncountable, which gives us no information if we end up exiting due to a
mismatched ClassInfo pointer. It should instead use BadType and should pass the correct
JSValueSource and Node instead of passing empty values.
Reviewed by Filip Pizlo.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArray):
2013-05-11 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support Jump and ForceOSRExit
https://bugs.webkit.org/show_bug.cgi?id=115942
Reviewed by Oliver Hunt.
Added two obvious nodes: Jump and ForceOSRExit. We already had everything we needed
to support them.
Adding these increases our coverage a fair bit, and revealed a bug: LLVM's full
instruction selector currently appears to mishandle doubles in constant pools (or
just constant pools in general) with the small code model in the MCJIT. But switching
to FastISel "fixes" it. That's what this patch does, for now. This will probably
actually be permanent; the FastISel does pretty much everything we would ever want,
at least in the foreseeable future.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
(FTL):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileBlock):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileJSConstant):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileJump):
(JSC::FTL::LowerDFGToLLVM::compileReturn):
(JSC::FTL::LowerDFGToLLVM::compileForceOSRExit):
* runtime/Options.h:
(JSC):
2013-05-10 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support CompareStrictEqConstant
https://bugs.webkit.org/show_bug.cgi?id=115941
Reviewed by Mark Hahnenberg.
Pretty simple, but factors out the craziness of comparing against null or undefined
in a way that is reusable for both == and ===.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
(JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
2013-05-10 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support CompareEqConstant
https://bugs.webkit.org/show_bug.cgi?id=115939
Reviewed by Oliver Hunt and Mark Hahnenberg.
The most interesting part of this patch is the way I make it easier to deal with
the inputs to Phi functions. This adds the notion of ValueFromBlock, which you
can get by doing m_out.anchor(value). You can build up a vector of these, and then
pass them to m_out.phi(type, vector) in one go.
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLAbbreviatedTypes.h: Added.
(FTL):
* ftl/FTLAbbreviations.h:
(FTL):
(JSC::FTL::addIncoming):
(JSC::FTL::buildPhi):
* ftl/FTLAbstractHeapRepository.h:
(FTL):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lowDouble):
(JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIfIsStillValid):
* ftl/FTLOutput.h:
(JSC::FTL::Output::phi):
(Output):
(JSC::FTL::Output::anchor):
* ftl/FTLValueFromBlock.h: Added.
(FTL):
(ValueFromBlock):
(JSC::FTL::ValueFromBlock::ValueFromBlock):
(JSC::FTL::ValueFromBlock::value):
(JSC::FTL::ValueFromBlock::block):
2013-05-10 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support CompareStrictEq
https://bugs.webkit.org/show_bug.cgi?id=115927
Reviewed by Mark Hahnenberg.
Do the sensible thing, and make it so that for common cases, CompareEq is
implemented in terms of CompareStrictEq in the FTL backend. All of the cases
we currently support can be done this way.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileCompareEq):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
2013-05-10 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support Int32ToDouble
https://bugs.webkit.org/show_bug.cgi?id=115926
Reviewed by Mark Hahnenberg.
This node exists mainly to help the DFG see that a node may have both an int
and a double representation. But in the FTL, nodes already have multiple
representations. So this is just a no-op for the FTL.
I considered making it so that the node isn't even inserted if we're doing
FTL compilation, but that would have required a bunch of conditionalizing in
the DFG's optimization phases, which sort of expect this node to be present
and necessary.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble):
(LowerDFGToLLVM):
2013-05-10 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support LogicalNot
https://bugs.webkit.org/show_bug.cgi?id=115924
Reviewed by Mark Hahnenberg.
* ftl/FTLAbbreviations.h:
(JSC::FTL::buildNot):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileLogicalNot):
(LowerDFGToLLVM):
* ftl/FTLOutput.h:
(JSC::FTL::Output::bitNot):
2013-05-10 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support CompareGreater, CompareLessEq, and CompareGreaterEq
https://bugs.webkit.org/show_bug.cgi?id=115923
Reviewed by Mark Hahnenberg.
Also fixed a bug where double CompareLess would assert.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileCompareLess):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
(JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
(JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):
2013-05-10 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL CompareEq ObjectUse should handle masquerading
https://bugs.webkit.org/show_bug.cgi?id=115920
Reviewed by Mark Hahnenberg.
We don't yet support watchpoints, but this does all the wiring right up to the
part where we would have emitted watchpoints. I've also written this in a way that
makes it easy to use the case where you would have anyway speculated non-masquerading
even if the watchpoint was invalidated.
This is inherently racy, of course: but the only race here is that you might first
set the watchpoint, and then the watchpoint is invalidated, and then you compile rest
of the code in a way that doesn't need the watchpoint. That's fine, since the FTL
will remember that it had set the watchpoint and then cancel the compilation.
* ftl/FTLAbbreviations.h:
(JSC::FTL::int8Type):
* ftl/FTLAbstractHeapRepository.h:
(FTL):
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
* ftl/FTLCommonValues.h:
(CommonValues):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::LowerDFGToLLVM::lowNonNullObject):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
(JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIsStillValid):
(JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIfIsStillValid):
* ftl/FTLOutput.h:
(JSC::FTL::Output::constInt8):
(JSC::FTL::Output::load8):
(JSC::FTL::Output::isZero8):
(JSC::FTL::Output::notZero8):
(JSC::FTL::Output::testIsZero8):
(JSC::FTL::Output::testNonZero8):
2013-05-09 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG shouldn't allocate in the GC heap
https://bugs.webkit.org/show_bug.cgi?id=115598
Reviewed by Geoffrey Garen.
I believe that we've now fixed this, and this patch just adds the relevant assertion.
* runtime/JSCellInlines.h:
(JSC::JSCell::JSCell):
2013-05-09 Filip Pizlo <fpizlo@apple.com>
fourthTier: CodeBlock should be RefCounted
https://bugs.webkit.org/show_bug.cgi?id=115594
Reviewed by Geoffrey Garen.
This makes it possible to have the currently-being-compiled CodeBlock not be
installed in Executable, while also allowing it to point to its intended
alternative(). So long as we were using ownership and not reference counting, it
would have been difficult to have both CodeBlock::m_alternative and
Executable::m_codeBlockForBlah point to the previous CodeBlock.
I also took the opportunity to clean up a bunch of code that appears to have
rotted.
* assembler/MacroAssemblerCodeRef.h:
(MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::operator==):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::releaseAlternative):
(JSC::CodeBlock::setAlternative):
(CodeBlock):
(JSC::GlobalCodeBlock::GlobalCodeBlock):
(JSC::ProgramCodeBlock::ProgramCodeBlock):
(JSC::EvalCodeBlock::EvalCodeBlock):
(JSC::FunctionCodeBlock::FunctionCodeBlock):
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::~DFGCodeBlocks):
(JSC::DFGCodeBlocks::jettison):
(JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
* heap/DFGCodeBlocks.h:
(DFGCodeBlocks):
* heap/Heap.cpp:
(JSC::Heap::jettisonDFGCodeBlock):
* heap/Heap.h:
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* runtime/Executable.cpp:
(JSC::jettisonCodeBlock):
(JSC::EvalExecutable::jitCompile):
(JSC::EvalExecutable::compileInternal):
(JSC::ProgramExecutable::jitCompile):
(JSC::ProgramExecutable::compileInternal):
(JSC::FunctionExecutable::jitCompileForCall):
(JSC::FunctionExecutable::jitCompileForConstruct):
(JSC::FunctionExecutable::produceCodeBlockFor):
(JSC::FunctionExecutable::compileForCallInternal):
(JSC::FunctionExecutable::compileForConstructInternal):
* runtime/Executable.h:
(EvalExecutable):
(FunctionExecutable):
(JSC::FunctionExecutable::codeBlockFor):
* runtime/ExecutionHarness.h:
(JSC::prepareForExecution):
(JSC::prepareFunctionForExecution):
2013-05-09 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should have its own notion of StructureChain, and it should be possible to validate it after compilation finishes
https://bugs.webkit.org/show_bug.cgi?id=115841
Reviewed by Oliver Hunt.
This adds IntendedStructureChain, which is like StructureChain, except that it holds a bit
more information and can be validated independantly of its owning Structure and lexical
GlobalObject, since it remembers both of those things. It's also malloc'd and RefCounted
rather than GC'd, so it can be allocated in a concurrent compilation thread.
Gave this class a bunch of methods to allow the following idiom:
- Snapshot a structure chain concurrently. This structure chain may end up being
wrong in case of races, but in that case we will find out when we try to validate
it.
- Perform validation on the structure chain itself, without recomputing the chain.
Previously, many chain validation methods (prototypeChainMayInterceptStoreTo() for
example) recomputed the chain, and hence, were inherently racy: you could build one
chain and then validate against a different chain, and hence not realize that the
chain you did build was actually broken for your purposes, because the chain you
checked was a different one.
- Validate that the chain is still the right one at any time, allowing the cancellation
of compilation if there was a race.
Also added DFG::DesiredStructureChains, which tracks those intended structure chains that
the compiler had already chosen to use. If any of those are invalid at link time, throw
out the compilation.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForChain):
(JSC::GetByIdStatus::computeFor):
* bytecode/GetByIdStatus.h:
(JSC::GetByIdStatus::GetByIdStatus):
(JSC::GetByIdStatus::chain):
(GetByIdStatus):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
* bytecode/PutByIdStatus.h:
(JSC::PutByIdStatus::PutByIdStatus):
(JSC::PutByIdStatus::structureChain):
(PutByIdStatus):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDesiredStructureChains.cpp: Added.
(DFG):
(JSC::DFG::DesiredStructureChains::DesiredStructureChains):
(JSC::DFG::DesiredStructureChains::~DesiredStructureChains):
(JSC::DFG::DesiredStructureChains::areStillValid):
* dfg/DFGDesiredStructureChains.h: Added.
(DFG):
(DesiredStructureChains):
(JSC::DFG::DesiredStructureChains::addLazily):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isStillValid):
(DFG):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::linkFunction):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* runtime/IntendedStructureChain.cpp: Added.
(JSC):
(JSC::IntendedStructureChain::IntendedStructureChain):
(JSC::IntendedStructureChain::~IntendedStructureChain):
(JSC::IntendedStructureChain::isStillValid):
(JSC::IntendedStructureChain::matches):
(JSC::IntendedStructureChain::chain):
(JSC::IntendedStructureChain::mayInterceptStoreTo):
(JSC::IntendedStructureChain::isNormalized):
(JSC::IntendedStructureChain::terminalPrototype):
* runtime/IntendedStructureChain.h: Added.
(JSC):
(IntendedStructureChain):
(JSC::IntendedStructureChain::head):
(JSC::IntendedStructureChain::size):
(JSC::IntendedStructureChain::at):
(JSC::IntendedStructureChain::operator[]):
(JSC::IntendedStructureChain::last):
* runtime/Structure.cpp:
(JSC::Structure::prototypeChainMayInterceptStoreTo):
* runtime/Structure.h:
(Structure):
* runtime/StructureInlines.h:
(JSC::Structure::storedPrototypeObject):
(JSC):
(JSC::Structure::storedPrototypeStructure):
2013-05-06 Mark Lam <mark.lam@apple.com>
Fix broken 32-bit build + some clean up in JITStubs.cpp.
https://bugs.webkit.org/show_bug.cgi?id=115684.
Reviewed by Geoffrey Garen.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JITStubs.cpp:
- removed unneeded stubs for CPU(X86_64) && USE(JSVALUE32_64).
- added some line breaks to more clearly delineate between
ports/configurations of stub code.
2013-05-05 Geoffrey Garen <ggaren@apple.com>
Rolled back in r149527 with crash fixed.
Reviewed by Oliver Hunt.
Rationalized 'this' value conversion
https://bugs.webkit.org/show_bug.cgi?id=115542
This fixes a bunch of Sputnik tests, and some bad pointer access.
The new model is that the callee always performs 'this' value conversion.
My ultimate goal is to break up resolve_with_this into single-result
opcodes. This step avoids having to add a special form of convert_this
that distinguishes callers vs callees.
Only the callee knows whether it uses 'this' and/or whether 'this'
conversion should use StrictMode, so it's most natural to perform
convert_this in the callee.
* API/JSCallbackFunction.cpp:
(JSC::JSCallbackFunction::call): Perform 'this' value conversion for
our callee, since it may observe 'this'.
* API/JSCallbackObjectFunctions.h:
(JSC::::call): Ditto.
* API/JSContextRef.cpp:
(JSGlobalContextCreateInGroup): Use a proxy 'this' object in global scope
even when we're not in the browser. This eliminates some odd cases where
API clients used to be able to get a direct reference to an environment
record. Now, any reference to an environment record unambiguously means
that the VM resolved that record in the scope chain.
(JSContextGetGlobalObject): Removed an incorrect comment. Now that JSC
participates in the proxy 'this' object scheme, the behavior is not
WebCore-only.
* API/JSObjectRef.cpp:
(JSObjectSetPrototype):
(JSObjectCallAsFunction): Don't perform 'this' value conversion in the
caller; the callee will do it if needed.
* JavaScriptCore.order: Order!
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
What are the chances that this will work?
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock): Renamed convert_this to to_this, to match our
other conversion opcodes.
* bytecode/CodeOrigin.h:
(CodeOrigin):
(InlineCallFrame):
(JSC::CodeOrigin::codeOriginOwner): Use the more precise type for our
executable, so compilation can discover where we're in strict mode.
* bytecode/Opcode.h:
(JSC::padOpcodeName): Updated for rename.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator): Always emit to_this when
'this' is in use -- strict mode still needs to convert environment
records to 'undefined'.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.h:
(JSC::DFG::canCompileOpcode): Updated for renames.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Tightened up this code to consider
strict mode (a new requirement) and to consider the global object (which
was always a requirement).
* dfg/DFGGraph.h:
(JSC::DFG::Graph::globalThisObjectFor):
(JSC::DFG::Graph::executableFor):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Ditto.
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
* interpreter/Interpreter.h: Don't ASSERT about 'this' -- it's our job
to fix it up if needed.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
(JIT):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emitSlow_op_to_this):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emitSlow_op_to_this):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* jit/JITStubs.h: Removed special-case code for various kinds of
conversions. The baseline fast path is now final objects only. It hurt
my brain to think through how to keep the other fast paths working, and
our benchmarks do not object.
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
(LLInt):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm: Updated for renames. Removed some
special case code, as in the JIT above.
* profiler/ProfileGenerator.cpp:
(JSC::ProfileGenerator::addParentForConsoleStart):
* runtime/CallData.cpp:
(JSC::call):
* runtime/ClassInfo.h:
(MethodTable):
* runtime/Completion.cpp:
(JSC::evaluate):
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToJSON): The callee performs 'this' conversion, not
the caller.
* runtime/GetterSetter.cpp:
(JSC::callGetter):
(JSC::callSetter):
* runtime/GetterSetter.h: Added helper functions for invoking getters
and setters from C++ code, since this was duplicated in a bunch of
places.
* runtime/JSActivation.cpp:
(JSC::JSActivation::toThis):
* runtime/JSActivation.h:
(JSActivation):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toThisSlowCase):
(JSC::JSValue::putToPrimitive):
* runtime/JSCJSValue.h:
(JSValue):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toThis):
* runtime/JSCell.cpp:
(JSC::JSCell::toThis):
* runtime/JSCell.h:
(JSCell):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::toThis):
* runtime/JSGlobalObject.h:
(JSGlobalObject): Filled out runtime support for converting 'this'
values as needed, according to the appropriate strictness, using
helper functions where getter/setter code was duplicated.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoGetter):
(JSC::globalFuncProtoSetter): Perform 'this' value conversion, since we
observe 'this'.
* runtime/JSNameScope.cpp:
(JSC::JSNameScope::toThis):
* runtime/JSNameScope.h:
(JSNameScope): Same as JSActivation.
* runtime/JSObject.cpp:
(JSC::JSObject::put):
(JSC::JSObject::setPrototypeWithCycleCheck): Bug fix. Don't peform
'this' value conversion in this helper function. The __proto__
setter does this for us, since it's the function that logically observes
'this' -- and we can ASSERT so. Also, the previous code used
"globalExec()->thisValue()", which is a read past the beginning of a
buffer! I don't think this ever worked on purpose.
(JSC::JSObject::toThis):
(JSC::JSObject::fillGetterPropertySlot):
* runtime/JSObject.h:
(JSC::JSObject::inlineGetOwnPropertySlot):
* runtime/JSScope.cpp:
(JSC::JSScope::resolveWithThis):
* runtime/JSString.cpp:
(JSC::JSString::toThis):
* runtime/JSString.h:
(JSString):
* runtime/PropertySlot.cpp:
(JSC::PropertySlot::functionGetter):
* runtime/PropertySlot.h:
(JSC):
(JSC::PropertySlot::setGetterSlot):
(JSC::PropertySlot::setCacheableGetterSlot):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayEntry::get):
(JSC::SparseArrayEntry::put):
* runtime/StrictEvalActivation.cpp:
(JSC::StrictEvalActivation::toThis):
* runtime/StrictEvalActivation.h:
(StrictEvalActivation): Ditto.
2013-05-03 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG::ByteCodeParser doesn't need ExecState*
https://bugs.webkit.org/show_bug.cgi?id=115582
Reviewed by Geoffrey Garen.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::ByteCodeParser):
(ByteCodeParser):
(JSC::DFG::parse):
* dfg/DFGByteCodeParser.h:
(DFG):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
2013-05-02 Filip Pizlo <fpizlo@apple.com>
fourthTier: Profiler should be thread-safe
https://bugs.webkit.org/show_bug.cgi?id=115445
Reviewed by Geoffrey Garen.
Change the Profiler::Database API for Compilation creation so that we don't add
it to the Database until it's completely constructed. This prevents the Database
from seeing Compilations that are being concurrently constructed.
Change the Profiler::Database itself to do locking for creation of Bytecodes and
for modifying the map. This map may be consulted by both the main thread and the
concurrent thread.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::linkFunction):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* profiler/ProfilerBytecodes.h:
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::ensureBytecodesFor):
(JSC::Profiler::Database::notifyDestruction):
(JSC::Profiler::Database::addCompilation):
* profiler/ProfilerDatabase.h:
(Database):
2013-05-02 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG tries to ref/deref StringImpls in a ton of places
https://bugs.webkit.org/show_bug.cgi?id=115300
Reviewed by Geoffrey Garen.
Change any code transitively called from DFG compilation to use StringImpl*
directly instead of String, Identifier, or PropertyName. I use the convention
of passing "StringImpl* uid" instead of an Identifier or PropertyName.
Switch over any code transitively called from DFG compilation to use CStrings
whenever possible for all of its debug dumping.
This makes it possible to compile things without hitting the ref/deref
assertion in StringImpl.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::inferredName):
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::sourceCodeOnOneLine):
(JSC::constantName):
(JSC::idName):
(JSC::CodeBlock::registerName):
(JSC::regexpToSourceString):
(JSC::regexpName):
(JSC::pointerToSourceString):
(JSC::CodeBlock::printUnaryOp):
(JSC::CodeBlock::printBinaryOp):
(JSC::CodeBlock::printConditionalJump):
(JSC::CodeBlock::printGetByIdOp):
(JSC::dumpStructure):
(JSC::CodeBlock::printCallOp):
(JSC::CodeBlock::printPutByIdOp):
(JSC::CodeBlock::printStructure):
(JSC::CodeBlock::printStructures):
(JSC::CodeBlock::dumpBytecode):
* bytecode/CodeBlock.h:
(CodeBlock):
* bytecode/CodeBlockHash.cpp:
(JSC::CodeBlockHash::CodeBlockHash):
* bytecode/CodeOrigin.cpp:
(JSC::InlineCallFrame::inferredName):
* bytecode/CodeOrigin.h:
(InlineCallFrame):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeForChain):
(JSC::GetByIdStatus::computeFor):
* bytecode/GetByIdStatus.h:
(JSC):
(GetByIdStatus):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
* bytecode/PutByIdStatus.h:
(JSC):
(PutByIdStatus):
* bytecode/ReduceWhitespace.cpp:
(JSC::reduceWhitespace):
* bytecode/ReduceWhitespace.h:
(JSC):
* bytecode/ResolveGlobalStatus.cpp:
(JSC::computeForStructure):
(JSC::ResolveGlobalStatus::computeFor):
* bytecode/ResolveGlobalStatus.h:
(JSC):
(ResolveGlobalStatus):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(ByteCodeParser):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDesiredIdentifiers.cpp: Added.
(DFG):
(JSC::DFG::DesiredIdentifiers::DesiredIdentifiers):
(JSC::DFG::DesiredIdentifiers::~DesiredIdentifiers):
(JSC::DFG::DesiredIdentifiers::addLazily):
(JSC::DFG::DesiredIdentifiers::reallyAdd):
* dfg/DFGDesiredIdentifiers.h: Added.
(DFG):
(DesiredIdentifiers):
(JSC::DFG::DesiredIdentifiers::numberOfIdentifiers):
(JSC::DFG::DesiredIdentifiers::at):
(JSC::DFG::DesiredIdentifiers::operator[]):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
(JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::dump):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryBuildGetByIDList):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::identifierUID):
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::compile):
* parser/SourceCode.cpp: Added.
(JSC):
(JSC::SourceCode::toUTF8):
* parser/SourceCode.h:
(SourceCode):
* profiler/ProfilerBytecodes.cpp:
(JSC::Profiler::Bytecodes::toJS):
* profiler/ProfilerBytecodes.h:
(JSC::Profiler::Bytecodes::inferredName):
(JSC::Profiler::Bytecodes::sourceCode):
(Bytecodes):
* runtime/Identifier.h:
(JSC::Identifier::utf8):
(JSC):
* runtime/Structure.cpp:
(JSC::Structure::addPropertyTransitionToExistingStructureImpl):
(JSC::Structure::addPropertyTransitionToExistingStructure):
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
(JSC::Structure::getConcurrently):
(JSC::Structure::prototypeChainMayInterceptStoreTo):
(JSC):
* runtime/Structure.h:
(Structure):
* runtime/StructureInlines.h:
(JSC::Structure::getConcurrently):
2013-05-02 Filip Pizlo <fpizlo@apple.com>
fourthTier: Structure transition table keys don't have to ref their StringImpl's
https://bugs.webkit.org/show_bug.cgi?id=115525
Reviewed by Geoffrey Garen.
The structure transition table basically maps string to structure. The string is
always also stored, and ref'd, in the structure in Structure::m_nameInPrevious.
m_nameInPrevious is never mutated, and never cleared. The string cannot die unless
the structure dies. If the structure dies, then that entry in the transition map
becomes a zombie anyway and we will detect this separately.
So, we don't need to use RefPtr<StringImpl>. We can just use StringImpl*.
This also fixes a goof where we were getting the StringImpl's hash rather than
using a pointer hash. Not only is the latter faster, but it prevents my change
from leading to crashes: with my change we can have zombie keys, not just zombie
values. They will exist only until the next map mutation, which will clear them.
Lookups will work fine because the lookup routine will reject zombies. But it
does mean that the HashMap will have to deal with dangling StringImpl*'s; all it
takes to make this work is to ensure that the HashMap itself never dereferences
them. Using a pointer hash rather than StringImpl::existingHash() accomplishes
this.
This also ensures that we don't accidentally call ref() or deref() from the
compilation thread, if the compilation thread inspects the transition table.
And no, we wouldn't have been able to use the HashMap<RefPtr<...>, ...>
specialization, because the transition table is actually
HashMap<pair<RefPtr<StringImpl>, unsigned>, ...>: hence that specialization
doesn't kick in. We could have written a new specialization or something, but
that seemed like a lot of work given that we don't need the table to be ref'ing
the strings anyways.
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::add):
* runtime/StructureTransitionTable.h:
(StructureTransitionTable):
(Hash):
(JSC::StructureTransitionTable::Hash::hash):
2013-05-01 Filip Pizlo <fpizlo@apple.com>
fourthTier: Structure::addPropertyTransitionToExistingStructure should be thread-safe
https://bugs.webkit.org/show_bug.cgi?id=115468
Reviewed by Geoffrey Garen.
This makes the main thread modify the transition table while holding a lock. Note
that the GC might modify its weak pointers without locking, but the GC will lock out
the compilation thread anyway. The map will then only reshape in response to add()
and set(), which happen while holding a lock.
This allows the compilation thread to now query transition tables safely, provided it
holds a lock when doing so.
Also changed LLVM asm printer initialization to just initialize the X86 one. It makes
sense for us to just initialize the asm printer(s) that we actually use; you could
imagine us being linked to a system LLVM that has cross-compilation support; there is
no point in the WebKit or JSC process doing work to initialize all of those targets.
That part was rubber stamped by Mark Hahnenberg.
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreadingOnce):
* runtime/Structure.cpp:
(JSC::Structure::addPropertyTransitionToExistingStructureImpl):
(JSC::Structure::addPropertyTransitionToExistingStructure):
(JSC):
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
(JSC::Structure::addPropertyTransition):
(JSC::Structure::nonPropertyTransition):
* runtime/Structure.h:
(Structure):
2013-04-30 Filip Pizlo <fpizlo@apple.com>
fourthTier: Structure::getConcurrently() may be called from for uncacheable dictionaries, and this is safe
https://bugs.webkit.org/show_bug.cgi?id=115464
Reviewed by Oliver Hunt and Geoffrey Garen.
This can happen for example transitively from JSObject::put(). getCurrently() does
work for uncacheable dictionaries; it just has the obvious race that right after it
returns, the result it returned may no longer be right. This isn't an issue if it was
called on the main thread, and may not be an issue in some other situations.
So, we should just remove the assertion, since the only thing it buys us is crashes.
* runtime/Structure.cpp:
(JSC::Structure::getConcurrently):
2013-04-30 Filip Pizlo <fpizlo@apple.com>
fourthTier: Don't link gtest into JavaScriptCore
Rubber stamped by Mark Rowe.
* Configurations/JavaScriptCore.xcconfig:
2013-04-29 Filip Pizlo <fpizlo@apple.com>
fourthTier: String::utf8() should also be available as StringImpl::utf8() so that you don't have to ref() a StringImpl just to get its utf8()
https://bugs.webkit.org/show_bug.cgi?id=115393
Reviewed by Geoffrey Garen.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode):
2013-07-16 Oliver Hunt <oliver@apple.com>
Merge dfgFourthTier r149301
2013-04-28 Filip Pizlo <fpizlo@apple.com>
fourthTier: ASSERT that commonly used not-thread-safe methods in the runtime are not being called during compilation
https://bugs.webkit.org/show_bug.cgi?id=115297
Reviewed by Geoffrey Garen.
Put in assertions that we're not doing bad things in compilation threads. Also
factored compilation into compile+link so that even though we don't yet have
concurrent compilation, we can be explicit about which parts of DFG work are
meant to be concurrent, and which aren't.
Also fix a handful of bugs found by these assertions.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ResolveGlobalStatus.cpp:
(JSC::computeForStructure):
* bytecode/Watchpoint.cpp:
(JSC::WatchpointSet::add):
(JSC::InlineWatchpointSet::inflateSlow):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::~JITCompiler):
(DFG):
(JSC::DFG::JITCompiler::compileBody):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::linkFunction):
* dfg/DFGJITCompiler.h:
(JITCompiler):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLCompile.h:
(FTL):
* ftl/FTLLink.cpp: Added.
(FTL):
(JSC::FTL::compileEntry):
(JSC::FTL::link):
* ftl/FTLLink.h: Added.
(FTL):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* ftl/FTLState.h:
(FTL):
(State):
* runtime/Structure.cpp:
(JSC::Structure::get):
(JSC::Structure::prototypeChainMayInterceptStoreTo):
* runtime/Structure.h:
(JSC::Structure::materializePropertyMapIfNecessary):
* runtime/StructureInlines.h:
(JSC::Structure::get):
2013-04-27 Filip Pizlo <fpizlo@apple.com>
FTL should support double variables
https://bugs.webkit.org/show_bug.cgi?id=113624
Reviewed by Geoffrey Garen.
Made all of the operations that the FTL already supports, also support doubles.
OSR exit already basically had everything it needed, so no changes there. This
mostly just glues together bits of DFG IR to LLVM IR, in a straight-forward way.
* ftl/FTLAbbreviations.h:
(FTL):
(JSC::FTL::doubleType):
(JSC::FTL::constReal):
(JSC::FTL::buildPhi):
(JSC::FTL::addIncoming):
(JSC::FTL::buildFAdd):
(JSC::FTL::buildFSub):
(JSC::FTL::buildFMul):
(JSC::FTL::buildFNeg):
(JSC::FTL::buildSIToFP):
(JSC::FTL::buildUIToFP):
(JSC::FTL::buildBitCast):
(JSC::FTL::buildFCmp):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
* ftl/FTLCommonValues.h:
(CommonValues):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileGetLocal):
(JSC::FTL::LowerDFGToLLVM::compileSetLocal):
(JSC::FTL::LowerDFGToLLVM::compileAdd):
(JSC::FTL::LowerDFGToLLVM::compileArithSub):
(JSC::FTL::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::LowerDFGToLLVM::compileArithNegate):
(JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::LowerDFGToLLVM::compileCompareLess):
(JSC::FTL::LowerDFGToLLVM::lowDouble):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lowJSValue):
(JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
(JSC::FTL::LowerDFGToLLVM::unboxDouble):
(JSC::FTL::LowerDFGToLLVM::boxDouble):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::speculateNumber):
(JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
(JSC::FTL::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
* ftl/FTLOutput.h:
(JSC::FTL::Output::constDouble):
(Output):
(JSC::FTL::Output::phi):
(JSC::FTL::Output::doubleAdd):
(JSC::FTL::Output::doubleSub):
(JSC::FTL::Output::doubleMul):
(JSC::FTL::Output::doubleNeg):
(JSC::FTL::Output::intToFP):
(JSC::FTL::Output::intToDouble):
(JSC::FTL::Output::unsignedToFP):
(JSC::FTL::Output::unsignedToDouble):
(JSC::FTL::Output::bitCast):
(JSC::FTL::Output::loadDouble):
(JSC::FTL::Output::storeDouble):
(JSC::FTL::Output::doubleEqual):
(JSC::FTL::Output::doubleNotEqualOrUnordered):
(JSC::FTL::Output::doubleLessThan):
(JSC::FTL::Output::doubleLessThanOrEqual):
(JSC::FTL::Output::doubleGreaterThan):
(JSC::FTL::Output::doubleGreaterThanOrEqual):
(JSC::FTL::Output::doubleEqualOrUnordered):
(JSC::FTL::Output::doubleNotEqual):
(JSC::FTL::Output::doubleLessThanOrUnordered):
(JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
(JSC::FTL::Output::doubleGreaterThanOrUnordered):
(JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
(JSC::FTL::Output::testIsZero64):
2013-04-27 Filip Pizlo <fpizlo@apple.com>
fourthTier: SymbolTable should be thread-safe
https://bugs.webkit.org/show_bug.cgi?id=115301
Reviewed by Geoffrey Garen.
Makes SymbolTable thread-safe. Relies on SymbolTableEntry already being immutable,
other than the WatchpointSet; but the WatchpointSet already has a righteous
concurrency protocol. So, this patch just protects the SymbolTable's HashMap.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::nameForRegister):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addVar):
* runtime/Executable.cpp:
(JSC::ProgramExecutable::addGlobalVar):
* runtime/JSActivation.cpp:
(JSC::JSActivation::getOwnNonIndexPropertyNames):
(JSC::JSActivation::symbolTablePutWithAttributes):
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
(JSC::symbolTablePut):
(JSC::symbolTablePutWithAttributes):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::SymbolTable):
(JSC::SymbolTable::~SymbolTable):
* runtime/SymbolTable.h:
(JSC::SymbolTable::find):
(JSC::SymbolTable::get):
(JSC::SymbolTable::inlineGet):
(JSC::SymbolTable::begin):
(JSC::SymbolTable::end):
(JSC::SymbolTable::size):
(JSC::SymbolTable::add):
(JSC::SymbolTable::set):
(JSC::SymbolTable::contains):
2013-04-26 Filip Pizlo <fpizlo@apple.com>
fourthTier: WatchpointSet should make racy uses easier to reason about
https://bugs.webkit.org/show_bug.cgi?id=115299
Reviewed by Anders Carlsson.
The compiler often does things like:
1c) Observe something that would imply that a WatchpointSet ought to be invalid
2c) Check that it is invalid
The main thread often does things like:
1m) Fire the watchpoint set
2m) Do some other thing that would cause the compiler to assume that the WatchpointSet
ought to be invalid
An example is structure transitions, where (1c) is the compiler noticing that a
put_by_id inline cache is in a transition state, with the source structure being S;
(2c) is the compiler asserting that S's watchpoint set is invalid; (1m) is the main
thread firing S's watchpoint set before it does the first transition away from S; and
(2m) is the main thread caching the put_by_id transition away from S.
This is totally fine, except that (1c) and (2c), and (1m) and (2m) could be reordered.
Probably, in most cases, this ought to do enough things that the main thread probably
already has some fencing. But the compiler thread definitely doesn't have fencing. In
any case, we should play it safe and just have additional fencing in all of the
relevant places.
We already have some idioms to put load-load and store-store fences in the right
places. But this change just makes WatchpointSet take care of this for us, thus
reducing the chances of us getting this wrong.
* bytecode/Watchpoint.cpp:
(JSC::WatchpointSet::notifyWriteSlow):
* bytecode/Watchpoint.h:
(WatchpointSet):
(JSC::WatchpointSet::isStillValid):
(JSC::WatchpointSet::hasBeenInvalidated):
(JSC::InlineWatchpointSet::hasBeenInvalidated):
(JSC::InlineWatchpointSet::notifyWrite):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState):
2013-07-16 Oliver Hunt <oliver@apple.com>
Merge dfgFourthTier r149233
2013-04-26 Filip Pizlo <fpizlo@apple.com>
fourthTier: CFA should defend against results seeming inconsistent due to a watchpoint firing during compilation
https://bugs.webkit.org/show_bug.cgi?id=115083
Reviewed by Geoffrey Garen.
This ruggedizes our racyness with respect to watchpoints. We want to be able to assert,
in some places, that a watchpoint-based optimization has only occurred if the
watchpoint set was still valid. But currently we *can* soundly do watchpoint-based
optimizations even for invalid watchpoints, so long as we recorded in the IR that we
had done so; this will then lead to the code being insta-jettisoned after compilation
completes. Obviously, we don't want this to happen often - but we do want to allow it
precisely in the case of watchpoint races.
This adds the ability to assert that we hadn't over-watchpointed ourselves, with and
exemption for races.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::setFuturePossibleStructure):
(JSC::DFG::AbstractValue::filterFuturePossibleStructure):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addStructureTransitionCheck):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
* dfg/DFGDesiredWatchpoints.h:
(GenericDesiredWatchpoints):
(JSC::DFG::GenericDesiredWatchpoints::isStillValid):
(JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState):
(JSC::DFG::GenericDesiredWatchpoints::isValidOrMixed):
(JSC::DFG::DesiredWatchpoints::isStillValid):
(JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState):
(JSC::DFG::DesiredWatchpoints::isValidOrMixed):
(DesiredWatchpoints):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::masqueradesAsUndefinedWatchpointIsStillValid):
(Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addLazily):
(JITCompiler):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
(JSC::DFG::SpeculativeJIT::speculationWatchpointForMasqueradesAsUndefined):
(JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLState.h:
(State):
2013-04-23 Filip Pizlo <fpizlo@apple.com>
fourthTier: AbstractValue methods that deal with watchpoints should have access to Graph, so that in debug mode, Graph can track the history of watchpoint states and detect races
https://bugs.webkit.org/show_bug.cgi?id=115084
Reviewed by Geoffrey Garen.
The idea is that as part of https://bugs.webkit.org/show_bug.cgi?id=115083, I'll have
Graph record the initial state of a watchpoint at the time that we decide to take
advantage of it; then I will use this to disable any watchpoint-related assertions
in debug mode. Note that this "watchpoint cache" will only be maintained in debug
mode, so there will be no release performance implications. But to do this, I need to
ensure that all of the places that reason about watchpoints have access to Graph.
For example, I'll want AbstractValue::setFuturePossibleStructure to record the state
of the watchpoint in Graph so that subsequent assertions can check if the watchpoint's
state had changed since that decision was made.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::initialize):
(JSC::DFG::AbstractState::executeEffects):
(JSC::DFG::AbstractState::mergeStateAtTail):
* dfg/DFGAbstractState.h:
(JSC::DFG::AbstractState::trySetConstant):
* dfg/DFGAbstractValue.cpp: Added.
(DFG):
(JSC::DFG::AbstractValue::setMostSpecific):
(JSC::DFG::AbstractValue::set):
(JSC::DFG::AbstractValue::filter):
(JSC::DFG::AbstractValue::setFuturePossibleStructure):
(JSC::DFG::AbstractValue::filterFuturePossibleStructure):
(JSC::DFG::AbstractValue::dump):
* dfg/DFGAbstractValue.h:
(DFG):
(AbstractValue):
(JSC::DFG::AbstractValue::setType):
(JSC::DFG::AbstractValue::filterByValue):
2013-07-16 Oliver Hunt <oliver@apple.com>
Merge dfgFourthTier r148936
2013-04-22 Filip Pizlo <fpizlo@apple.com>
fourthTier: Create an equivalent of Structure::get() that can work from a compilation thread
https://bugs.webkit.org/show_bug.cgi?id=114987
Reviewed by Geoffrey Garen.
This completes the work started by r148570. That patch made it possible to do
Structure::get() without modifying Structure. This patch takes this further, and
makes this thread-safe (for non-uncacheable-dictionaries) via
Structure::getConcurrently(). This method not only doesn't modify Structure, but
also ensures that any concurrent attempts to add to, remove from, or steal the
table from that structure doesn't mess up the result of the call. The call may
return invalidOffset even if a property is *just* about to be added, but it will
never do the reverse: if it returns a property then you can be sure that the
structure really does have that property and always will have it.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeForChain):
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
* runtime/PropertyMapHashTable.h:
(PropertyTable):
(JSC::PropertyTable::findConcurrently):
(JSC):
(JSC::PropertyTable::add):
(JSC::PropertyTable::remove):
(JSC::PropertyTable::reinsert):
(JSC::PropertyTable::rehash):
* runtime/PropertyTable.cpp:
(JSC::PropertyTable::PropertyTable):
* runtime/Structure.cpp:
(JSC::Structure::findStructuresAndMapForMaterialization):
(JSC::Structure::getConcurrently):
* runtime/Structure.h:
(Structure):
* runtime/StructureInlines.h:
(JSC::Structure::getConcurrently):
2013-07-16 Oliver Hunt <oliver@apple.com>
Merge dfgFourthTier r148850
2013-04-21 Filip Pizlo <fpizlo@apple.com>
fourthTier: WebKit's build system should relink JavaScriptCore if LLVM's libraries changed but its headers didn't
https://bugs.webkit.org/show_bug.cgi?id=114926
Reviewed by Geoffrey Garen.
Use a phony file that includes a phony header to force JavaScriptCore to be relinked
if necessary. The external LLVM-importing scripts will touch the header if the libraries
are known to have changed.
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/WebKitLLVMLibraryAnchor.cpp: Added.
2013-07-16 Oliver Hunt <oliver@apple.com>
Merge dfgFourthTier r148836
2013-04-21 Filip Pizlo <fpizlo@apple.com>
fourthTier: It should be possible to query WatchpointSets, and add Watchpoints, even if the compiler is running in another thread
https://bugs.webkit.org/show_bug.cgi?id=114909
Reviewed by Oliver Hunt.
The idea here is that a concurrent compiler will use watchpoint sets as follows:
During concurrent compilation: It will create Watchpoints, and query WatchpointSets only
for the purpose of profiling. That is, it will use decide whether it is profitable to
compile the code "as if" the watchpoint sets are valid.
During synchronous linking: By "linking" I don't necessarily mean the LinkBuffer stuff,
but just the very bitter end of compilation where we make the JIT code callable. This
can happen after LinkBuffer stuff. Anyway, this will have to happen synchronously, and
at that point we can (a) check that all WatchpointSets that we assumed were valid are
still valid and (b) if they are then we add the watchpoints to those sets. If any of the
sets are invalid, we give up on this compilation and try again later.
The querying of WatchpointSets is engineered to say that the set is still valid if it
is so *right now*, but this is done in a racy way and so it may say so spuriously: we
may, with hopefully low probability, have a set that says it is valid even though it was
just invalidated. The goal is only to ensure that (i) a set never claims to be invalid
if it is actually valid, (ii) a set doesn't claim to be valid if it was invalidated
before compilation even began, and (iii) querying the validity of a set doesn't cause us
to crash.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/Watchpoint.cpp:
(JSC::InlineWatchpointSet::inflateSlow):
* bytecode/Watchpoint.h:
(WatchpointSet):
(InlineWatchpointSet):
(JSC::InlineWatchpointSet::hasBeenInvalidated):
(JSC::InlineWatchpointSet::isThin):
(JSC::InlineWatchpointSet::isFat):
(JSC::InlineWatchpointSet::fat):
* dfg/DFGDesiredWatchpoints.cpp: Added.
(DFG):
(JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
(JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints):
(JSC::DFG::DesiredWatchpoints::addLazily):
(JSC::DFG::DesiredWatchpoints::reallyAdd):
(JSC::DFG::DesiredWatchpoints::areStillValid):
* dfg/DFGDesiredWatchpoints.h: Added.
(DFG):
(JSC::DFG::WatchpointForGenericWatchpointSet::WatchpointForGenericWatchpointSet):
(WatchpointForGenericWatchpointSet):
(GenericDesiredWatchpoints):
(JSC::DFG::GenericDesiredWatchpoints::GenericDesiredWatchpoints):
(JSC::DFG::GenericDesiredWatchpoints::addLazily):
(JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
(JSC::DFG::GenericDesiredWatchpoints::areStillValid):
(DesiredWatchpoints):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addLazily):
(JITCompiler):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLCompile.h:
(FTL):
* ftl/FTLState.h:
(State):
* runtime/JSFunction.h:
(JSFunction):
(JSC::JSFunction::allocationProfileWatchpointSet):
* runtime/Structure.h:
(Structure):
(JSC::Structure::transitionWatchpointSet):
2013-07-16 Oliver Hunt <oliver@apple.com>
Merge dfgFourthTier r148804
2013-04-20 Filip Pizlo <fpizlo@apple.com>
fourthTier: value profiles and array profiles should be thread-safe enough to be accessible in a concurrent compilation thread
https://bugs.webkit.org/show_bug.cgi?id=114906
Reviewed by Oliver Hunt.
This introduces thread safety to value profiles, array profiles, and
array allocation profiles.
We already have three separate operations that happen on profiles:
(1) writing, which the JIT, LLInt, and OSR exit do; (2) updating,
which happens during GC, from OSR entry slow-paths, and in the DFG;
and (3) reading, which happens in the DFG. For example, the JIT/LLInt
and OSR exit write to ValueProfile::m_buckets, which gets synthesized
into ValueProfile::m_prediction (and other fields) during update, and
the latter gets read by the DFG. Note that (2) must also happen in
the DFG since only the DFG knows which code blocks it will inline,
and those blocks' profiles may not have otherwise been updated via
any other mechanism.
I refer to these three operations as writing, updating, and reading.
Consequently, both profile updating and profile reading may happen
asynchronously, if the JIT is asynchronous.
The locking protocol for profiles works as follows:
- Writing does not require locking, but is only allowed on the main
thread. We require that these fields can be stored atomically by
the profiling code, even without locks. For value profiles, this
only works on 64-bit platforms, currently. For array profiles,
which consist of multiple separate fields, this means that an
asynchronous update of the profile may see slight inconsistencies
(like a structure that doesn't quite match the array modes bits),
but these should be harmless: at worst, the DFG will specialize
too much and we'll have OSR exits.
- Updating a value profile requires holding a lock, but must assume
that the fields written by the profiling code in JIT/LLInt may
be written to without locking.
- Reading a value profile requires holding a lock.
The one major exception to these rules is the ArrayAllocationProfile,
which requires no locking. We do this because it's used so often and
in places where we don't necessarily have access to the owning
CodeBlock, so if we did want it to be locked it would have to have
its own lock. Also, I believe that it is sound to just make this
profile racy and not worry about locking at all. All that was needed
were some changes to ensure that we explicitly read some raced-over
fields only once.
Two additional interesting things in this change:
- To make it easy to see which profile methods require locking, they
take a const CodeBlockLocker& as an argument. I saw this idiom for
identifying which methods require which locks to be held being used
in LLVM, and I quite like it.
- Lazy operand value profiles, which are created lazily and at any
time, require the CodeBlockLock to be held when they are being
created. Writes to them are lockless and main-thread-only, but as
with other profiles, updates and reads require locking.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ArrayAllocationProfile.cpp:
(JSC::ArrayAllocationProfile::updateIndexingType):
* bytecode/ArrayAllocationProfile.h:
(JSC::ArrayAllocationProfile::selectIndexingType):
* bytecode/ArrayProfile.cpp:
(JSC::ArrayProfile::computeUpdatedPrediction):
(JSC::ArrayProfile::briefDescription):
* bytecode/ArrayProfile.h:
(ArrayProfile):
(JSC::ArrayProfile::expectedStructure):
(JSC::ArrayProfile::structureIsPolymorphic):
(JSC::ArrayProfile::hasDefiniteStructure):
(JSC::ArrayProfile::observedArrayModes):
(JSC::ArrayProfile::mayInterceptIndexedAccesses):
(JSC::ArrayProfile::mayStoreToHole):
(JSC::ArrayProfile::outOfBounds):
(JSC::ArrayProfile::usesOriginalArrayStructures):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpValueProfiling):
(JSC::CodeBlock::dumpArrayProfiling):
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::updateAllArrayPredictions):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
(JSC::CodeBlock::updateAllPredictionsAndCheckIfShouldOptimizeNow):
(CodeBlock):
* bytecode/CodeBlockLock.h: Added.
(JSC):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/LazyOperandValueProfile.cpp:
(JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
(JSC::CompressedLazyOperandValueProfileHolder::add):
(JSC::LazyOperandValueProfileParser::LazyOperandValueProfileParser):
(JSC::LazyOperandValueProfileParser::~LazyOperandValueProfileParser):
(JSC):
(JSC::LazyOperandValueProfileParser::initialize):
(JSC::LazyOperandValueProfileParser::prediction):
* bytecode/LazyOperandValueProfile.h:
(CompressedLazyOperandValueProfileHolder):
(LazyOperandValueProfileParser):
* bytecode/MethodOfGettingAValueProfile.cpp:
(JSC::MethodOfGettingAValueProfile::getSpecFailBucket):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecode/ResolveGlobalStatus.cpp:
(JSC::ResolveGlobalStatus::computeFor):
* bytecode/ValueProfile.h:
(JSC::ValueProfileBase::briefDescription):
(ValueProfileBase):
(JSC::ValueProfileBase::computeUpdatedPrediction):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::fromObserved):
* dfg/DFGArrayMode.h:
(ArrayMode):
(JSC::DFG::ArrayMode::withProfile):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::getArrayMode):
(JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOSRExitPreparation.cpp:
(JSC::DFG::prepareCodeOriginForOSRExit):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* jit/JITInlines.h:
(JSC::JIT::chooseArrayMode):
* jit/JITStubs.cpp:
(JSC::tryCachePutByID):
(JSC::tryCacheGetByID):
(JSC::DEFINE_STUB_FUNCTION):
(JSC::lazyLinkFor):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setUpCall):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::BytecodeSequence):
* runtime/JSScope.cpp:
(JSC::JSScope::resolveContainingScopeInternal):
(JSC::JSScope::resolvePut):
2013-04-17 Filip Pizlo <fpizlo@apple.com>
fourthTier: all inline caches should thread-safe enough to allow a concurrent compilation thread to read them safely
https://bugs.webkit.org/show_bug.cgi?id=114762
Reviewed by Mark Hahnenberg.
For most inline caches this is easy: the inline cache has a clean temporal
separation between doing the requested action (which may take an unbounded
amount of time, may recurse, and may do arbitrary things) and recording the
relevant information in the cache. So, we just put locks around the
recording bit. That part is always O(1) and does not recurse. The lock we
use is per-CodeBlock to achieve a good balance between locking granularity
and low space overhead. So a concurrent compilation thread will only block
if an inline cache ping-pongs in the code block being compiled (or inlined)
and never when other inline caches do things.
For resolve operations, it's a bit tricky. The global resolve bit works
like any other IC in that it has the clean temporal separation. But the
operations vector itself doesn't have this separation, since we will be
filling it in tandem with actions that may take a long time. This patch
gets around this by having a m_ready bit in the ResolveOperations and
PutToBaseOperation. This is set while holding the CodeBlock's lock. If the
DFG observes the m_ready bit not set (while holding the lock) then it
conservatively assumes that the resolve hasn't happened yet and just
plants a ForceOSRExit.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
* bytecode/CodeBlock.h:
(CodeBlock):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecode/ResolveGlobalStatus.cpp:
(JSC::ResolveGlobalStatus::computeFor):
* bytecode/ResolveOperation.h:
(JSC::ResolveOperations::ResolveOperations):
(ResolveOperations):
(JSC::PutToBaseOperation::PutToBaseOperation):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
* jit/JITStubs.cpp:
(JSC::tryCachePutByID):
(JSC::tryCacheGetByID):
(JSC::DEFINE_STUB_FUNCTION):
(JSC::lazyLinkFor):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setUpCall):
* runtime/JSScope.cpp:
(JSC::JSScope::resolveContainingScopeInternal):
(JSC::JSScope::resolveContainingScope):
(JSC::JSScope::resolvePut):
2013-04-16 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should be able to query Structure without modifying it
https://bugs.webkit.org/show_bug.cgi?id=114708
Reviewed by Oliver Hunt.
This is work towards allowing the DFG, and FTL, to run on a separate thread.
The idea is that the most evil thing that the DFG does that has thread-safety
issues is fiddling with Structures by calling Structure::get(). This can lead
to rematerialization of property tables, which is definitely not thread-safe
due to how StringImpl works. So, this patch completely side-steps the problem
by creating a new version of Structure::get, called
Structure::getWithoutMaterializing, which may choose to do an O(n) search if
necessary to avoid materialization. I believe this should be fine - the DFG
does't call into these code path often enough for this to matter, and most of
the time, the Structure that we call this on will already have a property
table because some inline cache would have already called ::get() on that
Structure.
Also cleaned up the materialization logic: we can stop the search as soon as
we find any Structure with a property table rather than searching all the way
for a pinned one.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
* runtime/Structure.cpp:
(JSC::Structure::findStructuresAndMapForMaterialization):
(JSC::Structure::materializePropertyMap):
(JSC::Structure::getWithoutMaterializing):
(JSC):
* runtime/Structure.h:
(Structure):
* runtime/StructureInlines.h:
(JSC::Structure::getWithoutMaterializing):
(JSC):
2013-04-13 Filip Pizlo <fpizlo@apple.com>
fourthTier: Fix release build.
* dfg/DFGOSRExitCompilerCommon.cpp:
* ftl/FTLExitValue.cpp:
* ftl/FTLOSRExitCompiler.cpp:
2013-04-13 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should have OSR exit
https://bugs.webkit.org/show_bug.cgi?id=113623
Reviewed by Oliver Hunt.
This implements OSR exit, and hilariously, it actually works. The idea is to have
LLVM call a no-return function on the off-ramp, passing it everything we know about
bytecode state that isn't already flushed to the call frame. Our own JIT takes care
of the rest.
We can now run all of SunSpider, V8, and Kraken with the FTL enabled.
The details are described in FTLOSRExit.h.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* assembler/AbstractMacroAssembler.h:
(Address):
(JSC::AbstractMacroAssembler::Address::withOffset):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::offsetOf):
(LinkBuffer):
* assembler/MacroAssemblerX86Common.h:
* assembler/RepatchBuffer.h:
(JSC::RepatchBuffer::RepatchBuffer):
(JSC::RepatchBuffer::~RepatchBuffer):
(RepatchBuffer):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/Operands.h:
(Operands):
(JSC):
(JSC::::dump):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::initialize):
* dfg/DFGGPRInfo.h:
(DFG):
(GPRInfo):
* dfg/DFGMinifiedNode.h:
(JSC::DFG::belongsInMinifiedGraph):
* dfg/DFGNodeType.h:
(JSC::DFG::needsOSRBackwardRewiring):
(DFG):
(JSC::DFG::needsOSRForwardRewiring):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
(DFG):
(JSC::DFG::OSRExit::convertToForward):
* dfg/DFGOSRExit.h:
(OSRExit):
* dfg/DFGOSRExitBase.cpp: Added.
(DFG):
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
(JSC::DFG::OSRExitBase::doSearchForForwardConversion):
* dfg/DFGOSRExitBase.h: Added.
(DFG):
(JSC::DFG::OSRExitBase::OSRExitBase):
(OSRExitBase):
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::handleExitCounts):
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitCompilerCommon.h:
(DFG):
* dfg/DFGOSRExitPreparation.cpp: Added.
(DFG):
(JSC::DFG::prepareCodeOriginForOSRExit):
* dfg/DFGOSRExitPreparation.h: Added.
(DFG):
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
* dfg/DFGValueSource.h:
(JSC::DFG::ValueSource::forSpeculation):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct):
* ftl/FTLAbbreviations.h:
(JSC::FTL::functionType):
(FTL):
(JSC::FTL::typeOf):
(JSC::FTL::appendBasicBlock):
(JSC::FTL::insertBasicBlock):
(JSC::FTL::buildCall):
(JSC::FTL::setTailCall):
* ftl/FTLCArgumentGetter.cpp: Added.
(FTL):
(JSC::FTL::CArgumentGetter::loadNextAndBox):
* ftl/FTLCArgumentGetter.h: Added.
(FTL):
(JSC::FTL::isArgumentRegister):
(CArgumentGetter):
(JSC::FTL::CArgumentGetter::CArgumentGetter):
(JSC::FTL::CArgumentGetter::loadNext8):
(JSC::FTL::CArgumentGetter::loadNext32):
(JSC::FTL::CArgumentGetter::loadNext64):
(JSC::FTL::CArgumentGetter::loadNextPtr):
(JSC::FTL::CArgumentGetter::loadNextDouble):
(JSC::FTL::CArgumentGetter::nextAddress):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLExitArgument.cpp: Added.
(FTL):
(JSC::FTL::ExitArgument::dump):
* ftl/FTLExitArgument.h: Added.
(FTL):
(ExitArgumentRepresentation):
(ExitArgument):
(JSC::FTL::ExitArgument::ExitArgument):
(JSC::FTL::ExitArgument::operator!):
(JSC::FTL::ExitArgument::format):
(JSC::FTL::ExitArgument::argument):
(JSC::FTL::ExitArgument::withFormat):
(JSC::FTL::ExitArgument::representation):
* ftl/FTLExitArgumentForOperand.cpp: Added.
(FTL):
(JSC::FTL::ExitArgumentForOperand::dump):
* ftl/FTLExitArgumentForOperand.h: Added.
(FTL):
(ExitArgumentForOperand):
(JSC::FTL::ExitArgumentForOperand::ExitArgumentForOperand):
(JSC::FTL::ExitArgumentForOperand::operator!):
(JSC::FTL::ExitArgumentForOperand::exitArgument):
(JSC::FTL::ExitArgumentForOperand::operand):
(JSC::FTL::lesserArgumentIndex):
* ftl/FTLExitArgumentList.h: Added.
(FTL):
* ftl/FTLExitThunkGenerator.cpp: Added.
(FTL):
(JSC::FTL::ExitThunkGenerator::ExitThunkGenerator):
(JSC::FTL::ExitThunkGenerator::~ExitThunkGenerator):
(JSC::FTL::ExitThunkGenerator::emitThunk):
* ftl/FTLExitThunkGenerator.h: Added.
(FTL):
(ExitThunkGenerator):
(JSC::FTL::ExitThunkGenerator::didThings):
* ftl/FTLExitValue.cpp: Added.
(FTL):
(JSC::FTL::ExitValue::dump):
* ftl/FTLExitValue.h: Added.
(FTL):
(ExitValue):
(JSC::FTL::ExitValue::ExitValue):
(JSC::FTL::ExitValue::operator!):
(JSC::FTL::ExitValue::dead):
(JSC::FTL::ExitValue::inJSStack):
(JSC::FTL::ExitValue::inJSStackAsInt32):
(JSC::FTL::ExitValue::inJSStackAsDouble):
(JSC::FTL::ExitValue::constant):
(JSC::FTL::ExitValue::exitArgument):
(JSC::FTL::ExitValue::kind):
(JSC::FTL::ExitValue::isDead):
(JSC::FTL::ExitValue::isInJSStackSomehow):
(JSC::FTL::ExitValue::isConstant):
(JSC::FTL::ExitValue::isArgument):
* ftl/FTLFormattedValue.h:
(FTL):
(JSC::FTL::noValue):
(JSC::FTL::int32Value):
(JSC::FTL::uInt32Value):
(JSC::FTL::booleanValue):
(JSC::FTL::jsValueValue):
(JSC::FTL::doubleValue):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::initializeExitThunks):
(FTL):
(JSC::FTL::JITCode::exitThunks):
* ftl/FTLJITCode.h:
(JITCode):
* ftl/FTLLowerDFGToLLVM.cpp:
(FTL):
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
(JSC::FTL::LowerDFGToLLVM::compileBlock):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileGetLocal):
(JSC::FTL::LowerDFGToLLVM::compileSetLocal):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileMovHint):
(JSC::FTL::LowerDFGToLLVM::compileZombieHint):
(JSC::FTL::LowerDFGToLLVM::compileMovHintAndCheck):
(JSC::FTL::LowerDFGToLLVM::compileAdd):
(JSC::FTL::LowerDFGToLLVM::compileArithSub):
(JSC::FTL::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::LowerDFGToLLVM::compileArithNegate):
(JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
(JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::LowerDFGToLLVM::speculateBackward):
(JSC::FTL::LowerDFGToLLVM::speculateForward):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::terminate):
(JSC::FTL::LowerDFGToLLVM::backwardTypeCheck):
(JSC::FTL::LowerDFGToLLVM::forwardTypeCheck):
(JSC::FTL::LowerDFGToLLVM::typeCheck):
(JSC::FTL::LowerDFGToLLVM::appendTypeCheck):
(JSC::FTL::LowerDFGToLLVM::lowInt32):
(JSC::FTL::LowerDFGToLLVM::lowCell):
(JSC::FTL::LowerDFGToLLVM::lowBoolean):
(JSC::FTL::LowerDFGToLLVM::speculateObject):
(JSC::FTL::LowerDFGToLLVM::isLive):
(JSC::FTL::LowerDFGToLLVM::use):
(JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
(JSC::FTL::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
(JSC::FTL::LowerDFGToLLVM::tryToSetConstantExitArgument):
(JSC::FTL::LowerDFGToLLVM::addExitArgument):
(JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
(JSC::FTL::LowerDFGToLLVM::observeMovHint):
* ftl/FTLOSRExit.cpp: Added.
(FTL):
(JSC::FTL::OSRExit::OSRExit):
(JSC::FTL::OSRExit::codeLocationForRepatch):
(JSC::FTL::OSRExit::convertToForward):
* ftl/FTLOSRExit.h: Added.
(FTL):
(OSRExit):
* ftl/FTLOSRExitCompilationInfo.h: Added.
(FTL):
(JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
(OSRExitCompilationInfo):
* ftl/FTLOSRExitCompiler.cpp: Added.
(FTL):
(JSC::FTL::compileStub):
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLOSRExitCompiler.h: Added.
(FTL):
* ftl/FTLOutput.h:
(JSC::FTL::Output::newBlock):
(JSC::FTL::Output::intToPtr):
(JSC::FTL::Output::load):
(JSC::FTL::Output::store):
(Output):
(JSC::FTL::Output::call):
(JSC::FTL::Output::convertToTailCall):
(FTL):
* ftl/FTLState.h:
(State):
* ftl/FTLThunks.cpp: Added.
(FTL):
(JSC::FTL::osrExitGenerationThunkGenerator):
* ftl/FTLThunks.h: Added.
(JSC):
(FTL):
* ftl/FTLValueFormat.cpp: Added.
(WTF):
(WTF::printInternal):
* ftl/FTLValueFormat.h: Added.
(FTL):
(WTF):
* ftl/FTLValueSource.cpp: Added.
(FTL):
(JSC::FTL::ValueSource::dump):
* ftl/FTLValueSource.h: Added.
(FTL):
(ValueSource):
(JSC::FTL::ValueSource::ValueSource):
(JSC::FTL::ValueSource::kind):
(JSC::FTL::ValueSource::operator!):
(JSC::FTL::ValueSource::node):
2013-04-12 Filip Pizlo <fpizlo@apple.com>
fourthTier: switch to using MCJIT and disable frame pointer elimination
https://bugs.webkit.org/show_bug.cgi?id=114542
Reviewed by Oliver Hunt and Michael Saboff.
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreadingOnce):
2013-04-09 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should provide utilities for common OSR exit tasks
https://bugs.webkit.org/show_bug.cgi?id=114306
Reviewed by Mark Hahnenberg.
Just abstract out some things that the FTL will want to use as well.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompiler.h:
(OSRExitCompiler):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp: Added.
(DFG):
(JSC::DFG::handleExitCounts):
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitCompilerCommon.h: Added.
(DFG):
2013-04-09 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should better abstract floating point arguments
https://bugs.webkit.org/show_bug.cgi?id=114300
Reviewed by Mark Hahnenberg.
* dfg/DFGFPRInfo.h:
(FPRInfo):
(JSC::DFG::FPRInfo::toArgumentRegister):
2013-04-05 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should better abstract arguments
https://bugs.webkit.org/show_bug.cgi?id=114073
Reviewed by Mark Hahnenberg.
* dfg/DFGGPRInfo.h:
(GPRInfo):
(JSC::DFG::GPRInfo::toArgumentRegister):
2013-04-03 Filip Pizlo <fpizlo@apple.com>
fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data into something accessible from both DFG::JITCode and FTL::JITCode
https://bugs.webkit.org/show_bug.cgi?id=113905
Reviewed by Geoffrey Garen.
This removes one pointer from CodeBlock.
It also gives us a framework for having JITType-specific data in CodeBlock, by
putting it into the appropriate JITCode class (either DFG::JITCode or
FTL::JITCode). And it allows us to have DFG and FTL share some common data,
via DFG::CommonData, which is stored in both DFG::JITCode and FTL::JITCode and
always accessible via JITCode::dfgCommon().
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* bytecode/CodeBlock.cpp:
(JSC):
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::visitAggregate):
(JSC::CodeBlock::performTracingFixpointIteration):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::stronglyVisitWeakReferences):
(JSC::CodeBlock::shrinkToFit):
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
(JSC::DFGCodeBlocks::mark):
* dfg/DFGAssemblyHelpers.h:
* dfg/DFGCommonData.cpp: Added.
(DFG):
(JSC::DFG::CommonData::notifyCompilingStructureTransition):
(JSC::DFG::CommonData::shrinkToFit):
* dfg/DFGCommonData.h: Added.
(JSC):
(DFG):
(JSC::DFG::WeakReferenceTransition::WeakReferenceTransition):
(WeakReferenceTransition):
(CommonData):
(JSC::DFG::CommonData::CommonData):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGDriver.h:
(DFG):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGJITCode.cpp: Added.
(DFG):
(JSC::DFG::JITCode::JITCode):
(JSC::DFG::JITCode::~JITCode):
(JSC::DFG::JITCode::dfgCommon):
(JSC::DFG::JITCode::dfg):
(JSC::DFG::JITCode::shrinkToFit):
* dfg/DFGJITCode.h: Added.
(DFG):
(JITCode):
(JSC::DFG::JITCode::appendOSREntryData):
(JSC::DFG::JITCode::osrEntryDataForBytecodeIndex):
(JSC::DFG::JITCode::appendOSRExit):
(JSC::DFG::JITCode::lastOSRExit):
(JSC::DFG::JITCode::appendSpeculationRecovery):
(JSC::DFG::JITCode::appendWatchpoint):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JITCompiler):
(JSC::DFG::JITCompiler::addWeakReference):
(JSC::DFG::JITCompiler::noticeOSREntry):
(JSC::DFG::JITCompiler::jitCode):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExit.h:
(OSRExit):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::backwardSpeculationCheck):
(JSC::DFG::SpeculativeJIT::speculationWatchpoint):
(JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGVariableEventStream.cpp:
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::JITCode):
(JSC::FTL::JITCode::~JITCode):
(FTL):
(JSC::FTL::JITCode::initializeCode):
(JSC::FTL::JITCode::addressForCall):
(JSC::FTL::JITCode::executableAddressAtOffset):
(JSC::FTL::JITCode::dataAddressAtOffset):
(JSC::FTL::JITCode::offsetOf):
(JSC::FTL::JITCode::size):
(JSC::FTL::JITCode::contains):
(JSC::FTL::JITCode::ftl):
(JSC::FTL::JITCode::dfgCommon):
* ftl/FTLJITCode.h:
(JITCode):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint):
(JSC::FTL::LowerDFGToLLVM::compilePutStructure):
(JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):
(JSC::FTL::LowerDFGToLLVM::addWeakReference):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::weakPointer):
* ftl/FTLState.cpp:
(FTL):
(JSC::FTL::State::State):
(JSC::FTL::State::dumpState):
* ftl/FTLState.h:
(State):
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::~DFGCodeBlocks):
(JSC::DFGCodeBlocks::jettison):
(JSC::DFGCodeBlocks::clearMarks):
(JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
(JSC::DFGCodeBlocks::traceMarkedCodeBlocks):
* jit/JITCode.cpp:
(JSC::JITCode::dfgCommon):
(JSC):
(JSC::JITCode::dfg):
(JSC::JITCode::ftl):
(JSC::DirectJITCode::DirectJITCode):
(JSC::DirectJITCode::initializeCodeRef):
(JSC::DirectJITCode::addressForCall):
(JSC::DirectJITCode::executableAddressAtOffset):
(JSC::DirectJITCode::dataAddressAtOffset):
(JSC::DirectJITCode::offsetOf):
(JSC::DirectJITCode::size):
(JSC::DirectJITCode::contains):
* jit/JITCode.h:
(DFG):
(FTL):
(JSC):
(JITCode):
(DirectJITCode):
2013-04-03 Filip Pizlo <fpizlo@apple.com>
fourthTier: Include LLVM headers with surrounding #pragmas instead of using my #define
https://bugs.webkit.org/show_bug.cgi?id=113921
Reviewed by Oliver Hunt.
The LLVM community wants us to continue including all of LLVM's C++ headers. Change
to using #pragma's to disable warnings that they cannot handle.
* ftl/FTLLLVMHeaders.h:
2013-04-03 Filip Pizlo <fpizlo@apple.com>
fourthTier: Everyone should know about the FTL
https://bugs.webkit.org/show_bug.cgi?id=113897
Reviewed by Mark Hahnenberg.
In order to get OSR exit to work right, we need the distinction between DFG and
FTL to be clear even after compilation finishes, since they will have subtly
different OSR stories and likely use different data structures.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::resetStubInternal):
(JSC::ProgramCodeBlock::compileOptimized):
(JSC::EvalCodeBlock::compileOptimized):
(JSC::FunctionCodeBlock::compileOptimized):
(JSC::CodeBlock::adjustedExitCountThreshold):
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::hasOptimizedReplacement):
(JSC::ExecState::isInlineCallFrame):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::JITCode):
* ftl/FTLState.cpp:
(JSC::FTL::State::dumpState):
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::jettison):
* interpreter/Interpreter.cpp:
(JSC::getLineNumberForCallFrame):
(JSC::getCallerInfo):
* jit/JITCode.cpp:
(WTF::printInternal):
* jit/JITCode.h:
(JSC::JITCode::topTierJIT):
(JSC::JITCode::nextTierJIT):
(JITCode):
(JSC::JITCode::isJIT):
(JSC::JITCode::isLowerTier):
(JSC::JITCode::isHigherTier):
(JSC::JITCode::isLowerOrSameTier):
(JSC::JITCode::isHigherOrSameTier):
(JSC::JITCode::isOptimizingJIT):
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* runtime/Executable.cpp:
(JSC::EvalExecutable::compileOptimized):
(JSC::samplingDescription):
(JSC::ProgramExecutable::compileOptimized):
(JSC::FunctionExecutable::compileOptimizedForCall):
(JSC::FunctionExecutable::compileOptimizedForConstruct):
2013-04-03 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should abstract out how it does forward exits, and that code should be simplified
https://bugs.webkit.org/show_bug.cgi?id=113894
Reviewed by Mark Hahnenberg.
1) We previously had two different ways of convertingToForward, one path for
where we had a ValueRecovery for the current node and one where we didn't.
But the paths were doing exactly the same thing except that if you have a
ValueRecovery, you also find the last applicable mov hint and do some
extra things. This patch combines the two paths and bases both of them on
the previous no-ValueRecovery path, which was simpler to begin with.
2) This moves the logic into DFG::OSRExit, which further simplifies the code
and makes the logic available to the FTL.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::convertToForward):
(DFG):
* dfg/DFGOSRExit.h:
(DFG):
(OSRExit):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
2013-04-02 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should have the equivalent of a ValueRecovery
https://bugs.webkit.org/show_bug.cgi?id=113819
Reviewed by Mark Hahnenberg.
This adds a way of saying that we have a value, we don't want to say what
node the value came from, but we know specifics of how the value is
formatted. This is the LLVM equivalent of DFG's ValueRecovery.
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLFormattedValue.h: Added.
(FTL):
(FormattedValue):
(JSC::FTL::FormattedValue::FormattedValue):
(JSC::FTL::FormattedValue::operator!):
(JSC::FTL::FormattedValue::format):
(JSC::FTL::FormattedValue::value):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
(JSC::FTL::LowerDFGToLLVM::speculateForward):
(JSC::FTL::LowerDFGToLLVM::weakPointer):
2013-04-02 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should use the right abstract heap for Int32 array accesses
https://bugs.webkit.org/show_bug.cgi?id=113759
Reviewed by Mark Hahnenberg.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
2013-04-02 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support fast property stores
https://bugs.webkit.org/show_bug.cgi?id=113757
Reviewed by Oliver Hunt.
Simplified the task of handling property transitions and reduced amount of code
duplication between the JITs.
Added PutByOffset, PutStructure, PhantomPutStructure, WeakJSConstant, and a
stub form of StructureTransitionWatchpoint to the FTL.
Also simplified the creation of pointer constants, and fixed a bug in
speculateObject().
* dfg/DFGGraph.h:
(JSC::DFG::Graph::notifyCompilingStructureTransition):
(Graph):
* dfg/DFGJITCompiler.h:
(JITCompiler):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileWeakJSConstant):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint):
(JSC::FTL::LowerDFGToLLVM::compilePutStructure):
(JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):
(JSC::FTL::LowerDFGToLLVM::compilePutByOffset):
(JSC::FTL::LowerDFGToLLVM::speculateObject):
(JSC::FTL::LowerDFGToLLVM::weakPointer):
* ftl/FTLOutput.h:
(Output):
(JSC::FTL::Output::constIntPtr):
(JSC::FTL::Output::absolute):
2013-04-01 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support some more integer arithmetic ops (negate, xor, urshift)
https://bugs.webkit.org/show_bug.cgi?id=113740
Reviewed by Geoffrey Garen.
* ftl/FTLAbbreviations.h:
(JSC::FTL::buildNeg):
(JSC::FTL::buildLShr):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileArithNegate):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileBitXor):
(JSC::FTL::LowerDFGToLLVM::compileBitURShift):
(JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
* ftl/FTLOutput.h:
(JSC::FTL::Output::neg):
(JSC::FTL::Output::lShr):
2013-04-01 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support GetGlobalVar/PutGlobalVar
https://bugs.webkit.org/show_bug.cgi?id=113728
Reviewed by Gavin Barraclough.
Removed the macro magic for the globals absolute abstract heap, since for anything
with absolute addresses we can just share a common absolute abstract heap. It
would only be a problem if we for example were emitting an access to a global but
not using an absolute address, and then wanted to say that this access was
constrained to global variables. I don't believe we do that, and I don't believe we
ever will.
Then added Output::absolute(), a convenient way of building a typed pointer for an
absolute address.
Then added GetGlobalVar/PutGlobalVar.
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
(FTL):
(AbstractHeapRepository):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
* ftl/FTLOutput.h:
(JSC::FTL::Output::absolute):
(Output):
2013-03-31 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL should support ArithSub
https://bugs.webkit.org/show_bug.cgi?id=113675
Reviewed by Oliver Hunt.
This does the obvious bit of implementing ArithSub, but it also takes this
as an opportunity to clean up how intrinsics and common values (common types
and constants) are handled. Previously they were all lumped together in
FTL::Output. Now, in an effort to split up the files and make FTL::Output
less big, I created a thing called FTL::CommonValues which just tracks the
common values, and a thing called FTL::IntrinsicRepository which just tracks
intrinsics. These and FTL::Output are all related to each other in a linear
hierarchy. Moreover, IntrinsicRepository uses macro-fu to make it easy to
declare new intrinsics in the future.
I also out-of-lined some things and made .cpp files for each of these classes.
Initialize I wasn't going to do this but then I realized that FTL::Output is
already included in multiple places. Probably it's better if some of its guts
are not inline, and it's also good to now have .cpp "landing pads" if we ever
want to add more things to that class.
Note that a lot of how these things are designed has to do with the fact
that pretty soon here I'll have to switch us from using the LLVM global
context to using a context that we create. When that happens, anyone who
creates anything will have to know the context; that's why FTL::CommonValues
already knows the module but doesn't use it - in the future it will have to
do things with it.
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLAbbreviations.h:
(JSC::FTL::buildSub):
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCommonValues.cpp: Added.
(FTL):
(JSC::FTL::CommonValues::CommonValues):
* ftl/FTLCommonValues.h: Added.
(FTL):
(CommonValues):
(JSC::FTL::CommonValues::initialize):
* ftl/FTLIntrinsicRepository.cpp: Added.
(FTL):
(JSC::FTL::IntrinsicRepository::IntrinsicRepository):
* ftl/FTLIntrinsicRepository.h: Added.
(FTL):
(IntrinsicRepository):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileArithSub):
(LowerDFGToLLVM):
* ftl/FTLOutput.cpp: Added.
(FTL):
(JSC::FTL::Output::Output):
(JSC::FTL::Output::~Output):
* ftl/FTLOutput.h:
(Output):
(JSC::FTL::Output::initialize):
(JSC::FTL::Output::sub):
(JSC::FTL::Output::addWithOverflow32):
(JSC::FTL::Output::subWithOverflow32):
(JSC::FTL::Output::mulWithOverflow32):
2013-03-31 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL doesn't need virtual register allocation
https://bugs.webkit.org/show_bug.cgi?id=113679
Reviewed by Mark Hahnenberg.
* dfg/DFGDriver.cpp:
(JSC::DFG::dumpAndVerifyGraph):
(DFG):
(JSC::DFG::compile):
2013-03-31 Filip Pizlo <fpizlo@apple.com>
https://bugs.webkit.org/show_bug.cgi?id=113656
Fix Sam's nits.
Unreviewed.
* ftl/FTLAbstractHeap.cpp:
(JSC::FTL::IndexedAbstractHeap::initialize):
* ftl/FTLAbstractHeap.h:
(IndexedAbstractHeap):
(AbsoluteAbstractHeap):
* ftl/FTLAbstractHeapRepository.h:
(AbstractHeapRepository):
2013-03-31 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL JIT should support GetByVal on Int32 arrays
https://bugs.webkit.org/show_bug.cgi?id=113668
Reviewed by Sam Weinig.
It actually already supported this, but needed to be told that it did.
Also adds an option to enable LICM (loop-invariant code motion, i.e.
http://llvm.org/docs/Passes.html#licm-loop-invariant-code-motion). LICM
isn't doing me any good right now, but I guess I'll have to play with
it more. And this adds the ability to tweak the LLVM optimization level
from the command-line.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
* runtime/Options.h:
(JSC):
2013-03-31 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL JIT should supply TBAA meta-data to LLVM
https://bugs.webkit.org/show_bug.cgi?id=113656
Reviewed by Oliver Hunt.
This adds support for performing strong typing on the LLVM IR that the FTL
generates, by using TBAA meta-data. This will permit LLVM to do aggressive
GVN, load elimination, and LICM optimization even if it sees pointer store
side-effects. The goal is to precisely model all loads and stores we emit,
except for the super crazy ones (GetById that can go all-out polymorphic,
or for example a Call where we know nothing).
This is accomplished by introducing the notion of an AbstractHeap
typesystem. An AbstractHeap is a subset of all possible memory locations
that we might store to. For example, JSCell::m_structure and
JSObject::m_butterfly are two disjoint AbstractHeaps because we know that
a store to one cannot clobber the other. AbstractHeaps follow a
single-inheritance hierarchy. There is the root heap, which corresponds to
any possible memory location accessible to the JS engine, and then there
are heaps for all internal object fields, a heap for each global object,
and so on.
There are three other tidbits here that make this somewhat more interesting.
We have a notion of an AbstractHeap-with-offset, called AbstractField.
JSCell::m_structure is actually an AbstractField. This allows us to say
things like m_out.loadPtr(base, m_heaps.JSCell_structure); this both
gives you the offset of JSCell::m_structure and ascribes TBAA meta-data for
the JSCell::m_structure heap to the generated load instrction.
Another fun tidbit is the notion of Indexed, Numbered, and Absolute abstract
heaps. An indexed abstract heap corresponds to a set of locations that you
might access by index from some base. Virtual registers are a great example.
Though I call them just "variables" in the FTL. When we access a virtual
register, we know that we aren't interfering with accesses to
Structure-managed named properties, or with JSCell::m_structure, or with
other such disjoint heaps. But we also know that if we access a variable at
offset X and then another variable at offset Y and we know that X and Y are
unequal, then these two accesses are on disjoint subheaps of the variables
heap. This works out naturally for interference between, say, scoped variable
access and local variable access: if you access scoped variable r5 and then
access a local variable r5, these might interfere - and they will get the
same abstract subheap of the variables heap. IndexedAbstractHeaps
conveniently remember the size of the elements and will give you an
AbstractField (i.e. heap-with-offset) if you give it an index. This is great
for conveniently writing code that accesses contiguous arrays of well-typed
things. This allows you to literally do things like
m_out.load64(callFrameRegister, m_heaps.variables[operand]) and the right
thing will happen. You can also get the heap variables.atAnyIndex(), if
you're doing an access with an unknown index.
Numbered and Absolute abstract heaps are related except that they don't
assume that the value used to get the abstract subheap corresponds to any
meaningful offset from any base. Numbered heaps, like the properties heap
(for named properties tracked by Structure), are "numbered" (not indexed)
by the propertyNumber. So you can emit a GetByOffset by separately
computing the offset and the propertyNumber (both values are stored in the
StorageAccessData), and passing the offset directly to Output::address()
and passing m_heaps.properties[propertyNumber] as the field. Absolute heaps
are similar, but are keyed on absolute address. This is appropriate for
global variables, and possibly other things.
Finally, FTL::Output understands the notion of a pointer-with-TBAA-data,
and calls it a TypedPointer. TypedPointer is a tuple of a LLVMValueRef
referencing an intptr value and a pointer to an AbstractHeap. All load()
and store() operations now take a TypedPointer, and will perform the access
by casting the intptr to a pointer of the right type and then ascribing the
TBAA meta-data from the AbstractHeap.
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLAbbreviations.h:
(JSC::FTL::mdKindID):
(JSC::FTL::mdString):
(JSC::FTL::mdNode):
(FTL):
(JSC::FTL::setMetadata):
* ftl/FTLAbstractHeap.cpp: Added.
(FTL):
(JSC::FTL::AbstractHeap::tbaaMetadataSlow):
(JSC::FTL::AbstractHeap::decorateInstruction):
(JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
(JSC::FTL::IndexedAbstractHeap::~IndexedAbstractHeap):
(JSC::FTL::IndexedAbstractHeap::baseIndex):
(JSC::FTL::IndexedAbstractHeap::atSlow):
(JSC::FTL::IndexedAbstractHeap::initialize):
(JSC::FTL::NumberedAbstractHeap::NumberedAbstractHeap):
(JSC::FTL::NumberedAbstractHeap::~NumberedAbstractHeap):
(JSC::FTL::AbsoluteAbstractHeap::AbsoluteAbstractHeap):
(JSC::FTL::AbsoluteAbstractHeap::~AbsoluteAbstractHeap):
* ftl/FTLAbstractHeap.h: Added.
(FTL):
(AbstractHeap):
(JSC::FTL::AbstractHeap::AbstractHeap):
(JSC::FTL::AbstractHeap::isInitialized):
(JSC::FTL::AbstractHeap::initialize):
(JSC::FTL::AbstractHeap::parent):
(JSC::FTL::AbstractHeap::heapName):
(JSC::FTL::AbstractHeap::tbaaMetadata):
(AbstractField):
(JSC::FTL::AbstractField::AbstractField):
(JSC::FTL::AbstractField::initialize):
(JSC::FTL::AbstractField::offset):
(IndexedAbstractHeap):
(JSC::FTL::IndexedAbstractHeap::atAnyIndex):
(JSC::FTL::IndexedAbstractHeap::at):
(JSC::FTL::IndexedAbstractHeap::operator[]):
(JSC::FTL::IndexedAbstractHeap::returnInitialized):
(JSC::FTL::IndexedAbstractHeap::MyHashTraits::constructDeletedValue):
(JSC::FTL::IndexedAbstractHeap::MyHashTraits::isDeletedValue):
(NumberedAbstractHeap):
(JSC::FTL::NumberedAbstractHeap::atAnyNumber):
(JSC::FTL::NumberedAbstractHeap::at):
(JSC::FTL::NumberedAbstractHeap::operator[]):
(AbsoluteAbstractHeap):
(JSC::FTL::AbsoluteAbstractHeap::atAnyAddress):
(JSC::FTL::AbsoluteAbstractHeap::at):
(JSC::FTL::AbsoluteAbstractHeap::operator[]):
* ftl/FTLAbstractHeapRepository.cpp: Added.
(FTL):
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
(JSC::FTL::AbstractHeapRepository::~AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h: Added.
(FTL):
(AbstractHeapRepository):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
(JSC::FTL::LowerDFGToLLVM::compileGetButterfly):
(JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
(JSC::FTL::LowerDFGToLLVM::speculateObject):
(JSC::FTL::LowerDFGToLLVM::addressFor):
(JSC::FTL::LowerDFGToLLVM::payloadFor):
(JSC::FTL::LowerDFGToLLVM::tagFor):
(LowerDFGToLLVM):
* ftl/FTLOutput.h:
(FTL):
(JSC::FTL::Output::Output):
(JSC::FTL::Output::initialize):
(JSC::FTL::Output::set):
(JSC::FTL::Output::load):
(JSC::FTL::Output::store):
(Output):
(JSC::FTL::Output::load32):
(JSC::FTL::Output::load64):
(JSC::FTL::Output::loadPtr):
(JSC::FTL::Output::store32):
(JSC::FTL::Output::store64):
(JSC::FTL::Output::storePtr):
(JSC::FTL::Output::addPtr):
(JSC::FTL::Output::address):
(JSC::FTL::Output::baseIndex):
* ftl/FTLTypedPointer.h: Added.
(FTL):
(TypedPointer):
(JSC::FTL::TypedPointer::TypedPointer):
(JSC::FTL::TypedPointer::operator!):
(JSC::FTL::TypedPointer::heap):
(JSC::FTL::TypedPointer::value):
* runtime/Options.h:
(JSC):
2013-03-30 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL JIT should be able to compile the Array.prototype.findGraphNode function in Kraken/ai-astar
https://bugs.webkit.org/show_bug.cgi?id=113646
Reviewed by Oliver Hunt.
This adds enough FTL support to compile Array.prototype.findGraphNode. This isn't
a speed-up, yet, because findGraphNode tends to be aggressively inlined by the DFG,
and the FTL can't yet compile the things into which it was inlined. In future
patches we will get to a point where we can compile the callers, and then we'll be
able to see what the performance effects are.
But the interesting thing is that it isn't a slow-down, either. This implies that
even if we FTL compile a CodeBlock that we shouldn't have (the fact that we
compiling things that end up being inlined is dumb, and the fact that the current
FTL tiering strategy launches LLVM for those things is even dumber), we still run
at OK performance.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileGetButterfly):
(JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
(JSC::FTL::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::LowerDFGToLLVM::lowInt32):
(JSC::FTL::LowerDFGToLLVM::lowCell):
(JSC::FTL::LowerDFGToLLVM::lowObject):
(JSC::FTL::LowerDFGToLLVM::lowBoolean):
(JSC::FTL::LowerDFGToLLVM::lowJSValue):
(JSC::FTL::LowerDFGToLLVM::lowStorage):
(JSC::FTL::LowerDFGToLLVM::isNotInt32):
(JSC::FTL::LowerDFGToLLVM::isNotCell):
(JSC::FTL::LowerDFGToLLVM::isNotBoolean):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::speculateCell):
(JSC::FTL::LowerDFGToLLVM::speculateObject):
(JSC::FTL::LowerDFGToLLVM::accountedPointer):
(JSC::FTL::LowerDFGToLLVM::weakPointer):
* ftl/FTLOutput.h:
(JSC::FTL::Output::Output):
(JSC::FTL::Output::insertNewBlocksBefore):
(JSC::FTL::Output::appendTo):
(Output):
(JSC::FTL::Output::baseIndex):
2013-03-29 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL JIT should be able to compile the Marsaglia random number generator
https://bugs.webkit.org/show_bug.cgi?id=113635
Reviewed by Oliver Hunt.
Just adding missing functionality.
Also "fixed" OSR exit to use a call to abort() in addition to using Unreachable
since the latter doesn't actually mean trap - quite the opposite, it tells LLVM
that the code can never be reached.
The Marsaglia function runs ~60% faster with FTL, than DFG. Not a terrible start.
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLAbbreviations.h:
(FTL):
(JSC::FTL::voidType):
(JSC::FTL::structType):
(JSC::FTL::functionType):
(JSC::FTL::addFunction):
(JSC::FTL::setLinkage):
(JSC::FTL::setFunctionCallingConv):
(JSC::FTL::addExternFunction):
(JSC::FTL::constIntToPtr):
(JSC::FTL::constBitCast):
(JSC::FTL::buildMul):
(JSC::FTL::buildOr):
(JSC::FTL::buildShl):
(JSC::FTL::buildAShr):
(JSC::FTL::buildCall):
(JSC::FTL::buildExtractValue):
(JSC::FTL::dumpModule):
(JSC::FTL::verifyModule):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileBlock):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileAdd):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::LowerDFGToLLVM::compileBitAnd):
(JSC::FTL::LowerDFGToLLVM::compileBitOr):
(JSC::FTL::LowerDFGToLLVM::compileBitRShift):
(JSC::FTL::LowerDFGToLLVM::compileBitLShift):
(JSC::FTL::LowerDFGToLLVM::compileCompareLess):
(JSC::FTL::LowerDFGToLLVM::compileBranch):
(JSC::FTL::LowerDFGToLLVM::speculateBackward):
(JSC::FTL::LowerDFGToLLVM::lowBoolean):
* ftl/FTLOutput.h:
(JSC::FTL::Output::Output):
(JSC::FTL::Output::initialize):
(JSC::FTL::Output::appendTo):
(Output):
(JSC::FTL::Output::mul):
(JSC::FTL::Output::bitOr):
(JSC::FTL::Output::shl):
(JSC::FTL::Output::aShr):
(JSC::FTL::Output::addWithOverflow32):
(JSC::FTL::Output::mulWithOverflow32):
(JSC::FTL::Output::extractValue):
(JSC::FTL::Output::call):
(JSC::FTL::Output::addWithOverflow32Function):
(JSC::FTL::Output::mulWithOverflow32Function):
* ftl/FTLState.cpp: Added.
(FTL):
(JSC::FTL::State::dumpState):
* ftl/FTLState.h:
(State):
2013-03-29 Filip Pizlo <fpizlo@apple.com>
Unreviewed, release mode build fix.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lowInt32):
(JSC::FTL::LowerDFGToLLVM::lowCell):
(JSC::FTL::LowerDFGToLLVM::lowBoolean):
(JSC::FTL::LowerDFGToLLVM::lowJSValue):
2013-03-29 Filip Pizlo <fpizlo@apple.com>
fourthTier: Change DO_NOT_INCLUDE_LLVM_CPP_HEADERS to LLVM_DO_NOT_INCLUDE_CPP_HEADERS
https://bugs.webkit.org/show_bug.cgi?id=113634
Reviewed by Dan Bernstein.
* ftl/FTLLLVMHeaders.h:
2013-03-29 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL JIT should be able run some simple function
https://bugs.webkit.org/show_bug.cgi?id=113481
Reviewed by Geoffrey Garen.
I forgot to make a couple of the requested review changes, so I'm making
them now!
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLJITCode.h:
2013-03-29 Filip Pizlo <fpizlo@apple.com>
fourthTier: FTL JIT should be able run some simple function
https://bugs.webkit.org/show_bug.cgi?id=113481
Reviewed by Geoffrey Garen.
This is the initial version of the FTL JIT (Fourth Tier LLVM JIT).
It includes a lowering from the DFG IR to LLVM IR (FTL::lowerDFGToLLVM)
and a "backend" step that invokes the LLVM and wraps the resulting
function in a thunk (FTL::compile).
All LLVM IR building functions are wrapped up into a nicer FTL API.
First they're wrapped in an abbreviated API (FTLAbbreviations.h) and
then again into an object-oriented IR builder (FTLOutput.h).
This runs things. I don't know how fast it runs things. And I don't
make any claims of stability. The FTL is runtime-disabled by default;
you will enable it by doing --useExperimentalFTL=true. Probably if you
do this, you will run slower, because of the heavy thunking we do, the
fact that we don't have anything resembling a sensible tiering story,
and because we only compile ridiculously tiny functions.
Finally, this still requires a custom set of LLVM headers to build.
I am working on getting that up-streamed to LLVM, and separately I'll
make sure that we have a build checked into this branch.
* Configurations/JavaScriptCore.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/Operands.h:
(Operands):
(JSC::Operands::Operands):
* dfg/DFGAbstractState.h:
(JSC::DFG::AbstractState::needsTypeCheck):
(AbstractState):
(JSC::DFG::AbstractState::filterEdgeByUse):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::needsTypeCheck):
(JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand):
(JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
(DFG):
* dfg/DFGUseKind.h:
(JSC::DFG::shouldNotHaveTypeCheck):
(DFG):
(JSC::DFG::mayHaveTypeCheck):
(JSC::DFG::isDouble):
(JSC::DFG::isCell):
* ftl: Added.
* ftl/FTLAbbreviations.h: Added.
(FTL):
(JSC::FTL::int1Type):
(JSC::FTL::int32Type):
(JSC::FTL::int64Type):
(JSC::FTL::intPtrType):
(JSC::FTL::pointerType):
(JSC::FTL::getParam):
(JSC::FTL::constInt):
(JSC::FTL::appendBasicBlock):
(JSC::FTL::insertBasicBlock):
(JSC::FTL::buildAlloca):
(JSC::FTL::buildAdd):
(JSC::FTL::buildAnd):
(JSC::FTL::buildXor):
(JSC::FTL::buildLoad):
(JSC::FTL::buildStore):
(JSC::FTL::buildZExt):
(JSC::FTL::buildIntCast):
(JSC::FTL::buildIntToPtr):
(JSC::FTL::buildPtrToInt):
(JSC::FTL::buildICmp):
(JSC::FTL::buildSelect):
(JSC::FTL::buildBr):
(JSC::FTL::buildCondBr):
(JSC::FTL::buildRet):
(JSC::FTL::buildUnreachable):
* ftl/FTLCapabilities.cpp: Added.
(FTL):
(JSC::FTL::canCompile):
* ftl/FTLCapabilities.h: Added.
(FTL):
* ftl/FTLCompile.cpp: Added.
(FTL):
(JSC::FTL::compileEntry):
(JSC::FTL::compile):
* ftl/FTLCompile.h: Added.
(FTL):
* ftl/FTLJITCode.cpp: Added.
(FTL):
(JSC::FTL::JITCode::JITCode):
(JSC::FTL::JITCode::~JITCode):
(JSC::FTL::JITCode::addressForCall):
(JSC::FTL::JITCode::executableAddressAtOffset):
(JSC::FTL::JITCode::dataAddressAtOffset):
(JSC::FTL::JITCode::offsetOf):
(JSC::FTL::JITCode::size):
(JSC::FTL::JITCode::contains):
* ftl/FTLJITCode.h: Added.
(FTL):
(JITCode):
* ftl/FTLLLVMHeaders.h: Added.
* ftl/FTLLowerDFGToLLVM.cpp: Added.
(FTL):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::addFlushedLocalOpRoots):
(JSC::FTL::LowerDFGToLLVM::closeOverFlushedLocalOps):
(JSC::FTL::LowerDFGToLLVM::addFlushedLocalOp):
(JSC::FTL::LowerDFGToLLVM::addFlushedLocalEdge):
(JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
(JSC::FTL::LowerDFGToLLVM::compileBlock):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileJSConstant):
(JSC::FTL::LowerDFGToLLVM::compileGetLocal):
(JSC::FTL::LowerDFGToLLVM::compileSetLocal):
(JSC::FTL::LowerDFGToLLVM::compileMovHintAndCheck):
(JSC::FTL::LowerDFGToLLVM::compilePhantom):
(JSC::FTL::LowerDFGToLLVM::compileReturn):
(JSC::FTL::LowerDFGToLLVM::speculateBackward):
(JSC::FTL::LowerDFGToLLVM::speculateForward):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::terminate):
(JSC::FTL::LowerDFGToLLVM::backwardTypeCheck):
(JSC::FTL::LowerDFGToLLVM::forwardTypeCheck):
(JSC::FTL::LowerDFGToLLVM::typeCheck):
(JSC::FTL::LowerDFGToLLVM::lowInt32):
(JSC::FTL::LowerDFGToLLVM::lowCell):
(JSC::FTL::LowerDFGToLLVM::lowBoolean):
(JSC::FTL::LowerDFGToLLVM::lowJSValue):
(JSC::FTL::LowerDFGToLLVM::checkNotInt32):
(JSC::FTL::LowerDFGToLLVM::unboxInt32):
(JSC::FTL::LowerDFGToLLVM::boxInt32):
(JSC::FTL::LowerDFGToLLVM::checkNotCell):
(JSC::FTL::LowerDFGToLLVM::checkNotBoolean):
(JSC::FTL::LowerDFGToLLVM::unboxBoolean):
(JSC::FTL::LowerDFGToLLVM::boxBoolean):
(JSC::FTL::LowerDFGToLLVM::speculateInt32):
(JSC::FTL::LowerDFGToLLVM::addressFor):
(JSC::FTL::LowerDFGToLLVM::payloadFor):
(JSC::FTL::LowerDFGToLLVM::tagFor):
(JSC::FTL::LowerDFGToLLVM::globalData):
(JSC::FTL::LowerDFGToLLVM::codeBlock):
(JSC::FTL::lowerDFGToLLVM):
* ftl/FTLLowerDFGToLLVM.h: Added.
(FTL):
* ftl/FTLOutput.h: Added.
(FTL):
(Output):
(JSC::FTL::Output::Output):
(JSC::FTL::Output::~Output):
(JSC::FTL::Output::initialize):
(JSC::FTL::Output::appendTo):
(JSC::FTL::Output::newBlock):
(JSC::FTL::Output::param):
(JSC::FTL::Output::constBool):
(JSC::FTL::Output::constInt32):
(JSC::FTL::Output::constIntPtr):
(JSC::FTL::Output::constInt64):
(JSC::FTL::Output::add):
(JSC::FTL::Output::bitAnd):
(JSC::FTL::Output::bitXor):
(JSC::FTL::Output::zeroExt):
(JSC::FTL::Output::intCast):
(JSC::FTL::Output::castToInt32):
(JSC::FTL::Output::get):
(JSC::FTL::Output::set):
(JSC::FTL::Output::load):
(JSC::FTL::Output::store):
(JSC::FTL::Output::load32):
(JSC::FTL::Output::load64):
(JSC::FTL::Output::loadPtr):
(JSC::FTL::Output::store32):
(JSC::FTL::Output::store64):
(JSC::FTL::Output::storePtr):
(JSC::FTL::Output::equal):
(JSC::FTL::Output::notEqual):
(JSC::FTL::Output::above):
(JSC::FTL::Output::aboveOrEqual):
(JSC::FTL::Output::below):
(JSC::FTL::Output::belowOrEqual):
(JSC::FTL::Output::greaterThan):
(JSC::FTL::Output::greaterThanOrEqual):
(JSC::FTL::Output::lessThan):
(JSC::FTL::Output::lessThanOrEqual):
(JSC::FTL::Output::isZero64):
(JSC::FTL::Output::notZero64):
(JSC::FTL::Output::testNonZero64):
(JSC::FTL::Output::select):
(JSC::FTL::Output::jump):
(JSC::FTL::Output::branch):
(JSC::FTL::Output::ret):
(JSC::FTL::Output::unreachable):
* ftl/FTLState.h: Added.
(FTL):
(State):
(JSC::FTL::State::State):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreadingOnce):
* runtime/Options.h:
(JSC):
2013-03-27 Filip Pizlo <fpizlo@apple.com>
fourthTier: JITCode should abstract exactly how the JIT code is structured and where it was allocated
https://bugs.webkit.org/show_bug.cgi?id=113437
Reviewed by Mark Hahnenberg.
JITCode is now a virtual base class, which will allow different JITs to have radically
different memory allocation and management conventions in the future. It will also
make it easier to store JIT-specific meta-data in CodeBlock just by putting it into
an appropriate JITCode subclass.
For now there is one subclass, DirectJITCode, which just behaves like JITCode used to
behave.
* assembler/RepatchBuffer.h:
(JSC::RepatchBuffer::RepatchBuffer):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::resetStubInternal):
(JSC::CodeBlock::bytecodeOffset):
(JSC::CodeBlock::codeOriginForReturn):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::getJITCode):
(JSC::CodeBlock::getJITType):
(CodeBlock):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGDriver.h:
(DFG):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JITCompiler):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::codeLocationForRepatch):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOperations.cpp:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
(JSC::JIT::compile):
(JIT):
* jit/JITCode.cpp:
(JSC):
(JSC::JITCode::JITCode):
(JSC::JITCode::~JITCode):
(JSC::JITCode::execute):
(JSC::JITCode::hostFunction):
(JSC::DirectJITCode::DirectJITCode):
(JSC::DirectJITCode::~DirectJITCode):
(JSC::DirectJITCode::addressForCall):
(JSC::DirectJITCode::executableAddressAtOffset):
(JSC::DirectJITCode::dataAddressAtOffset):
(JSC::DirectJITCode::offsetOf):
(JSC::DirectJITCode::size):
(JSC::DirectJITCode::contains):
* jit/JITCode.h:
(JSC):
(JITCode):
(JSC::JITCode::bottomTierJIT):
(JSC::JITCode::topTierJIT):
(JSC::JITCode::nextTierJIT):
(JSC::JITCode::isOptimizingJIT):
(JSC::JITCode::isBaselineCode):
(JSC::JITCode::jitType):
(JSC::JITCode::jitTypeFor):
(JSC::JITCode::executableAddress):
(JSC::JITCode::start):
(JSC::JITCode::end):
(DirectJITCode):
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* jit/JITStubs.cpp:
(JSC::lazyLinkFor):
(JSC::DEFINE_STUB_FUNCTION):
* jit/ThunkGenerators.cpp:
(JSC::virtualForGenerator):
* llint/LLIntEntrypoints.cpp:
(JSC::LLInt::getFunctionEntrypoint):
(JSC::LLInt::getEvalEntrypoint):
(JSC::LLInt::getProgramEntrypoint):
* llint/LLIntEntrypoints.h:
(JSC):
(LLInt):
(JSC::LLInt::getEntrypoint):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
(JSC::LLInt::entryOSR):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Executable.cpp:
(JSC::EvalExecutable::compileInternal):
(JSC::ProgramExecutable::compileInternal):
(JSC::FunctionExecutable::compileForCallInternal):
(JSC::FunctionExecutable::compileForConstructInternal):
* runtime/Executable.h:
(JSC::ExecutableBase::generatedJITCodeForCall):
(JSC::ExecutableBase::generatedJITCodeForConstruct):
(JSC::ExecutableBase::generatedJITCodeFor):
(ExecutableBase):
(JSC::ExecutableBase::hostCodeEntryFor):
(JSC::ExecutableBase::jsCodeEntryFor):
(JSC::ExecutableBase::jsCodeWithArityCheckEntryFor):
(JSC::NativeExecutable::create):
(JSC::NativeExecutable::finishCreation):
(JSC::EvalExecutable::generatedJITCode):
(JSC::ProgramExecutable::generatedJITCode):
* runtime/ExecutionHarness.h:
(JSC::prepareForExecution):
(JSC::prepareFunctionForExecution):
2013-07-16 Oliver Hunt <oliver@apple.com>
Merged dfgFourthTier r148570
2013-04-16 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should be able to query Structure without modifying it
https://bugs.webkit.org/show_bug.cgi?id=114708
Reviewed by Oliver Hunt.
This is work towards allowing the DFG, and FTL, to run on a separate thread.
The idea is that the most evil thing that the DFG does that has thread-safety
issues is fiddling with Structures by calling Structure::get(). This can lead
to rematerialization of property tables, which is definitely not thread-safe
due to how StringImpl works. So, this patch completely side-steps the problem
by creating a new version of Structure::get, called
Structure::getWithoutMaterializing, which may choose to do an O(n) search if
necessary to avoid materialization. I believe this should be fine - the DFG
does't call into these code path often enough for this to matter, and most of
the time, the Structure that we call this on will already have a property
table because some inline cache would have already called ::get() on that
Structure.
Also cleaned up the materialization logic: we can stop the search as soon as
we find any Structure with a property table rather than searching all the way
for a pinned one.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
* runtime/Structure.cpp:
(JSC::Structure::findStructuresAndMapForMaterialization):
(JSC::Structure::materializePropertyMap):
(JSC::Structure::getWithoutMaterializing):
(JSC):
* runtime/Structure.h:
(Structure):
* runtime/StructureInlines.h:
(JSC::Structure::getWithoutMaterializing):
(JSC):
2013-07-15 Oliver Hunt <oliver@apple.com>
Merged dfgFourthTier r148047
2013-04-09 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should provide utilities for common OSR exit tasks
https://bugs.webkit.org/show_bug.cgi?id=114306
Reviewed by Mark Hahnenberg.
Just abstract out some things that the FTL will want to use as well.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompiler.h:
(OSRExitCompiler):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp: Added.
(DFG):
(JSC::DFG::handleExitCounts):
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitCompilerCommon.h: Added.
(DFG):
2013-07-15 Oliver Hunt <oliver@apple.com>
Merged dfgFourthTier r148037
2013-04-09 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should better abstract floating point arguments
https://bugs.webkit.org/show_bug.cgi?id=114300
Reviewed by Mark Hahnenberg.
* dfg/DFGFPRInfo.h:
(FPRInfo):
(JSC::DFG::FPRInfo::toArgumentRegister):
2013-07-15 Oliver Hunt <oliver@apple.com>
Merged dfgFourthTier r147821
2013-04-05 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should better abstract arguments
https://bugs.webkit.org/show_bug.cgi?id=114073
Reviewed by Mark Hahnenberg.
* dfg/DFGGPRInfo.h:
(GPRInfo):
(JSC::DFG::GPRInfo::toArgumentRegister):
2013-07-15 Oliver Hunt <oliver@apple.com>
Merged dfgFourthTier r147609
2013-04-03 Filip Pizlo <fpizlo@apple.com>
fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data into something accessible from both DFG::JITCode and FTL::JITCode
https://bugs.webkit.org/show_bug.cgi?id=113905
Reviewed by Geoffrey Garen.
This removes one pointer from CodeBlock.
It also gives us a framework for having JITType-specific data in CodeBlock, by
putting it into the appropriate JITCode class (either DFG::JITCode or
FTL::JITCode). And it allows us to have DFG and FTL share some common data,
via DFG::CommonData, which is stored in both DFG::JITCode and FTL::JITCode and
always accessible via JITCode::dfgCommon().
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* bytecode/CodeBlock.cpp:
(JSC):
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::visitAggregate):
(JSC::CodeBlock::performTracingFixpointIteration):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::stronglyVisitWeakReferences):
(JSC::CodeBlock::shrinkToFit):
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
(JSC::DFGCodeBlocks::mark):
* dfg/DFGAssemblyHelpers.h:
* dfg/DFGCommonData.cpp: Added.
(DFG):
(JSC::DFG::CommonData::notifyCompilingStructureTransition):
(JSC::DFG::CommonData::shrinkToFit):
* dfg/DFGCommonData.h: Added.
(JSC):
(DFG):
(JSC::DFG::WeakReferenceTransition::WeakReferenceTransition):
(WeakReferenceTransition):
(CommonData):
(JSC::DFG::CommonData::CommonData):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGDriver.h:
(DFG):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGJITCode.cpp: Added.
(DFG):
(JSC::DFG::JITCode::JITCode):
(JSC::DFG::JITCode::~JITCode):
(JSC::DFG::JITCode::dfgCommon):
(JSC::DFG::JITCode::dfg):
(JSC::DFG::JITCode::shrinkToFit):
* dfg/DFGJITCode.h: Added.
(DFG):
(JITCode):
(JSC::DFG::JITCode::appendOSREntryData):
(JSC::DFG::JITCode::osrEntryDataForBytecodeIndex):
(JSC::DFG::JITCode::appendOSRExit):
(JSC::DFG::JITCode::lastOSRExit):
(JSC::DFG::JITCode::appendSpeculationRecovery):
(JSC::DFG::JITCode::appendWatchpoint):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JITCompiler):
(JSC::DFG::JITCompiler::addWeakReference):
(JSC::DFG::JITCompiler::noticeOSREntry):
(JSC::DFG::JITCompiler::jitCode):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExit.h:
(OSRExit):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::backwardSpeculationCheck):
(JSC::DFG::SpeculativeJIT::speculationWatchpoint):
(JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGVariableEventStream.cpp:
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::~DFGCodeBlocks):
(JSC::DFGCodeBlocks::jettison):
(JSC::DFGCodeBlocks::clearMarks):
(JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
(JSC::DFGCodeBlocks::traceMarkedCodeBlocks):
* jit/JITCode.cpp:
(JSC::JITCode::dfgCommon):
(JSC):
(JSC::JITCode::dfg):
(JSC::JITCode::ftl):
(JSC::DirectJITCode::DirectJITCode):
(JSC::DirectJITCode::initializeCodeRef):
(JSC::DirectJITCode::addressForCall):
(JSC::DirectJITCode::executableAddressAtOffset):
(JSC::DirectJITCode::dataAddressAtOffset):
(JSC::DirectJITCode::offsetOf):
(JSC::DirectJITCode::size):
(JSC::DirectJITCode::contains):
* jit/JITCode.h:
(DFG):
(FTL):
(JSC):
(JITCode):
(DirectJITCode):
2013-07-15 Oliver Hunt <oliver@apple.com>
Merge dfgFourthTier r147587
2013-04-03 Filip Pizlo <fpizlo@apple.com>
fourthTier: Everyone should know about the FTL
https://bugs.webkit.org/show_bug.cgi?id=113897
Reviewed by Mark Hahnenberg.
In order to get OSR exit to work right, we need the distinction between DFG and
FTL to be clear even after compilation finishes, since they will have subtly
different OSR stories and likely use different data structures.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::resetStubInternal):
(JSC::ProgramCodeBlock::compileOptimized):
(JSC::EvalCodeBlock::compileOptimized):
(JSC::FunctionCodeBlock::compileOptimized):
(JSC::CodeBlock::adjustedExitCountThreshold):
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::hasOptimizedReplacement):
(JSC::ExecState::isInlineCallFrame):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::JITCode):
* ftl/FTLState.cpp:
(JSC::FTL::State::dumpState):
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::jettison):
* interpreter/Interpreter.cpp:
(JSC::getLineNumberForCallFrame):
(JSC::getCallerInfo):
* jit/JITCode.cpp:
(WTF::printInternal):
* jit/JITCode.h:
(JSC::JITCode::topTierJIT):
(JSC::JITCode::nextTierJIT):
(JITCode):
(JSC::JITCode::isJIT):
(JSC::JITCode::isLowerTier):
(JSC::JITCode::isHigherTier):
(JSC::JITCode::isLowerOrSameTier):
(JSC::JITCode::isHigherOrSameTier):
(JSC::JITCode::isOptimizingJIT):
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* runtime/Executable.cpp:
(JSC::EvalExecutable::compileOptimized):
(JSC::samplingDescription):
(JSC::ProgramExecutable::compileOptimized):
(JSC::FunctionExecutable::compileOptimizedForCall):
(JSC::FunctionExecutable::compileOptimizedForConstruct):
2013-04-03 Filip Pizlo <fpizlo@apple.com>
fourthTier: DFG should abstract out how it does forward exits, and that code should be simplified
https://bugs.webkit.org/show_bug.cgi?id=113894
Reviewed by Mark Hahnenberg.
1) We previously had two different ways of convertingToForward, one path for
where we had a ValueRecovery for the current node and one where we didn't.
But the paths were doing exactly the same thing except that if you have a
ValueRecovery, you also find the last applicable mov hint and do some
extra things. This patch combines the two paths and bases both of them on
the previous no-ValueRecovery path, which was simpler to begin with.
2) This moves the logic into DFG::OSRExit, which further simplifies the code
and makes the logic available to the FTL.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::convertToForward):
(DFG):
* dfg/DFGOSRExit.h:
(DFG):
(OSRExit):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
2013-07-15 Oliver Hunt <oliver@apple.com>
Merge dfgFourthTier r147582
2013-07-15 Oliver Hunt <oliver@apple.com>
Merge dfgFourthTier r147014
2013-03-27 Filip Pizlo <fpizlo@apple.com>
fourthTier: JITCode should abstract exactly how the JIT code is structured and where it was allocated
https://bugs.webkit.org/show_bug.cgi?id=113437
Reviewed by Mark Hahnenberg.
JITCode is now a virtual base class, which will allow different JITs to have radically
different memory allocation and management conventions in the future. It will also
make it easier to store JIT-specific meta-data in CodeBlock just by putting it into
an appropriate JITCode subclass.
For now there is one subclass, DirectJITCode, which just behaves like JITCode used to
behave.
* assembler/RepatchBuffer.h:
(JSC::RepatchBuffer::RepatchBuffer):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::resetStubInternal):
(JSC::CodeBlock::bytecodeOffset):
(JSC::CodeBlock::codeOriginForReturn):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::getJITCode):
(JSC::CodeBlock::getJITType):
(CodeBlock):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGDriver.h:
(DFG):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JITCompiler):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::codeLocationForRepatch):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOperations.cpp:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
(JSC::JIT::compile):
(JIT):
* jit/JITCode.cpp:
(JSC):
(JSC::JITCode::JITCode):
(JSC::JITCode::~JITCode):
(JSC::JITCode::execute):
(JSC::JITCode::hostFunction):
(JSC::DirectJITCode::DirectJITCode):
(JSC::DirectJITCode::~DirectJITCode):
(JSC::DirectJITCode::addressForCall):
(JSC::DirectJITCode::executableAddressAtOffset):
(JSC::DirectJITCode::dataAddressAtOffset):
(JSC::DirectJITCode::offsetOf):
(JSC::DirectJITCode::size):
(JSC::DirectJITCode::contains):
* jit/JITCode.h:
(JSC):
(JITCode):
(JSC::JITCode::bottomTierJIT):
(JSC::JITCode::topTierJIT):
(JSC::JITCode::nextTierJIT):
(JSC::JITCode::isOptimizingJIT):
(JSC::JITCode::isBaselineCode):
(JSC::JITCode::jitType):
(JSC::JITCode::jitTypeFor):
(JSC::JITCode::executableAddress):
(JSC::JITCode::start):
(JSC::JITCode::end):
(DirectJITCode):
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* jit/JITStubs.cpp:
(JSC::lazyLinkFor):
(JSC::DEFINE_STUB_FUNCTION):
* jit/ThunkGenerators.cpp:
(JSC::virtualForGenerator):
* llint/LLIntEntrypoints.cpp:
(JSC::LLInt::getFunctionEntrypoint):
(JSC::LLInt::getEvalEntrypoint):
(JSC::LLInt::getProgramEntrypoint):
* llint/LLIntEntrypoints.h:
(JSC):
(LLInt):
(JSC::LLInt::getEntrypoint):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
(JSC::LLInt::entryOSR):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Executable.cpp:
(JSC::EvalExecutable::compileInternal):
(JSC::ProgramExecutable::compileInternal):
(JSC::FunctionExecutable::compileForCallInternal):
(JSC::FunctionExecutable::compileForConstructInternal):
* runtime/Executable.h:
(JSC::ExecutableBase::generatedJITCodeForCall):
(JSC::ExecutableBase::generatedJITCodeForConstruct):
(JSC::ExecutableBase::generatedJITCodeFor):
(ExecutableBase):
(JSC::ExecutableBase::hostCodeEntryFor):
(JSC::ExecutableBase::jsCodeEntryFor):
(JSC::ExecutableBase::jsCodeWithArityCheckEntryFor):
(JSC::NativeExecutable::create):
(JSC::NativeExecutable::finishCreation):
(JSC::EvalExecutable::generatedJITCode):
(JSC::ProgramExecutable::generatedJITCode):
* runtime/ExecutionHarness.h:
(JSC::prepareForExecution):
(JSC::prepareFunctionForExecution):
2013-07-24 Filip Pizlo <fpizlo@apple.com>
It should be possible to hijack IndexingHeader for things other than lengths
https://bugs.webkit.org/show_bug.cgi?id=119065
Reviewed by Mark Hahnenberg.
Made the body of IndexingHeader be a union.
Modified the offlineasm so that you can say IndexingHeader::u.lengths.publicLength.
Previously those dots would cause parse errors. Now an identifier in offlineasm can
have a dot anywhere except the first character.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/parser.rb:
* runtime/IndexingHeader.h:
(JSC::IndexingHeader::offsetOfPublicLength):
(JSC::IndexingHeader::offsetOfVectorLength):
(JSC::IndexingHeader::IndexingHeader):
(JSC::IndexingHeader::vectorLength):
(JSC::IndexingHeader::setVectorLength):
(JSC::IndexingHeader::publicLength):
(JSC::IndexingHeader::setPublicLength):
2013-07-24 Mark Hahnenberg <mhahnenberg@apple.com>
JIT::updateTopCallFrame doesn't update the CallFrame's bytecodeOffset if bytecodeOffset == 0
https://bugs.webkit.org/show_bug.cgi?id=118923
Reviewed by Filip Pizlo.
This bug causes the CallFrame's bytecodeOffset to not be properly set when we
enter, e.g., cti_optimize from an op_enter.
* jit/JITInlines.h:
(JSC::JIT::updateTopCallFrame):
2013-07-23 Filip Pizlo <fpizlo@apple.com>
DFG string concatenation optimizations might emit speculative nodes after emitting nodes that kill the original inputs
https://bugs.webkit.org/show_bug.cgi?id=119032
Reviewed by Oliver Hunt.
It just needs some Phantom action.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
2013-07-10 Mark Lam <mark.lam@apple.com>
Need ExpressionRangeInfo before ResolveForPuts in strict mode.
https://bugs.webkit.org/show_bug.cgi?id=118997.
Reviewed by Oliver Hunt.
If we add an assertion in UnlinkedCodeBlock::expressionRangeForBytecodeOffset()
to ensure that we are able to find an ExpressionRangeInfo for any given bytecode
offset, the following tests will fails:
fast/js/basic-strict-mode.html
fast/js/mozilla/strict/8.7.2.html
With this fix, those tests will no longer fail.
* bytecompiler/NodesCodegen.cpp:
(JSC::AssignResolveNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
- Emit expression info before calls to emitResolveBaseForPut() when in strict mode.
2013-07-23 Mark Lam <mark.lam@apple.com>
Added ExpressionRangeInfo for BinaryOpNodes that can throw exceptions
due to type coersion.
https://bugs.webkit.org/show_bug.cgi?id=116853.
Reviewed by Geoffrey Garen.
* bytecompiler/NodesCodegen.cpp:
(JSC::BinaryOpNode::emitBytecode):
- Added expression info for the strcat and the general binary op cases.
I did not add expression info for the "compare with null" case because
that comparison cannot trigger type coersion, and hence it won't throw
any exceptions and doesn't need the expression info.
2013-07-23 Mark Lam <mark.lam@apple.com>
Removed unused sourceOffset from JSTokenLocation.
https://bugs.webkit.org/show_bug.cgi?id=118996.
Reviewed by Geoffrey Garen.
This also removes the assertion reported in the bug because it is now
moot, thereby resolving the assertion failure issue on Windows.
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayNode::toArgumentList):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
* parser/Lexer.cpp:
(JSC::::lex):
* parser/Lexer.h:
(JSC::::lexExpectIdentifier):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::::Parser):
(JSC::::parseFunctionInfo):
(JSC::::parseExpressionOrLabelStatement):
(JSC::::parseMemberExpression):
* parser/Parser.h:
(JSC::::parse):
* parser/ParserTokens.h:
(JSC::JSTokenLocation::JSTokenLocation):
2013-07-22 Alex Christensen <achristensen@apple.com>
Added assembly files to Windows 64-bit builds.
https://bugs.webkit.org/show_bug.cgi?id=118931
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Added JITStubsMSVC64.asm for x64 and enabled MASM.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Added JITStubsMSVC64.asm.
2013-07-20 Brent Fulgham <bfulgham@apple.com>
[Windows] Remove unneeded custom stdint.h now that we build on VS2010.
https://bugs.webkit.org/show_bug.cgi?id=118868.
Reviewed by Anders Carlsson.
* os-win32/stdint.h: Removed.
* GNUmakefile.list.am: Removed reference to os-win32/stdint.h
2013-07-19 Alex Christensen <achristensen@apple.com>
Added x64 configuration to Visual Studio build.
https://bugs.webkit.org/show_bug.cgi?id=118888
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
* JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
* JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
2013-07-18 Andreas Kling <akling@apple.com>
CodeBlock DFG entry list isn't getting shrunk-to-fit after linking.
<http://webkit.org/b/118875>
<rdar://problem/14488577>
Reviewed by Geoffrey Garen.
Move the CodeBlock::shrinkToFit() call out of JITCompiler::link() and to the call sites
so SpeculativeJIT::linkOSREntries() can fill in CodeBlock::m_dfgData->osrEntry first.
886 kB progression on <http://twitter.com/awesomekling>
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
2013-07-18 Chris Curtis <chris_curtis@apple.com>
Fixed ASSERTION FAILED: callFrame == globalData->topCallFrame in JSC::Interpreter::addStackTraceIfNecessary
https://bugs.webkit.org/show_bug.cgi?id=118498
Reviewed by Geoffrey Garen.
* jit/JITStubs.cpp:
(throwExceptionFromOpCall):
Created new throwExceptionFromOpCall that takes in a functor that contains
a function pointer (to create the errorObject) instead of a JSValue. Inside
of throwExceptionFromOpCall the topCallFrame is being rolled back in order
to handle the error throw. By passing the function pointer in, we can defer
the creation of the error object until after topCallFrame has been rolled
back. This allows the error object to be created with the appropriate top
frame.
DEFINE_STUB_FUNCTION(void*, stack_check):
DEFINE_STUB_FUNCTION(void*, op_call_arityCheck):
DEFINE_STUB_FUNCTION(void*, op_construct_arityCheck):
DEFINE_STUB_FUNCTION(EncodedJSValue, op_call_NotJSFunction):
DEFINE_STUB_FUNCTION(EncodedJSValue, op_construct_NotJSConstruct):
(JSC::ErrorFunctor::~ErrorFunctor):
(JSC::ErrorWithExecFunctor::ErrorWithExecFunctor):
(JSC::ErrorWithExecFunctor::operator()):
(JSC::ErrorWithExecAndCalleeFunctor::ErrorWithExecAndCalleeFunctor):
(JSC::ErrorWithExecAndCalleeFunctor::operator()):
(JSC::ErrorWithExceptionFunctor::ErrorWithExceptionFunctor):
(JSC::ErrorWithExceptionFunctor::operator()):
(JSC::throwExceptionFromOpCall):
In order to eliminate the need to duplicate code, an error functor was
created for the 3 different throwExceptionFromOpCall handles.
1. The exception needs to be created, and the function pointer takes 1
parameter(callFrame->callerFrame()).
2. The exception needs to be created, and the function pointer takes 2
parameters (callFrame->callerFrame(), callFrame.calleeAsValue()).
3. The exception is already created. In this case, At the time when
the error functor is called, globalData.exception is returned.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue):
(JSC::createError):
(JSC::createInvalidParameterError):
(JSC::createNotAConstructorError):
(JSC::createNotAFunctionError):
(JSC::createNotAnObjectError):
* runtime/ExceptionHelpers.h:
The function toString() was being used to stringify an object for an exception
message. If the user wrote a toString() for that object, then the system would
continue to evaluate that code. A new helper function was created to prevent
the system to continue execution and exception creation from that execution.
2013-07-18 Filip Pizlo <fpizlo@apple.com>
LLInt get_argument_by_val for JSVALUE64 stores into the array profile when it meant to store into the value profile
https://bugs.webkit.org/show_bug.cgi?id=118865
Reviewed by Mark Hahnenberg.
* llint/LowLevelInterpreter64.asm:
2013-07-18 Andreas Kling <akling@apple.com>
CodeBlock::m_argumentValueProfiles wastes a lot of memory.
<http://webkit.org/b/118852>
<rdar://problem/14481659>
Reviewed by Anders Carlsson.
Use Vector::resizeToFit() for CodeBlock::m_argumentValueProfiles. We don't need any padding
for growth, since we won't be appending to it anyway.
921 KB progression on <http://twitter.com/awesomekling>
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setNumParameters):
2013-07-17 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix 32-bit after http://trac.webkit.org/changeset/152813
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2013-07-17 Geoffrey Garen <ggaren@apple.com>
API tests should test for JSStringCreateWithCFString with empty string
https://bugs.webkit.org/show_bug.cgi?id=118819
Reviewed by Mark Hahnenberg.
* API/tests/testapi.c:
(main): Test!
2013-07-17 Filip Pizlo <fpizlo@apple.com>
DFG assumes that NewFunction will never pass its input through
https://bugs.webkit.org/show_bug.cgi?id=118798
Reviewed by Sam Weinig.
Previously the DFG was assuming that NewFunction always returns a function. That's not
the case. It may return whatever was passed to it, if it wasn't passed SpecEmpty.
This fact needed to be wired through the compiler.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::makeTop):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2013-07-17 Geoffrey Garen <ggaren@apple.com>
JSStringCreateWithCFString should not convert the empty string into the NULL string
https://bugs.webkit.org/show_bug.cgi?id=118816
Reviewed by Sam Weinig.
* API/JSStringRef.cpp:
(JSStringCreateWithUTF8CString): Removed an extraneous comment, which
a previous version of the patch made incorrect.
* API/JSStringRefCF.cpp:
(JSStringCreateWithCFString): Don't convert the empty string into the
null string.
2013-07-17 Chris Curtis <chris_curtis@apple.com>
Naming convention on createInvalidParamError is incorrect.
https://bugs.webkit.org/show_bug.cgi?id=118756
Reviewed by Geoffrey Garen.
Changed the naming of createInvalidParamError to createInvalidParameterError.
This corrects the naming convention for the function listed in the WebKit code styling.
* interpreter/Interpreter.cpp:
(JSC::loadVarargs):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opIn):
* runtime/ExceptionHelpers.cpp:
(JSC::createInvalidParameterError):
* runtime/ExceptionHelpers.h:
* runtime/JSObject.cpp:
(JSC::JSObject::hasInstance):
2013-07-16 David Farler <dfarler@apple.com>
Typo in DFGInsertionSet.h header guard: "DFGInsectionSet_h" -> "DFGInsertionSet_h"
https://bugs.webkit.org/show_bug.cgi?id=118753
Reviewed by Geoffrey Garen.
* dfg/DFGInsertionSet.h:
"DFGInsectionSet_h" -> "DFGInsertionSet_h"
2013-07-16 Filip Pizlo <fpizlo@apple.com>
MakeRope fixup shouldn't lead to an Identity without kids
https://bugs.webkit.org/show_bug.cgi?id=118745
Reviewed by Mark Hahnenberg.
Make the empty string pruning part of fixupMakeRope() stop if it's on the last child.
Make Node::convertToIdentity release-assert that it has exactly one kid.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupMakeRope):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToIdentity):
2013-07-16 Mark Hahnenberg <mhahnenberg@apple.com>
Remove reference to JSValueStructSupport.h from JSExport.h
https://bugs.webkit.org/show_bug.cgi?id=118746
Reviewed by Filip Pizlo.
* API/JSExport.h: No such header exists, so it doesn't make sense to reference it.
2013-07-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r151978.
http://trac.webkit.org/changeset/151978
https://bugs.webkit.org/show_bug.cgi?id=118651
Caused regressions at least 3 websites (Requested by rniwa on
#webkit).
* runtime/JSCJSValue.h:
* runtime/JSString.h:
2013-07-12 Chris Curtis <chris_curtis@apple.com>
Optimize addStrackTraceIfNecessary to be faster in the case when it's not necessary
https://bugs.webkit.org/show_bug.cgi?id=118328
Reviewed by Geoffrey Garen.
Retrieving the stack is costly. We want to get it only once. By moving the check
for the .stack property above the code to retrieve the stack, we ensure this.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::addStackTraceIfNecessary):
2013-07-12 Brent Fulgham <bfulgham@apple.com>
[Windows] Build correction after r152573/r152577.
https://bugs.webkit.org/show_bug.cgi?id=118610
Reviewed by Oliver Hunt.
* jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub): Hand-feed MSVC++ the fact that we want the second
argument of the make_pair to be a function pointer.
2013-07-11 Oliver Hunt <oliver@apple.com>
Attempt to fix the windows build.
* jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub):
* jit/JITThunks.h:
2013-07-10 Oliver Hunt <oliver@apple.com>
NativeExecutable cache needs to use both call and construct functions for key
https://bugs.webkit.org/show_bug.cgi?id=118545
Reviewed by Geoffrey Garen.
Make the native executable cache make use a key pair so we don't decide to
treat all subsequent functions as not being constructors.
* jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub):
* jit/JITThunks.h:
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::create):
* runtime/JSCell.cpp:
(JSC::JSCell::getCallData):
(JSC::JSCell::getConstructData):
2013-07-09 Mark Lam <mark.lam@apple.com>
Gardening to unbreak builds on the Windows bot.
Not reviewed.
* parser/ParserTokens.h:
2013-07-09 Mark Lam <mark.lam@apple.com>
Fix 30% JSBench regression (caused by adding column numbers to stack traces).
https://bugs.webkit.org/show_bug.cgi?id=118481.
Reviewed by Mark Hahnenberg and Geoffrey Garen.
Previously, we already capture ExpressionRangeInfo that provides a divot for
each bytecode that can potentially throw an exception (and therefore generate
a stack trace). On first attempt to compute column numbers, we then do a walk
of the source string to record all line start positions in a table associated
with the SourceProvider. The column number can then be computed as
divot - lineStartFor(bytecodeOffset).
The computation of this lineStarts table is the source of the 30% JSBench
performance regression.
The new code now records lineStarts as the lexer and parser scans the source
code. These lineStarts are then used to compute the column number for the
given divot, and stored in the ExpressionRangeInfo. Similarly, we also capture
the line number at the divot point and store that in the ExpressionRangeInfo.
Hence, to look up line and column numbers, we now lookup the ExpressionRangeInfo
for the bytecodeOffset, and then compute the line and column from the values
stored in the expression info.
The strategy:
1. We want to minimize perturbations to the lexer and parser. Specifically,
the changes added should not change how it scans code, and generate bytecode.
2. We regard the divot as the source character position we are interested
in. As such, we'll capture line and lineStart (for column) at the point
when we capture the divot information. This ensures that the 3 values are
consistent.
How the change is done:
1. Change the lexer to track lineStarts.
2. Change the parser to capture line and lineStarts at the point of capturing
divots.
3. Change the parser and associated code to plumb these values all the way to
the point that the correspoinding ExpressionRangeInfo is emitted.
4. Propagate and record SourceCode firstLine and firstLineColumnOffset to the
the necessary places so that we can add them as needed when reifying
UnlinkedCodeBlocks into CodeBlocks.
5. Compress the line and column number values in the ExpressionRangeInfo. In
practice, we seldom have both large line and column numbers. Hence, we can
encode both in an uint32_t most of the time. For the times when we encounter
both large line and column numbers, we have a fallback to store the "fat"
position info.
6. Emit an ExpressionRangeInfo for UnaryOp nodes to get more line and column
number coverage.
7. Change the interpreter to use the new way of computing line and column.
8. Delete old line and column computation code that is now unused.
Misc details:
- the old lexer was tracking both a startOffset and charPosition where
charPosition equals startOffset - SourceCode.startOffset. We now use
startOffset exclusively throughout the system for consistency.
All offset values (including lineStart) are relative to the start of the
SourceProvider string. These values will only be converted to be relative
to the SourceCode.startOffset at the very last minute i.e. when the divot
is stored into the ExpressionRangeInfo.
This change to use the same offset system everywhere reduces confusion
from having to convert back and forth between the 2 systems. It also
enables a lot of assertions to be used.
- Also fixed some bugs in the choice of divot positions to use. For example,
both Eval and Function expressions previously used column numbers from
the start of the expression but used the line number at the end of the
expression. This is now fixed to use either the start or end positions
as appropriate, but not a mix of line and columns from both.
- Why use ints instead of unsigneds for offsets and lineStarts inside the
lexer and parser?
Some tests (e.g. fast/js/call-base-resolution.html and
fast/js/eval-cross-window.html) has shown that lineStart offsets can be
prior to the SourceCode.startOffset. Keeping the lexer offsets as ints
simplifies computations and makes it easier to maintain the assertions
that (startOffset >= lineStartOffset).
However, column and line numbers are always unsigned when we publish
them to the ExpressionRangeInfo. The ints are only used inside the
lexer and parser ... well, and bytecode generator.
- For all cases, lineStart is always captured where the divot is captured.
However, some sputnik conformance tests have shown that we cannot honor
line breaks for assignment statements like the following:
eval("x\u000A*=\u000A-1;");
In this case, the lineStart is expected to be captured at the start of
the assignment expression instead of at the divot point in the middle.
The assignment expression is the only special case for this.
This patch has been tested against the full layout tests both with release
and debug builds with no regression.
* API/JSContextRef.cpp:
(JSContextCreateBacktrace):
- Updated to use the new StackFrame::computeLineAndColumn().
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
- Added m_firstLineColumnOffset initialization.
- Plumbed the firstLineColumnOffset into the SourceCode.
- Initialized column for op_debug using the new way.
(JSC::CodeBlock::lineNumberForBytecodeOffset):
- Changed to compute line number using the ExpressionRangeInfo.
(JSC::CodeBlock::columnNumberForBytecodeOffset): Added
- Changed to compute column number using the ExpressionRangeInfo.
(JSC::CodeBlock::expressionRangeForBytecodeOffset):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::firstLineColumnOffset):
(JSC::GlobalCodeBlock::GlobalCodeBlock):
- Plumbed firstLineColumnOffset through to the super class.
(JSC::ProgramCodeBlock::ProgramCodeBlock):
- Plumbed firstLineColumnOffset through to the super class.
(JSC::EvalCodeBlock::EvalCodeBlock):
- Plumbed firstLineColumnOffset through to the super class.
But for EvalCodeBlocks, the firstLineColumnOffset is always 1
because we're starting with a new source string with no start
offset.
(JSC::FunctionCodeBlock::FunctionCodeBlock):
- Plumbed firstLineColumnOffset through to the super class.
* bytecode/ExpressionRangeInfo.h:
- Added modes for encoding line and column into a single 30-bit
unsigned. The encoding is in 1 of 3 modes:
1. FatLineMode: 22-bit line, 8-bit column
2. FatColumnMode: 8-bit line, 22-bit column
3. FatLineAndColumnMode: 32-bit line, 32-bit column
(JSC::ExpressionRangeInfo::encodeFatLineMode): Added.
- Encodes line and column into the 30-bit position using FatLine mode.
(JSC::ExpressionRangeInfo::encodeFatColumnMode): Added.
- Encodes line and column into the 30-bit position using FatColumn mode.
(JSC::ExpressionRangeInfo::decodeFatLineMode): Added.
- Decodes the FatLine mode 30-bit position into line and column.
(JSC::ExpressionRangeInfo::decodeFatColumnMode): Added.
- Decodes the FatColumn mode 30-bit position into line and column.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- Plumbed startColumn through.
(JSC::UnlinkedFunctionExecutable::link):
- Plumbed startColumn through.
(JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
- Computes a line number using the new way.
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
- Added decoding of line and column.
- Added handling of the case when we do not find a fitting expression
range info for a specified bytecodeOffset. This only happens if the
bytecodeOffset is below the first expression range info. In that
case, we'll use the first expression range info entry.
(JSC::UnlinkedCodeBlock::addExpressionInfo):
- Added encoding of line and column.
* bytecode/UnlinkedCodeBlock.h:
- Added m_expressionInfoFatPositions in RareData.
(JSC::UnlinkedFunctionExecutable::functionStartColumn):
(JSC::UnlinkedCodeBlock::shrinkToFit):
- Removed obsoleted m_lineInfo.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCall): Plumbed line and lineStart through.
(JSC::BytecodeGenerator::emitCallEval): Plumbed line and lineStart through.
(JSC::BytecodeGenerator::emitCallVarargs): Plumbed line and lineStart through.
(JSC::BytecodeGenerator::emitConstruct): Plumbed line and lineStart through.
(JSC::BytecodeGenerator::emitDebugHook): Plumbed lineStart through.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitNode):
(JSC::BytecodeGenerator::emitNodeInConditionContext):
- Removed obsoleted m_lineInfo.
(JSC::BytecodeGenerator::emitExpressionInfo):
- Plumbed line and lineStart through.
- Compute the line and column to be added to the expression range info.
* bytecompiler/NodesCodegen.cpp:
(JSC::ThrowableExpressionData::emitThrowReferenceError):
(JSC::ResolveNode::emitBytecode):
(JSC::ArrayNode::toArgumentList):
(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):
- Plumbed line and lineStart through the above as needed.
(JSC::UnaryOpNode::emitBytecode):
- Added emission of an ExpressionRangeInfo for the UnaryOp node.
(JSC::BinaryOpNode::emitStrcat):
(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):
- Plumbed line and lineStart through the above as needed.
(JSC::ConstStatementNode::emitBytecode):
(JSC::EmptyStatementNode::emitBytecode):
(JSC::DebuggerStatementNode::emitBytecode):
(JSC::ExprStatementNode::emitBytecode):
(JSC::VarStatementNode::emitBytecode):
(JSC::IfElseNode::emitBytecode):
(JSC::DoWhileNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::LabelNode::emitBytecode):
(JSC::ThrowNode::emitBytecode):
(JSC::TryNode::emitBytecode):
(JSC::ProgramNode::emitBytecode):
(JSC::EvalNode::emitBytecode):
(JSC::FunctionBodyNode::emitBytecode):
- Plumbed line and lineStart through the above as needed.
* interpreter/Interpreter.cpp:
(JSC::appendSourceToError):
- Added line and column arguments for expressionRangeForBytecodeOffset().
(JSC::StackFrame::computeLineAndColumn):
- Replaces StackFrame::line() and StackFrame::column().
(JSC::StackFrame::expressionInfo):
- Added line and column arguments.
(JSC::StackFrame::toString):
- Changed to use the new StackFrame::computeLineAndColumn().
(JSC::Interpreter::getStackTrace):
- Added the needed firstLineColumnOffset arg for the StackFrame.
* interpreter/Interpreter.h:
* parser/ASTBuilder.h:
(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::createFunctionExpr):
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createFuncDeclStatement):
(JSC::ASTBuilder::createBlockStatement):
(JSC::ASTBuilder::createExprStatement):
(JSC::ASTBuilder::createIfStatement):
(JSC::ASTBuilder::createForLoop):
(JSC::ASTBuilder::createForInLoop):
(JSC::ASTBuilder::createVarStatement):
(JSC::ASTBuilder::createReturnStatement):
(JSC::ASTBuilder::createBreakStatement):
(JSC::ASTBuilder::createContinueStatement):
(JSC::ASTBuilder::createTryStatement):
(JSC::ASTBuilder::createSwitchStatement):
(JSC::ASTBuilder::createWhileStatement):
(JSC::ASTBuilder::createDoWhileStatement):
(JSC::ASTBuilder::createLabelStatement):
(JSC::ASTBuilder::createWithStatement):
(JSC::ASTBuilder::createThrowStatement):
(JSC::ASTBuilder::createDebugger):
(JSC::ASTBuilder::createConstStatement):
(JSC::ASTBuilder::appendBinaryExpressionInfo):
(JSC::ASTBuilder::appendUnaryToken):
(JSC::ASTBuilder::unaryTokenStackLastStart):
(JSC::ASTBuilder::unaryTokenStackLastLineStartPosition): Added.
(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):.
- Plumbed line, lineStart, and startColumn through the above as needed.
* parser/Lexer.cpp:
(JSC::::currentSourcePtr):
(JSC::::setCode):
- Added tracking for sourceoffset and lineStart.
(JSC::::internalShift):
(JSC::::parseIdentifier):
- Added tracking for lineStart.
(JSC::::parseIdentifierSlowCase):
(JSC::::parseString):
- Added tracking for lineStart.
(JSC::::parseStringSlowCase):
(JSC::::lex):
- Added tracking for sourceoffset.
(JSC::::sourceCode):
* parser/Lexer.h:
(JSC::Lexer::currentOffset):
(JSC::Lexer::currentLineStartOffset):
(JSC::Lexer::setOffset):
- Added tracking for lineStart.
(JSC::Lexer::offsetFromSourcePtr): Added. conversion function.
(JSC::Lexer::sourcePtrFromOffset): Added. conversion function.
(JSC::Lexer::setOffsetFromSourcePtr):
(JSC::::lexExpectIdentifier):
- Added tracking for sourceoffset and lineStart.
* 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):
- Plumbed line and lineStart through the above as needed.
* parser/Nodes.cpp:
(JSC::StatementNode::setLoc): Plumbed lineStart.
(JSC::ScopeNode::ScopeNode): Plumbed lineStart.
(JSC::ProgramNode::ProgramNode): Plumbed startColumn.
(JSC::ProgramNode::create): Plumbed startColumn.
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode): Plumbed startColumn.
(JSC::FunctionBodyNode::create): Plumbed startColumn.
* parser/Nodes.h:
(JSC::Node::startOffset):
(JSC::Node::lineStartOffset): Added.
(JSC::StatementNode::firstLine):
(JSC::StatementNode::lastLine):
(JSC::ThrowableExpressionData::ThrowableExpressionData):
(JSC::ThrowableExpressionData::setExceptionSourceCode):
(JSC::ThrowableExpressionData::divotStartOffset):
(JSC::ThrowableExpressionData::divotEndOffset):
(JSC::ThrowableExpressionData::divotLine):
(JSC::ThrowableExpressionData::divotLineStart):
(JSC::ThrowableSubExpressionData::ThrowableSubExpressionData):
(JSC::ThrowableSubExpressionData::setSubexpressionInfo):
(JSC::ThrowableSubExpressionData::subexpressionDivot):
(JSC::ThrowableSubExpressionData::subexpressionStartOffset):
(JSC::ThrowableSubExpressionData::subexpressionEndOffset):
(JSC::ThrowableSubExpressionData::subexpressionLine):
(JSC::ThrowableSubExpressionData::subexpressionLineStart):
(JSC::ThrowablePrefixedSubExpressionData::ThrowablePrefixedSubExpressionData):
(JSC::ThrowablePrefixedSubExpressionData::setSubexpressionInfo):
(JSC::ThrowablePrefixedSubExpressionData::subexpressionDivot):
(JSC::ThrowablePrefixedSubExpressionData::subexpressionStartOffset):
(JSC::ThrowablePrefixedSubExpressionData::subexpressionEndOffset):
(JSC::ThrowablePrefixedSubExpressionData::subexpressionLine):
(JSC::ThrowablePrefixedSubExpressionData::subexpressionLineStart):
(JSC::ScopeNode::startStartOffset):
(JSC::ScopeNode::startLineStartOffset):
(JSC::ProgramNode::startColumn):
(JSC::EvalNode::startColumn):
(JSC::FunctionBodyNode::startColumn):
- Plumbed line and lineStart through the above as needed.
* parser/Parser.cpp:
(JSC::::Parser):
(JSC::::parseSourceElements):
(JSC::::parseVarDeclarationList):
(JSC::::parseConstDeclarationList):
(JSC::::parseForStatement):
(JSC::::parseBreakStatement):
(JSC::::parseContinueStatement):
(JSC::::parseReturnStatement):
(JSC::::parseThrowStatement):
(JSC::::parseWithStatement):
- Plumbed line and lineStart through the above as needed.
(JSC::::parseFunctionBody):
- Plumbed startColumn.
(JSC::::parseFunctionInfo):
(JSC::::parseFunctionDeclaration):
(JSC::LabelInfo::LabelInfo):
(JSC::::parseExpressionOrLabelStatement):
(JSC::::parseAssignmentExpression):
(JSC::::parseBinaryExpression):
(JSC::::parseProperty):
(JSC::::parseObjectLiteral):
(JSC::::parsePrimaryExpression):
(JSC::::parseMemberExpression):
(JSC::::parseUnaryExpression):
- Plumbed line, lineStart, startColumn through the above as needed.
* parser/Parser.h:
(JSC::Parser::next):
(JSC::Parser::nextExpectIdentifier):
(JSC::Parser::tokenStart):
(JSC::Parser::tokenColumn):
(JSC::Parser::tokenEnd):
(JSC::Parser::tokenLineStart):
(JSC::Parser::lastTokenLine):
(JSC::Parser::lastTokenLineStart):
(JSC::::parse):
* parser/ParserTokens.h:
(JSC::JSTokenLocation::JSTokenLocation):
- Plumbed lineStart.
(JSC::JSTokenLocation::lineStartPosition):
(JSC::JSTokenLocation::startPosition):
(JSC::JSTokenLocation::endPosition):
* parser/SourceCode.h:
(JSC::SourceCode::SourceCode):
(JSC::SourceCode::startColumn):
(JSC::makeSource):
(JSC::SourceCode::subExpression):
* parser/SourceProvider.cpp: delete old code.
* parser/SourceProvider.h: delete old code.
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::closeBraceToken):
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
- Plumbed lineStart.
* 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::createFunctionExpr):
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::createFuncDeclStatement):
(JSC::SyntaxChecker::createForInLoop):
(JSC::SyntaxChecker::createReturnStatement):
(JSC::SyntaxChecker::createBreakStatement):
(JSC::SyntaxChecker::createContinueStatement):
(JSC::SyntaxChecker::createWithStatement):
(JSC::SyntaxChecker::createLabelStatement):
(JSC::SyntaxChecker::createThrowStatement):
(JSC::SyntaxChecker::createGetterOrSetterProperty):
(JSC::SyntaxChecker::appendBinaryExpressionInfo):
(JSC::SyntaxChecker::operatorStackPop):
- Made SyntaxChecker prototype changes to match ASTBuilder due to new
args added for plumbing line, lineStart, and startColumn.
* runtime/CodeCache.cpp:
(JSC::CodeCache::generateBytecode):
(JSC::CodeCache::getCodeBlock):
- Plumbed startColumn.
* runtime/Executable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::compileInternal):
(JSC::FunctionExecutable::produceCodeBlockFor):
(JSC::FunctionExecutable::fromGlobalCode):
- Plumbed startColumn.
* runtime/Executable.h:
(JSC::ScriptExecutable::startColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
- Plumbed startColumn.
2013-07-08 Carlos Garcia Campos <cgarcia@igalia.com>
Unreviewed. Fix make distcheck.
* GNUmakefile.list.am: Add missing header files.
2013-07-04 Patrick Gansterer <paroga@webkit.org>
[CMake] Add generation of JITStubs for x86_64 MSVC
https://bugs.webkit.org/show_bug.cgi?id=116666
Reviewed by Laszlo Gombos.
Also move the generation for ARM CPU into the CMakeLists.txt,
since it's compiler specific and not dedicated to Windows CE.
* CMakeLists.txt:
* PlatformWinCE.cmake: Removed.
2013-07-04 Patrick Gansterer <paroga@webkit.org>
[CMake] Add STATICALLY_LINKED_WITH_WTF to JavaScriptCore project
https://bugs.webkit.org/show_bug.cgi?id=118120
Reviewed by Gyuyoung Kim.
Since WTF is a static library linked to JavaScriptCore on all CMake ports
we need to define STATICALLY_LINKED_WITH_WTF for all of them.
This makes only a difference for Windows, since WTF_EXPORT and WTF_IMPORT
are the same on all other platforms.
* CMakeLists.txt:
2013-07-02 Mark Hahnenberg <mhahnenberg@apple.com>
Replace RELEASE_ASSERT with ASSERT in CodeBlock:: bytecodeOffsetForCallAtIndex
https://bugs.webkit.org/show_bug.cgi?id=118316
Reviewed by Geoffrey Garen.
This is causing some crashiness in release builds. We should replace it with an ASSERT
until we track down all the places that need fixing in bug 118315.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::bytecodeOffsetForCallAtIndex):
2013-07-02 Brent Fulgham <bfulgham@apple.com>
[Windows] Unreviewed build correction for 'DebugSuffix' target.
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Must pass the
DEBUGSUFFIX definition to the nmake instance to be available during script processing.
2013-07-01 Sergio Correia <sergio.correia@openbossa.org>
[JSC]: Fix maybe-uninitialized gcc 4.8 warning in DFGSpeculativeJIT.cpp
https://bugs.webkit.org/show_bug.cgi?id=118278
Reviewed by Filip Pizlo.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
Initialize valueGPR with InvalidGPRReg.
2013-07-01 Csaba Osztrogonác <ossy@webkit.org>
Fix cast-align warnings in JavaScriptCore/heap/HandleBlockInlines.h
https://bugs.webkit.org/show_bug.cgi?id=118242
Reviewed by Mark Hahnenberg.
* heap/HandleBlockInlines.h:
(JSC::HandleBlock::nodes):
2013-06-29 Andreas Kling <akling@apple.com>
Follow-up to r152206: also update HashFlags8BitBuffer in the LLInt.
* llint/LowLevelInterpreter.asm:
2013-06-28 Andreas Kling <akling@apple.com>
Un-crashify JSC tests on debug bots after Anders had his way with StringImpl.
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
2013-06-28 Anders Carlsson <andersca@apple.com>
Remove String::deprecatedCharactersWithNullTermination() and related code
https://bugs.webkit.org/show_bug.cgi?id=118211
Reviewed by Benjamin Poulain.
* API/JSStringRef.cpp:
(JSStringCreateWithCharactersNoCopy):
Update call to StringImpl::createWithoutCopying.
2013-06-27 Timothy Hatcher <timothy@apple.com>
Notify the debugger about functions created from source code via new Function() or WebCore::JSLazyEventListener.
https://bugs.webkit.org/show_bug.cgi?id=118063
Reviewed by Geoffrey Garen.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode): Call Debugger::sourceParsed.
2013-06-26 Anders Carlsson <andersca@apple.com>
Add JSStringCreateWithCharactersNoCopy SPI
https://bugs.webkit.org/show_bug.cgi?id=118074
<rdar://problem/14279905>
Reviewed by Geoffrey Garen.
* API/JSStringRef.cpp:
(JSStringCreateWithCharactersNoCopy):
Create a new OpaqueJSString, using the newly added StringImpl::createWithoutCopying function.
* API/JSStringRefPrivate.h: Added.
Add a home for the JSStringCreateWithCharactersNoCopy function.
* API/OpaqueJSString.h:
(OpaqueJSString::OpaqueJSString):
Just call isolatedCopy on the passed in string.
* API/tests/testapi.c:
Add an API test for JSStringCreateWithCharactersNoCopy.
* JavaScriptCore.xcodeproj/project.pbxproj:
Add new files.
2013-06-25 Ryosuke Niwa <rniwa@webkit.org>
JSString should remember AtomicString
https://bugs.webkit.org/show_bug.cgi?id=117386
Reviewed by Geoffrey Garen.
Added JSValue::toAtomicString and JSString::atomicString. These two functions allow WebCore to update
JSString's m_value to set isAtomic flag and avoid the AtomicStringTable lookups in subsequent attempts
to obtain the AtomicString of the same value.
* runtime/JSCJSValue.h:
* runtime/JSString.h:
(JSC::JSString::atomicString):
(JSC::JSValue::toAtomicString):
2013-06-24 Roger Fong <roger_fong@apple.com>
Unreviewed. Makefile build fix for AppleWindows.
* JavaScriptCore.vcxproj/JavaScriptCore.make:
2013-06-17 Darin Adler <darin@apple.com>
Sort all the Xcode project files
https://bugs.webkit.org/show_bug.cgi?id=117696
Reviewed by Anders Carlsson.
* JavaScriptCore.xcodeproj/project.pbxproj: Ran the sort-Xcode-project-file script.
2013-06-21 Mark Lam <mark.lam@apple.com>
Introducing the VMStackBounds class.
https://bugs.webkit.org/show_bug.cgi?id=117862.
Reviewed by Geoffrey Garen.
- Removed Interpreter::StackPolicy.
- The new VMStackBounds will take over choosing the appropriate stack
size requirements, and invoking the underlying WTF::StackBounds to
to the real bounds check.
- VMStackBounds will now be used universally throughout JSC instead of
WTF::StackBounds.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* bytecompiler/BytecodeGenerator.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
* interpreter/Interpreter.h:
(JSC::Interpreter::isInErrorHandlingMode):
* parser/Parser.cpp:
(JSC::::Parser):
* parser/Parser.h:
* runtime/StringRecursionChecker.h:
(JSC::StringRecursionChecker::performCheck):
* runtime/VMStackBounds.h: Added.
(JSC::VMStackBounds::VMStackBounds):
(JSC::VMStackBounds::isSafeToRecurse):
(JSC::VMStackBounds::requiredCapacity):
2013-06-20 Mark Lam <mark.lam@apple.com>
Change stack capacity requirement to be more reasonable.
https://bugs.webkit.org/show_bug.cgi?id=117801.
Reviewed by Geoffrey Garen.
Previously, the requiredStack in StackPolicy::StackPolicy() was set to
to a high value like 256K to reduce the chances of encountering an
undetected stack overflow in a scenario where we have a combination of
deeply nested divs and a large amount recursive re-entries into the JSGlobalData.
However, this high value of requiredStack still does not completely
ensure that we will never encounter an undetected stack overflow. It
only lessens the probability of encountering it.
Secondly, on some platforms, the total stack size can be less than 256K
to start with. Hence, this high value requiredStack renders the JSGlobalData
unuseable on those platforms.
This patch will fix the requiredStack to be more reasonable based on
real world stack usage by the JSGlobalData. We won't (and cannot) try to prevent
undetected stack overflows outside of JSC as well. External code that
do deep recursion (e.g. Documnet::updateLayout()) should do their own
stack checks.
From a previous experiment, we measured the following:
On a debug build on OSX:
1. Stack usage different between recursive calls to interpreter entry:
7744 bytes
On a release build on OSX:
2. Stack usage difference between recursive calls to interpreter entry:
6352 bytes
Using these as a guide, we'll pick the following values for the
StackPolicy:
requiredStack: 32K
errorModeRequiredStack: 16K
The requiredStack is chosen to be 4x the measured usage above. The
additional 3x is a conservative estimate to account for stack space
that may be needed by other native functions called while in the
interpreter.
The errorModeRequiredStack has to be less than the requiredStack or we
won't be able to reenter the interpreter to do error handling work when
an imminent stack overflow is detected. It is assumed that the error
handling code will only do minimal work to allocate an exception and its
stack trace, and not run any arbitrary JS code. As such, it is safe to
allow re-entry into the interpreter with only 2x the measured usage in
this case.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::StackPolicy::StackPolicy):
2013-06-20 Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com>
HashSet: reverse the order of the template arguments at alternate 'find', 'contains' and 'add' methods
https://bugs.webkit.org/show_bug.cgi?id=117830
Reviewed by Anders Carlsson.
The order of the template arguments at HashSet alternate 'find', 'contains' and
'add' methods is reversed so that callers can just pass the translator
and let the compiler deduce input argument type.
* runtime/Identifier.h:
(JSC::IdentifierTable::add):
2013-06-20 Roger Fong <roger_fong@apple.com>
Make Windows makefile copy build output to a different folder.
<rdar://problem/14219184>.
* JavaScriptCore.vcxproj/JavaScriptCore.make:
2013-06-20 Mark Hahnenberg <mhahnenberg@apple.com>
Improper deallocation of JSManagedValue causes crashes during autorelease pool draining
https://bugs.webkit.org/show_bug.cgi?id=117840
Reviewed by Geoffrey Garen.
Improperly managing a JSManagedValue can cause a crash when the JSC::Weak inside the
JSManagedValue is destroyed upon deallocation. We would rather have improperly maintained
JSManagedValues cause memory leaks than take down the whole app.
The fix is to use the callback to the JSC::Weak on the destruction of the JSGlobalData so that we
can safely null it out. This will prevent ~Weak from crashing.
* API/JSManagedValue.mm:
(-[JSManagedValue JSC::JSC::]):
(JSManagedValueHandleOwner::finalize):
* API/tests/testapi.mm: Added a test that crashed prior to this fix due to a leaked
managed reference. Also fixed a small style nit I noticed in another test.
2013-06-18 Oliver Hunt <oliver@apple.com>
Going to google.com/trends causes a crash
https://bugs.webkit.org/show_bug.cgi?id=117602
Reviewed by Geoffrey Garen.
When handling op_throw, etc we need to flush the variables and arguments
for the entire inline stack, not just the top frame.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::flushAllArgumentsAndCapturedVariablesInInlineStack):
(JSC::DFG::ByteCodeParser::parseBlock):
2013-06-18 Roger Fong <roger_fong@apple.com>
Replace tools32 folder with tools and update WebKit Windows solution accordingly.
<rdar://problem/14118143>.
Rubberstamped by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCoreDebug.props:
* JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props:
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props:
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props:
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props:
* JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd:
* JavaScriptCore.vcxproj/JavaScriptCoreProduction.props:
* JavaScriptCore.vcxproj/JavaScriptCoreRelease.props:
* JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props:
* JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
* JavaScriptCore.vcxproj/jsc/jscDebug.props:
* JavaScriptCore.vcxproj/jsc/jscProduction.props:
* JavaScriptCore.vcxproj/jsc/jscRelease.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
* JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapiDebug.props:
* JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props:
* JavaScriptCore.vcxproj/testapi/testapiProduction.props:
* JavaScriptCore.vcxproj/testapi/testapiRelease.props:
* JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props:
2013-06-17 Roger Fong <roger_fong@apple.com>
Modify Windows makefiles to copy some bin output into Program Files.
https://bugs.webkit.org/show_bug.cgi?id=117714.
<rdar://problem/14179054>
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.make:
2013-06-14 Ryosuke Niwa <rniwa@webkit.org>
Function names on Object.prototype should be common identifiers
https://bugs.webkit.org/show_bug.cgi?id=117614
Reviewed by Darin Adler.
Patch written by Sam Weinig. Make Object's prototype function names common identififers since they're used frequently.
* runtime/CommonIdentifiers.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::reset):
* runtime/JSObject.h:
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
2013-06-13 Ryosuke Niwa <rniwa@webkit.org>
Remove LiteralIdentifierTable
https://bugs.webkit.org/show_bug.cgi?id=117613
Reviewed by Geoffrey Garen.
Removed LiteralIdentifierTable since it doesn't seem to have any perf. impact now.
* runtime/Identifier.cpp:
(JSC::Identifier::add):
2013-06-12 Conrad Shultz <conrad_shultz@apple.com>
JSExport header documentation substitutes "semicolon" for "colon"
https://bugs.webkit.org/show_bug.cgi?id=117552
Reviewed by Mark Hahnenberg.
* API/JSExport.h:
Fix a couple typos.
2013-06-10 Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
[JSC] Remove a vestige of wxWidgets support.
https://bugs.webkit.org/show_bug.cgi?id=117419
Reviewed by Benjamin Poulain.
* runtime/JSExportMacros.h: Remove a check for BUILDING_WX__ that
seems to have gone unnoticed when the wxWidgets port was removed.
2013-06-06 Roger Fong <roger_fong@apple.com>
Stop copying AAS binaries into build folder.
https://bugs.webkit.org/show_bug.cgi?id=117319.
Rubberstamped by Darin Adler.
* JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd:
* JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd:
* JavaScriptCore.vcxproj/jsc/jscPreLink.cmd:
* JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd:
* JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd:
* JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd:
2013-06-05 Filip Pizlo <fpizlo@apple.com>
DFG CFA shouldn't filter ArrayModes with ALL_NON_ARRAY_ARRAY_MODES if the speculated type is not SpecArray
https://bugs.webkit.org/show_bug.cgi?id=117279
<rdar://problem/14078025>
Reviewed by Mark Hahnenberg.
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::filterArrayModesByType):
2013-06-05 Michael Saboff <msaboff@apple.com>
JSC: Crash beneath cti_op_div @ http://gmailblog.blogspot.com
https://bugs.webkit.org/show_bug.cgi?id=117280
Reviewed by Filip Pizlo.
Updated the merging of VariableAccessData nodes in ArgumentPosition lists
to find the unified VariableAccessData node that is the root of the
current node instead of using the current node directly when merging
attributes.
Added new dump code to dump the ArgumentPosition list.
* dfg/DFGArgumentPosition.h:
(JSC::DFG::rgumentPosition::mergeArgumentPredictionAwareness):
(JSC::DFG::ArgumentPosition::mergeArgumentUnboxingAwareness):
(JSC::DFG::ArgumentPosition::dump):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
2013-06-05 Bear Travis <betravis@adobe.com>
[CSS Exclusions][CSS Shapes] Split CSS Exclusions & Shapes compile & runtime flags
https://bugs.webkit.org/show_bug.cgi?id=117172
Reviewed by Alexandru Chiculita.
Adding the CSS_SHAPES compile flag.
* Configurations/FeatureDefines.xcconfig:
2013-06-05 Balazs Kilvady <kilvadyb@homejinni.com>
JSC Assertion tests failures on MIPS.
https://bugs.webkit.org/show_bug.cgi?id=116552
Reviewed by Geoffrey Garen.
Fix condition handlig in branchAdd32 implemetations.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branchAdd32):
2013-06-04 Julien Brianceau <jbrianceau@nds.com>
[sh4] Add floating point absolute function support in baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=117147
Reviewed by Geoffrey Garen.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::supportsFloatingPointAbs):
(JSC::MacroAssemblerSH4::absDouble):
* assembler/SH4Assembler.h:
(JSC::SH4Assembler::dabs):
(JSC::SH4Assembler::printInstr):
2013-06-04 Zan Dobersek <zdobersek@igalia.com>
[JSC] Test262 15.5.4.9_3 test is failing
https://bugs.webkit.org/show_bug.cgi?id=116789
Reviewed by Geoffrey Garen.
Bring the String.prototype.localeCompare behavior in line wit ES5 15.9.4.9.
If method is not given enough arguments, the minimal amount of arguments must be assumed, with their value being undefined.
The first argument to localeCompare, in its string form, is used as the 'that' string that's used in the comparison.
Therefor, when calling str.localeCompare() or str.localeCompare(undefined), the first argument is `undefined` and the
string "undefined" is used as the string to which value of str is compared.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncLocaleCompare): Remove the early return in case of no given arguments to achieve the desired behavior.
2013-06-03 Hojong Han <hojong.han@samsung.com>
[EFL] Implement GCActivityCallback
https://bugs.webkit.org/show_bug.cgi?id=95923
Reviewed by Geoffrey Garen.
Implements the activity triggered garbage collector.
Additional GCs can be triggered by platfrom timer.
It has sort of compaction effect not to make JSC heap grow fast
so that memory usage becomes lower than usual.
* PlatformEfl.cmake: Added.
* heap/HeapTimer.cpp:
(JSC):
(JSC::HeapTimer::HeapTimer):
(JSC::HeapTimer::~HeapTimer):
(JSC::HeapTimer::add):
(JSC::HeapTimer::stop):
(JSC::HeapTimer::timerEvent):
* heap/HeapTimer.h:
(HeapTimer):
* jsc.cpp:
(main):
* runtime/GCActivityCallback.cpp:
(JSC):
(JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
(JSC::DefaultGCActivityCallback::scheduleTimer):
(JSC::DefaultGCActivityCallback::cancelTimer):
(JSC::DefaultGCActivityCallback::didAllocate):
* runtime/GCActivityCallback.h:
(GCActivityCallback):
(JSC::GCActivityCallback::GCActivityCallback):
(DefaultGCActivityCallback):
2013-06-03 Roger Fong <roger_fong@apple.com>
Nuke VS2005 files from the tree.
<rdar://problem/14042021>.
Rubberstamped by Brent Fulgham.
* JavaScriptCore.vcproj: Removed.
* JavaScriptCore.vcproj/JavaScriptCore: Removed.
* JavaScriptCore.vcproj/JavaScriptCore.make: Removed.
* JavaScriptCore.vcproj/JavaScriptCore.resources: Removed.
* JavaScriptCore.vcproj/JavaScriptCore.resources/Info.plist: Removed.
* JavaScriptCore.vcproj/JavaScriptCore.sln: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCF.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreDebug.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreDebugAll.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreDebugCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.make: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.vcproj: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedCommon.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedDebug.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedDebugAll.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedDebugCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedProduction.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedRelease.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedReleaseCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedReleasePGO.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePGOOptimize.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePostBuild.cmd: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePreBuild.cmd: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePreLink.cmd: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreProduction.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreRelease.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreReleaseCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreReleasePGO.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreReleasePGOOptimize.vsprops: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/build-generated-files.sh: Removed.
* JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd: Removed.
* JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Removed.
* JavaScriptCore.vcproj/LLIntAssembly: Removed.
* JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.make: Removed.
* JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Removed.
* JavaScriptCore.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Removed.
* JavaScriptCore.vcproj/LLIntDesiredOffsets: Removed.
* JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed.
* JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Removed.
* JavaScriptCore.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Removed.
* JavaScriptCore.vcproj/LLIntOffsetsExtractor: Removed.
* JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Removed.
* JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Removed.
* JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Removed.
* JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugAll.vsprops: Removed.
* JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.vsprops: Removed.
* JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Removed.
* JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleaseCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleasePGO.vsprops: Removed.
* JavaScriptCore.vcproj/jsc: Removed.
* JavaScriptCore.vcproj/jsc/jsc.vcproj: Removed.
* JavaScriptCore.vcproj/jsc/jscCommon.vsprops: Removed.
* JavaScriptCore.vcproj/jsc/jscDebug.vsprops: Removed.
* JavaScriptCore.vcproj/jsc/jscDebugAll.vsprops: Removed.
* JavaScriptCore.vcproj/jsc/jscDebugCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/jsc/jscPostBuild.cmd: Removed.
* JavaScriptCore.vcproj/jsc/jscPreBuild.cmd: Removed.
* JavaScriptCore.vcproj/jsc/jscPreLink.cmd: Removed.
* JavaScriptCore.vcproj/jsc/jscProduction.vsprops: Removed.
* JavaScriptCore.vcproj/jsc/jscRelease.vsprops: Removed.
* JavaScriptCore.vcproj/jsc/jscReleaseCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/jsc/jscReleasePGO.vsprops: Removed.
* JavaScriptCore.vcproj/testRegExp: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExp.vcproj: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpCommon.vsprops: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpDebug.vsprops: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpDebugAll.vsprops: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpDebugCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpPostBuild.cmd: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpPreBuild.cmd: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpPreLink.cmd: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpProduction.vsprops: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpRelease.vsprops: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpReleaseCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/testRegExp/testRegExpReleasePGO.vsprops: Removed.
* JavaScriptCore.vcproj/testapi: Removed.
* JavaScriptCore.vcproj/testapi/testapi.vcproj: Removed.
* JavaScriptCore.vcproj/testapi/testapiCommon.vsprops: Removed.
* JavaScriptCore.vcproj/testapi/testapiDebug.vsprops: Removed.
* JavaScriptCore.vcproj/testapi/testapiDebugAll.vsprops: Removed.
* JavaScriptCore.vcproj/testapi/testapiDebugCairoCFLite.vsprops: Removed.
* JavaScriptCore.vcproj/testapi/testapiPostBuild.cmd: Removed.
* JavaScriptCore.vcproj/testapi/testapiPreBuild.cmd: Removed.
* JavaScriptCore.vcproj/testapi/testapiPreLink.cmd: Removed.
* JavaScriptCore.vcproj/testapi/testapiProduction.vsprops: Removed.
* JavaScriptCore.vcproj/testapi/testapiRelease.vsprops: Removed.
* JavaScriptCore.vcproj/testapi/testapiReleaseCairoCFLite.vsprops: Removed.
2013-05-31 Filip Pizlo <fpizlo@apple.com>
Incorrect assertion in DFG::Graph::uncheckedActivationRegisterFor()
<rdar://problem/13989324>
Rubber stamped by Mark Hahnenberg.
This has a bogus assertion that checks that the passed CodeOrigin doesn't have
an inline call frame. This was well intentioned in the sense that it is true
that inlined call frames wouldn't have an activation register. But that doesn't
mean that people won't ask. Removing the assertion fixes a debug-only crash and
has no impact on production code. This change adds a comment to that effect.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::uncheckedActivationRegisterFor):
2013-05-31 Julien Brianceau <jbrianceau@nds.com>
[sh4] Fix Overflow case of branchMul32 in baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=117057
Reviewed by Oliver Hunt.
Current implementation of Overflow case in branchMul32 performs an
unsigned multiplication whereas a signed multiplication is expected.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::branchMul32):
2013-05-31 Julien Brianceau <jbrianceau@nds.com>
[sh4] Fix floating point comparisons in baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=117066.
Reviewed by Oliver Hunt.
Current implementation of branchDouble function in baseline JIT is wrong
for some conditions and overkill for others. For instance:
- With DoubleGreaterThanOrEqual condition, branch will be taken if either
operand is NaN with current implementation whereras it should not.
- With DoubleNotEqualOrUnordered condition, performed NaN checks are
useless (because comparison result is false if either operand is NaN).
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::branchDouble):
2013-05-31 Julien Brianceau <jbrianceau@nds.com>
[sh4] Fix double floating point transfer in baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=117054
Reviewed by Oliver Hunt.
In current implementation, dmovRegReg function transfers only one single
FPRegister as PR=1 and SZ=0 in floating point status/control register.
Double transfers must be performed with two fmov.s opcodes.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::moveDouble):
(JSC::MacroAssemblerSH4::addDouble): Handle (op2==dest) case properly.
(JSC::MacroAssemblerSH4::sqrtDouble):
* assembler/SH4Assembler.h:
(JSC::SH4Assembler::fmovsRegReg):
2013-05-31 Julien Brianceau <jbrianceau@nds.com>
[sh4] Handle branchType properly in branchTruncateDoubleToInt32.
https://bugs.webkit.org/show_bug.cgi?id=117062
Reviewed by Oliver Hunt.
Current implementation of branchTruncateDoubleToInt32 is incorrect
when branchType == BranchIfTruncateSuccessful in sh4 baseline JIT.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::branchTruncateDoubleToInt32):
2013-05-31 Brent Fulgham <bfulgham@apple.com>
[Windows] Unreviewed build fix for VS2005 builders.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Add
missing export for WTF::SHA1::computeHexDigest
2013-05-30 David Farler <dfarler@apple.com>
Fix jscore-test when not using --sdk option with jsDriver.pl
https://bugs.webkit.org/show_bug.cgi?id=116339
Reviewed by Joe Pecoraro.
* tests/mozilla/jsDriver.pl:
(execute_tests):
With each test, the shell_command needs to be started from scratch.
This fix will clear the shell_command and start over as before with
the opt_arch option when not using --sdk with jsDriver.pl.
2013-05-30 Roger Fong <roger_fong@apple.com>
Get rid of JavaScript exports file on AppleWin port.
https://bugs.webkit.org/show_bug.cgi?id=117050.
Reviewed by Darin Adler.
Delete the JavaScriptCoreExportGenerator folder and remove dependencies.
Start linking in WTF.lib now that it's a shared library.
* JavaScriptCore.vcxproj/JavaScriptCore.submit.sln:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorBuildCmd.cmd: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorDebug.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPreBuild.cmd: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorProduction.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: Removed.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/make-export-file-generator: Removed.
* JavaScriptCore.vcxproj/jsc/jscCommon.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
* JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters:
* JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
* JavaScriptCore.vcxproj/testapi/testapiCommon.props:
2013-05-22 David Farler <dfarler@apple.com>
Add --sdk option to jsDriver.pl to run with iOS Simulator
https://bugs.webkit.org/show_bug.cgi?id=116339
Reviewed by David Kilzer.
* tests/mozilla/jsDriver.pl:
(execute_tests):
Prefix shell command with the path to the "sim" tool.
(parse_args):
Add -d / --sdk option.
(usage):
Help message for -d / --sdk option.
2013-05-30 Julien Brianceau <jbrianceau@nds.com>
[sh4] Optimize NaN checks in LLINT for floating point comparisons.
https://bugs.webkit.org/show_bug.cgi?id=117049
Reviewed by Oliver Hunt.
Use the fcmp/eq opcode in sh4 LLINT to test if a double is NaN.
This is more efficient, doesn't require two tmp registers and requires
less code than current implementation (which converts double to float,
then checks 'E = Emax + 1' and 'f != 0').
* offlineasm/sh4.rb:
2013-05-30 Oliver Hunt <oliver@apple.com>
JSCallbackObject does not correctly initialise the PropertySlot for getOwnPropertyDescriptor
https://bugs.webkit.org/show_bug.cgi?id=117053
Reviewed by Mark Hahnenberg.
Set appropriate thisValue on the PropertySlot
* API/JSCallbackObjectFunctions.h:
(JSC::::getOwnPropertyDescriptor):
* API/tests/testapi.mm:
2013-05-29 Jeffrey Pfau <jpfau@apple.com>
[Mac] Enable cache partitioning and the public suffix list on 10.8
<rdar://problem/13679019>
Rubber-stamped by David Kilzer.
* Configurations/FeatureDefines.xcconfig:
2013-05-28 Brent Fulgham <bfulgham@apple.com>
[Windows] Put correct byteCompile symbol in file. Previous version
had an extra 'i' appended to the end.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
2013-05-28 Brent Fulgham <bfulgham@apple.com>
[Windows] Unreviewed build fix. Remove ?byteCompile symbol that
is no longer accessible during link.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
2013-05-28 Gavin Barraclough <barraclough@apple.com>
String(new Date(2010,10,1)) is wrong in KRAT, YAKT
https://bugs.webkit.org/show_bug.cgi?id=106750
Reviewed by Darin Adler.
* runtime/JSDateMath.cpp:
(JSC::msToGregorianDateTime):
- Additional review comment fix.
2013-05-28 Brent Fulgham <bfulgham@apple.com>
[Windows] Unreviewed build fix after r150833
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
A CR/LF combination was lost in the file, combining two symbols.
2013-05-27 Gavin Barraclough <barraclough@apple.com>
String(new Date(2010,10,1)) is wrong in KRAT, YAKT
https://bugs.webkit.org/show_bug.cgi?id=106750
Reviewed by Darin Adler.
First part of a fix, simplfy date handling code, instead of operating separately
on the UTC-standard and standard-DST offsets, just generate a combined UTC-local
offset (this is what we actually need, and what the OS gives us).
* runtime/JSDateMath.cpp:
(JSC::getLocalTimeOffset):
- removed getUTCOffset, converted getDSTOffset -> getLocalTimeOffset
(JSC::gregorianDateTimeToMS):
(JSC::msToGregorianDateTime):
(JSC::parseDateFromNullTerminatedCharacters):
- call getLocalTimeOffset instead of getUTCOffset/getDSTOffset
* runtime/JSGlobalData.cpp:
(JSC::JSGlobalData::resetDateCache):
- removed cachedUTCOffset, converted DSTOffsetCache -> LocalTimeOffsetCache
* runtime/JSGlobalData.h:
(JSC::LocalTimeOffsetCache::LocalTimeOffsetCache):
(JSC::LocalTimeOffsetCache::reset):
(LocalTimeOffsetCache):
- removed cachedUTCOffset, converted DSTOffsetCache -> LocalTimeOffsetCache
2013-05-28 Mark Hahnenberg <mhahnenberg@apple.com>
r150199 is very wrong
https://bugs.webkit.org/show_bug.cgi?id=116876
JSValue needs to protect its internal JSValueRef.
Reviewed by Darin Adler.
* API/JSValue.mm:
(-[JSValue initWithValue:inContext:]):
(-[JSValue dealloc]):
* API/tests/testapi.mm: Added a simple test to make sure that we protect the
underlying JavaScript value across garbage collections.
2013-05-27 Patrick Gansterer <paroga@webkit.org>
Use ICU_INCLUDE_DIRS in BlackBerry CMake files
https://bugs.webkit.org/show_bug.cgi?id=116210
Reviewed by Rob Buis.
Set and use the ICU_INCLUDE_DIRS variable to avoid
duplicated adding of the ICU include directory.
* PlatformBlackBerry.cmake:
2013-05-27 Gabor Rapcsanyi <rgabor@webkit.org>
MacroAssemblerARM should use xor to swap registers instead of move
https://bugs.webkit.org/show_bug.cgi?id=116306
Reviewed by Zoltan Herczeg.
Change register swapping to xor from move and this way we don't need
temporary register anymore.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::swap):
2013-05-25 Filip Pizlo <fpizlo@apple.com>
We broke (-2^31/-1)|0 in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116767
Reviewed by Andreas Kling.
The bug is that we were assuming that in the -2^31 case, we already had -2^31
in the result register. This was a wrong assumption.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIntegerArithDivForX86):
2013-05-24 Filip Pizlo <fpizlo@apple.com>
We broke !(0/0)
https://bugs.webkit.org/show_bug.cgi?id=116736
Reviewed by Gavin Barraclough.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createLogicalNot):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::pureToBoolean):
2013-05-24 Julien Brianceau <jbrianceau@nds.com>
[sh4] Optimize LLINT generated code and fix few bugs in baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=116716
Reviewed by Geoffrey Garen.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::mul32): Cosmetic changes.
(JSC::MacroAssemblerSH4::convertInt32ToDouble): Absolute address was not dereferenced.
(JSC::MacroAssemblerSH4::branch32): Absolute address was not dereferenced.
(JSC::MacroAssemblerSH4::revertJumpReplacementToBranchPtrWithPatch): Use all 32 bits of pointer for revertJump call.
* assembler/SH4Assembler.h:
(JSC::SH4Assembler::revertJump): Use changePCrelativeAddress to patch the whole pointer.
(JSC::SH4Assembler::linkJump): Cosmetic change.
* offlineasm/sh4.rb: Optimize LLINT generated code.
2013-05-23 Peter Wang <peter.wang@torchmobile.com.cn>
CLoop llint backend should not use the d8 register as scratch register
https://bugs.webkit.org/show_bug.cgi?id=116019
Reviewed by Csaba Osztrogonác.
* offlineasm/cloop.rb:
2013-05-22 Peter Wang <peter.wang@torchmobile.com.cn>
Use uninitialized register in "JIT::emit_op_neq_null" and "emit_op_eq_null"
https://bugs.webkit.org/show_bug.cgi?id=116593
Reviewed by Filip Pizlo.
Generated instructions using uninitialized register. It's caused by a mistake of r126494.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
2013-05-22 Filip Pizlo <fpizlo@apple.com>
Fix indentation of CodeBlock.h
Rubber stampted by Mark Hahnenberg.
* bytecode/CodeBlock.h:
2013-05-22 Julien Brianceau <jbrianceau@nds.com>
[sh4] Remove MacroAssemblerSH4.cpp file.
https://bugs.webkit.org/show_bug.cgi?id=116596.
Reviewed by Geoffrey Garen.
Move linkCall and repatchCall implementations from MacroAssemblerSH4.cpp
to MacroAssemblerSH4.h and remove MacroAssemblerSH4.cpp, as it is done
for other architectures.
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* assembler/MacroAssemblerSH4.cpp: Removed.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::linkCall):
(MacroAssemblerSH4):
(JSC::MacroAssemblerSH4::repatchCall):
2013-05-21 Brent Fulgham <bfulgham@apple.com>
[Windows] Unreviewed speculative fix for test-bots.
Add export declaration for WTFInvokeCrashHook to avoid runtime
load error on test bots.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
2013-05-21 Mark Lam <mark.lam@apple.com>
Added missing assert condition for PositiveOrZero in ARM branch32().
https://bugs.webkit.org/show_bug.cgi?id=116538.
Reviewed by Geoffrey Garen.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::branchAdd32):
2013-05-20 Mark Hahnenberg <mhahnenberg@apple.com>
Disable SuperRegion
https://bugs.webkit.org/show_bug.cgi?id=116362
Rubber stamped by Geoff Garen.
* heap/Region.h:
2013-05-20 Oliver Hunt <oliver@apple.com>
Make C API more robust against null contexts
https://bugs.webkit.org/show_bug.cgi?id=116462
Reviewed by Anders Carlsson.
Handle null contexts in a non-crashy way. It's a bug to ever call the
API with a null context, and the absence of a context means we can't
produce a meaningful result, so we still assert in debug builds.
Now where possible we detect and early return, returning null for any
pointer type, NaN for doubles, and false for any boolean result.
* API/JSBase.cpp:
(JSEvaluateScript):
(JSCheckScriptSyntax):
(JSReportExtraMemoryCost):
* API/JSContextRef.cpp:
(JSContextGetGlobalObject):
(JSContextGetGroup):
(JSContextGetGlobalContext):
(JSContextCreateBacktrace):
* API/JSObjectRef.cpp:
(JSObjectMake):
(JSObjectMakeFunctionWithCallback):
(JSObjectMakeConstructor):
(JSObjectMakeFunction):
(JSObjectMakeArray):
(JSObjectMakeDate):
(JSObjectMakeError):
(JSObjectMakeRegExp):
(JSObjectGetPrototype):
(JSObjectSetPrototype):
(JSObjectHasProperty):
(JSObjectGetProperty):
(JSObjectSetProperty):
(JSObjectGetPropertyAtIndex):
(JSObjectSetPropertyAtIndex):
(JSObjectDeleteProperty):
(JSObjectCopyPropertyNames):
* API/JSValueRef.cpp:
(JSValueGetType):
(JSValueIsUndefined):
(JSValueIsNull):
(JSValueIsBoolean):
(JSValueIsNumber):
(JSValueIsString):
(JSValueIsObject):
(JSValueIsObjectOfClass):
(JSValueIsEqual):
(JSValueIsStrictEqual):
(JSValueIsInstanceOfConstructor):
(JSValueMakeUndefined):
(JSValueMakeNull):
(JSValueMakeBoolean):
(JSValueMakeNumber):
(JSValueMakeString):
(JSValueMakeFromJSONString):
(JSValueCreateJSONString):
(JSValueToBoolean):
(JSValueToNumber):
(JSValueToStringCopy):
(JSValueToObject):
(JSValueProtect):
* API/JSWeakObjectMapRefPrivate.cpp:
2013-05-20 David Kilzer <ddkilzer@apple.com>
Synchronize FeatureDefines.xcconfig
* Configurations/FeatureDefines.xcconfig: Remove
ENABLE_LINK_PRERENDER. This was missed in r150356.
2013-05-19 Anders Carlsson <andersca@apple.com>
Remove link prerendering code
https://bugs.webkit.org/show_bug.cgi?id=116415
Reviewed by Darin Adler.
This code was only used by Chromium and is dead now.
* Configurations/FeatureDefines.xcconfig:
2013-05-18 Patrick Gansterer <paroga@webkit.org>
[CMake] Replace *_LIBRARY_NAME with *_OUTPUT_NAME
https://bugs.webkit.org/show_bug.cgi?id=114554
Reviewed by Gyuyoung Kim.
Using variables as target names is very uncommon in CMake.
The usual way to specify the name of the resulting binary
is to set the OUTPUT_NAME target property.
* CMakeLists.txt:
* shell/CMakeLists.txt:
2013-05-17 Patrick Gansterer <paroga@webkit.org>
[CMake] Remove invalid include paths
https://bugs.webkit.org/show_bug.cgi?id=116213
Reviewed by Gyuyoung Kim.
Since "${JAVASCRIPTCORE_DIR}/wtf" does not exist, it is safe
to remove them from the list of include directories.
* PlatformEfl.cmake: Removed.
* PlatformGTK.cmake: Removed.
2013-05-16 Patrick Gansterer <paroga@webkit.org>
Consolidate lists in JavaScriptCore CMake files
https://bugs.webkit.org/show_bug.cgi?id=115992
Reviewed by Gyuyoung Kim.
Move common files into the CMakeLists.txt to avoid duplicating the list of files.
Also rebase the recently added GTK files to match the other CMake ports, since
the submitted patch was based on an older version of the source tree.
* CMakeLists.txt:
* PlatformEfl.cmake:
* PlatformGTK.cmake:
* shell/CMakeLists.txt:
* shell/PlatformEfl.cmake:
* shell/PlatformGTK.cmake:
2013-05-16 Geoffrey Garen <ggaren@apple.com>
JSValue shouldn't protect/unprotect its context
https://bugs.webkit.org/show_bug.cgi?id=116234
Reviewed by Mark Hahnenberg.
Our retain on _context is sufficient.
* API/JSValue.mm:
(-[JSValue initWithValue:inContext:]):
(-[JSValue dealloc]):
2013-05-15 Ryosuke Niwa <rniwa@webkit.org>
Another Windows build fix attempt after r150160.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
2013-05-15 Oliver Hunt <oliver@apple.com>
RefCountedArray needs to use vector initialisers for its backing store
https://bugs.webkit.org/show_bug.cgi?id=116194
Reviewed by Gavin Barraclough.
Use an out of line function to clear the exception stack to avoid
needing to include otherwise unnecessary headers all over the place.
Everything else is just being updated to use that.
* bytecompiler/BytecodeGenerator.cpp:
* interpreter/CallFrame.h:
(JSC::ExecState::clearSupplementaryExceptionInfo):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::addStackTraceIfNecessary):
(JSC::Interpreter::throwException):
* runtime/JSGlobalObject.cpp:
(JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope):
* runtime/JSGlobalData.cpp:
(JSC):
(JSC::JSGlobalData::clearExceptionStack):
* runtime/JSGlobalData.h:
(JSGlobalData):
(JSC::JSGlobalData::exceptionStack):
2013-05-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r150051.
http://trac.webkit.org/changeset/150051
https://bugs.webkit.org/show_bug.cgi?id=116186
Broke all JSC tests on Mac and the author is unresponsive
(Requested by rniwa on #webkit).
* JavaScriptCore.xcodeproj/project.pbxproj:
2013-05-15 Julien Brianceau <jbrianceau@nds.com>
Remove savedTimeoutReg from JITStackFrame for sh4 base JIT.
https://bugs.webkit.org/show_bug.cgi?id=116143
Reviewed by Geoffrey Garen.
Since r148119, timeoutCheckRegister is removed from baseline JIT.
So we don't need to save r8 register in JITStackFrame anymore for sh4.
* jit/JITStubs.cpp:
* jit/JITStubs.h:
(JITStackFrame):
2013-05-15 Nico Weber <thakis@chromium.org>
WebKit doesn't support MSVS2003 any more, remove preprocessor checks for older versions.
https://bugs.webkit.org/show_bug.cgi?id=116157
Reviewed by Anders Carlsson.
Also remove a gcc3.2 workaround.
Merges parts of these two commits by the talented Nico Weber:
https://chromium.googlesource.com/chromium/blink/+/3677e2f47348daeff405a40b6f90fbdf0654c2f5
https://chromium.googlesource.com/chromium/blink/+/0fcd96c448dc30be1416dcc15713c53710c1a312
* os-win32/inttypes.h:
2013-05-13 Alvaro Lopez Ortega <alvaro@alobbs.com>
Nightly build's jsc doesn't work without DYLD_FRAMEWORK...
https://bugs.webkit.org/show_bug.cgi?id=79065
Reviewed by Darin Adler.
Fixes the build process so the depencencies of the jsc binary are
modified before its copied to its target directory. In this way
jsc should always use relative reference to the JavaScriptCore
libraries.
* JavaScriptCore.xcodeproj/project.pbxproj: Fixes the commands in
the "Copy Into Framework" target.
2013-05-13 Mark Hahnenberg <mhahnenberg@apple.com>
Objective-C API: scanExternalObjectGraph should not create new JSVirtualMachine wrappers
https://bugs.webkit.org/show_bug.cgi?id=116074
If scanExternalObjectGraph creates a new JSVirtualMachine wrapper during collection, when the
scanExternalObjectGraph call finishes and the autorelease pool is drained we will dealloc the
JSVirtualMachine which will cause us to try to take the API lock for the corresponding JSGlobalData.
If this happens on a GC thread other than the "main" thread, we will deadlock. The solution
is to just check the JSGlobalData cache, and if there is no JSVirtualMachine wrapper, return early.
Reviewed by Darin Adler.
* API/JSVirtualMachine.mm:
(scanExternalObjectGraph):
2013-05-13 Benjamin Poulain <benjamin@webkit.org>
Improve stringProtoFuncLastIndexOf for the prefix case
https://bugs.webkit.org/show_bug.cgi?id=115952
Reviewed by Geoffrey Garen.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncLastIndexOf):
Use the optimized string search when possible.
On Joseph Pecoraro's tests, this gives a ~30% speed improvement.
2013-05-13 Zalan Bujtas <zalan@apple.com>
WebProcess consuming very high CPU on linkedin.com
https://bugs.webkit.org/show_bug.cgi?id=115601
Reviewed by Andreas Kling.
Disable WEB_TIMING_MINIMAL.
Turn off window.performance and performance.now(). Some JS frameworks expect
additional Web Timing APIs, when performance.now() is available.
* Configurations/FeatureDefines.xcconfig:
2013-05-12 Anders Carlsson <andersca@apple.com>
Stop including UnusedParam.h
https://bugs.webkit.org/show_bug.cgi?id=116003
Reviewed by Sam Weinig.
UnusedParam.h is empty now so there's no need to include it anymore.
* API/APICast.h:
* API/tests/JSNode.c:
* API/tests/JSNodeList.c:
* API/tests/minidom.c:
* API/tests/testapi.c:
* assembler/AbstractMacroAssembler.h:
* assembler/MacroAssemblerCodeRef.h:
* bytecode/CodeBlock.cpp:
* heap/HandleStack.h:
* interpreter/JSStackInlines.h:
* jit/CompactJITCodeMap.h:
* jit/ExecutableAllocator.h:
* parser/SourceProvider.h:
* runtime/DatePrototype.cpp:
* runtime/JSNotAnObject.cpp:
* runtime/JSSegmentedVariableObject.h:
* runtime/JSVariableObject.h:
* runtime/Options.cpp:
* runtime/PropertyOffset.h:
2013-05-11 Martin Robinson <mrobinson@igalia.com>
[GTK] Add a basic cmake build for WTF and JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=115967
Reviewed by Laszlo Gombos.
* PlatformGTK.cmake: Added.
* shell/PlatformGTK.cmake: Added.
2013-05-10 Laszlo Gombos <l.gombos@samsung.com>
Remove USE(OS_RANDOMNESS)
https://bugs.webkit.org/show_bug.cgi?id=108095
Reviewed by Darin Adler.
Remove the USE(OS_RANDOMNESS) guard as it is turned on for all
ports.
* jit/JIT.cpp:
(JSC::JIT::JIT):
2013-05-10 Mark Hahnenberg <mhahnenberg@apple.com>
Rename StructureCheckHoistingPhase to TypeCheckHoistingPhase
https://bugs.webkit.org/show_bug.cgi?id=115938
We're going to add some more types of check hoisting soon, so let's have the right name here.
Rubber stamped by Filip Pizlo.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGStructureCheckHoistingPhase.cpp: Removed.
* dfg/DFGStructureCheckHoistingPhase.h: Removed.
* dfg/DFGTypeCheckHoistingPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGStructureCheckHoistingPhase.cpp.
(JSC::DFG::TypeCheckHoistingPhase::TypeCheckHoistingPhase):
(JSC::DFG::performTypeCheckHoisting):
* dfg/DFGTypeCheckHoistingPhase.h: Copied from Source/JavaScriptCore/dfg/DFGStructureCheckHoistingPhase.h.
2013-05-09 Christophe Dumez <ch.dumez@sisa.samsung.com>
Unreviewed build fix after r149836.
It broke at least EFL and GTK builds. Move new static members initialization
outside the class. Those need to have a definition outside the class because
their address is used (e.g. CodeCacheMap::nonGlobalWorkingSetMaxEntries).
* runtime/CodeCache.cpp:
(JSC):
* runtime/CodeCache.h:
(CodeCacheMap):
2013-05-08 Oliver Hunt <oliver@apple.com>
Code cache stores bogus var references for functions in eval code
https://bugs.webkit.org/show_bug.cgi?id=115747
Reviewed by Mark Hahnenberg.
Non-global eval now uses a per-CodeBlock cache, and only use it
when we're at the top of a function's scope. This means that we
will no longer cache the parsing of a single string across
multiple functions, and we won't cache when we're nested inside
constructs like |with| and |catch| where previously we would, which
is good because caching in those cases is unsound.
* bytecode/EvalCodeCache.h:
(JSC):
(JSC::EvalCodeCache::getSlow):
(JSC::EvalCodeCache::get):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::codeCacheForEval):
(UnlinkedCodeBlock):
(RareData):
* debugger/Debugger.cpp:
(JSC::evaluateInGlobalCallFrame):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluate):
* interpreter/Interpreter.cpp:
(JSC::eval):
* runtime/CodeCache.cpp:
(JSC::CodeCache::CodeCache):
(JSC::CodeCache::generateBytecode):
(JSC):
(JSC::CodeCache::getCodeBlock):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::CodeCacheMap):
(CodeCacheMap):
(JSC::CodeCacheMap::canPruneQuickly):
(JSC::CodeCacheMap::prune):
(JSC::CodeCache::create):
(CodeCache):
* runtime/Executable.cpp:
(JSC::EvalExecutable::EvalExecutable):
(JSC::EvalExecutable::compileInternal):
* runtime/Executable.h:
(JSC::EvalExecutable::create):
(EvalExecutable):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createEvalCodeBlock):
* runtime/JSGlobalObject.h:
(JSGlobalObject):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* runtime/JSGlobalData.cpp:
(JSC::JSGlobalData::JSGlobalData):
* runtime/JSGlobalData.h:
(JSGlobalData):
2013-05-08 Mark Hahnenberg <mhahnenberg@apple.com>
DFGArrayMode::fromObserved is too liberal when it sees different Array and NonArray shapes
https://bugs.webkit.org/show_bug.cgi?id=115805
Reviewed by Geoffrey Garen.
It checks the observed ArrayModes to see if we have seen any ArrayWith* first. If so, it assumes it's
an Array::Array, even if we've also observed any NonArrayWith* in the ArrayProfile. This leads to the
code generated by jumpSlowForUnwantedArrayMode to check the indexing type against (shape | IsArray)
instead of just shape, which can cause us to exit a lot in the case that we saw a NonArray.
To fix this we need to add a case that checks for both ArrayWith* and NonArrayWith* cases first, which
should then use Array::PossiblyArray, then do the checks we were already doing.
* bytecode/ArrayProfile.h:
(JSC::hasSeenArray):
(JSC::hasSeenNonArray):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::fromObserved):
2013-05-09 Joe Mason <jmason@blackberry.com>
[BlackBerry] Set up logging buffer on start of jsc executable
https://bugs.webkit.org/show_bug.cgi?id=114688
Reviewed by Rob Buis.
Internal PR: 322715
Internally Reviewed By: Jeff Rogers
* jsc.cpp:
(main): call BB::Platform::setupApplicationLogging
2013-05-08 Michael Saboff <msaboff@apple.com>
JSC: There should be a disassembler for ARM Thumb 2
https://bugs.webkit.org/show_bug.cgi?id=115827
Reviewed by Filip Pizlo.
Added a new disassembler for ARMv7 Thumb2 instructions for use by the JSC debugging
and profiling code. The opcode coverage is currently not complete. It covers all
of the integer instructions JSC currently emits, but only a limited number of
floating point opcodes. Currently that is just the 64 bit vmov and vmsr instructions.
The disassembler is structured as a base opcode class ARMv7DOpcode with sub-classes
for each instruction group. There is a public format method that does the bulk of
the disassembly work. There are two broad sub-classes, ARMv7D16BitOpcode and
ARMv7D32BitOpcode, for the 16 bit and 32 bit opcodes. There are sub-classes under
those two classes for individual and related groups of opcodes. Instructions are
"dispatched" to the right subclass via two arrays of linked lists in the inner classes
OpcodeGroup. There is one such inner class for each ARMv7D16BitOpcode and ARMv7D32BitOpcode.
Each OpcodeGroup has a mask and a pattern that it applies to the instruction to determine
that it matches a particular group. OpcodeGroup uses a static method to reinterpret_cast
the Opcode object to the right base class for the instruction group for formatting.
The cast eliminates the need of allocating an object for each decoded instruction.
Unknown instructions are formatted as ".word 1234" or ".long 12345678" depending whether
the instruction is 16 or 32 bit.
* JavaScriptCore.xcodeproj/project.pbxproj:
* disassembler/ARMv7: Added.
* disassembler/ARMv7/ARMv7DOpcode.cpp: Added.
(ARMv7Disassembler):
(OpcodeGroupInitializer):
(JSC::ARMv7Disassembler::ARMv7DOpcode::init):
(JSC::ARMv7Disassembler::ARMv7DOpcode::startITBlock):
(JSC::ARMv7Disassembler::ARMv7DOpcode::saveITConditionAt):
(JSC::ARMv7Disassembler::ARMv7DOpcode::fetchOpcode):
(JSC::ARMv7Disassembler::ARMv7DOpcode::disassemble):
(JSC::ARMv7Disassembler::ARMv7DOpcode::bufferPrintf):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendInstructionName):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendRegisterName):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendRegisterList):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendFPRegisterName):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::init):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::doDisassemble):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::defaultFormat):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddRegisterT2::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSPPlusImmediate::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchConditionalT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchExchangeT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchT2::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeCompareImmediateT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT2::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeGeneratePCRelativeAddress::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadFromLiteralPool::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscBreakpointT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscByteHalfwordOps::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscHint16::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscIfThenT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMoveImmediateT1::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMoveRegisterT1::format):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::init):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::doDisassemble):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::defaultFormat):
(JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::appendModifiedImmediate):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::appendImmShift):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::appendFPRegister):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegShift::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegParallel::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegMisc::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadRegister::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadUnsignedImmediate::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataPushPopSingle::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate12::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleRegister::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::format):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMSR::format):
* disassembler/ARMv7/ARMv7DOpcode.h: Added.
(ARMv7Disassembler):
(ARMv7DOpcode):
(JSC::ARMv7Disassembler::ARMv7DOpcode::ARMv7DOpcode):
(JSC::ARMv7Disassembler::ARMv7DOpcode::is32BitInstruction):
(JSC::ARMv7Disassembler::ARMv7DOpcode::isFPInstruction):
(JSC::ARMv7Disassembler::ARMv7DOpcode::conditionName):
(JSC::ARMv7Disassembler::ARMv7DOpcode::shiftName):
(JSC::ARMv7Disassembler::ARMv7DOpcode::inITBlock):
(JSC::ARMv7Disassembler::ARMv7DOpcode::startingITBlock):
(JSC::ARMv7Disassembler::ARMv7DOpcode::endITBlock):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendInstructionNameNoITBlock):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendSeparator):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendCharacter):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendString):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendShiftType):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendSignedImmediate):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendUnsignedImmediate):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendPCRelativeOffset):
(JSC::ARMv7Disassembler::ARMv7DOpcode::appendShiftAmount):
(ARMv7D16BitOpcode):
(OpcodeGroup):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::OpcodeGroup):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::setNext):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::next):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::matches):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::format):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::rm):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::rd):
(JSC::ARMv7Disassembler::ARMv7D16BitOpcode::opcodeGroupNumber):
(ARMv7DOpcodeAddRegisterT2):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddRegisterT2::rdn):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddRegisterT2::rm):
(ARMv7DOpcodeAddSPPlusImmediate):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSPPlusImmediate::rd):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSPPlusImmediate::immediate8):
(ARMv7DOpcodeAddSubtract):
(ARMv7DOpcodeAddSubtractT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::rm):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::rn):
(ARMv7DOpcodeAddSubtractImmediate3):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::immediate3):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::rn):
(ARMv7DOpcodeAddSubtractImmediate8):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::rdn):
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::immediate8):
(ARMv7DOpcodeBranchConditionalT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchConditionalT1::condition):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchConditionalT1::offset):
(ARMv7DOpcodeBranchExchangeT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchExchangeT1::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchExchangeT1::rm):
(ARMv7DOpcodeBranchT2):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchT2::immediate11):
(ARMv7DOpcodeCompareImmediateT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeCompareImmediateT1::rn):
(JSC::ARMv7Disassembler::ARMv7DOpcodeCompareImmediateT1::immediate8):
(ARMv7DOpcodeCompareRegisterT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT1::rn):
(ARMv7DOpcodeCompareRegisterT2):
(JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT2::rn):
(JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT2::rm):
(ARMv7DOpcodeDataProcessingRegisterT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::rm):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::rdn):
(ARMv7DOpcodeGeneratePCRelativeAddress):
(JSC::ARMv7Disassembler::ARMv7DOpcodeGeneratePCRelativeAddress::rd):
(JSC::ARMv7Disassembler::ARMv7DOpcodeGeneratePCRelativeAddress::immediate8):
(ARMv7DOpcodeLoadFromLiteralPool):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadFromLiteralPool::rt):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadFromLiteralPool::immediate8):
(ARMv7DOpcodeLoadStoreRegisterImmediate):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::immediate5):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::rn):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::rt):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale):
(ARMv7DOpcodeLoadStoreRegisterImmediateWordAndByte):
(ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord):
(ARMv7DOpcodeLoadStoreRegisterOffsetT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::opB):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::rm):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::rn):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::rt):
(ARMv7DOpcodeLoadStoreRegisterSPRelative):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::rt):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::immediate8):
(ARMv7DOpcodeLogicalImmediateT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::immediate5):
(ARMv7DOpcodeMiscAddSubSP):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::immediate7):
(ARMv7DOpcodeMiscByteHalfwordOps):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscByteHalfwordOps::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscByteHalfwordOps::op):
(ARMv7DOpcodeMiscBreakpointT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscBreakpointT1::immediate8):
(ARMv7DOpcodeMiscCompareAndBranch):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::immediate6):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::rn):
(ARMv7DOpcodeMiscHint16):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscHint16::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscHint16::opA):
(ARMv7DOpcodeMiscIfThenT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscIfThenT1::firstCondition):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscIfThenT1::mask):
(ARMv7DOpcodeMiscPushPop):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::registerMask):
(ARMv7DOpcodeMoveImmediateT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMoveImmediateT1::rd):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMoveImmediateT1::immediate8):
(ARMv7DOpcodeMoveRegisterT1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMoveRegisterT1::rd):
(JSC::ARMv7Disassembler::ARMv7DOpcodeMoveRegisterT1::rm):
(ARMv7D32BitOpcode):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::OpcodeGroup):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::setNext):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::next):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::matches):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::format):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rd):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rm):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rn):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rt):
(JSC::ARMv7Disassembler::ARMv7D32BitOpcode::opcodeGroupNumber):
(ARMv7DOpcodeBranchRelative):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::sBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::j1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::j2):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::immediate11):
(ARMv7DOpcodeConditionalBranchT3):
(JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::offset):
(JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::condition):
(JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::immediate6):
(ARMv7DOpcodeBranchOrBranchLink):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::offset):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::immediate10):
(JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::isBL):
(ARMv7DOpcodeDataProcessingLogicalAndRithmetic):
(ARMv7DOpcodeDataProcessingModifiedImmediate):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::sBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::immediate12):
(ARMv7DOpcodeDataProcessingShiftedReg):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::sBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::immediate5):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::type):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::tbBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::tBit):
(ARMv7DOpcodeDataProcessingReg):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingReg::op1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingReg::op2):
(ARMv7DOpcodeDataProcessingRegShift):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegShift::opName):
(ARMv7DOpcodeDataProcessingRegExtend):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::opExtendName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::opExtendAndAddName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::rotate):
(ARMv7DOpcodeDataProcessingRegParallel):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegParallel::opName):
(ARMv7DOpcodeDataProcessingRegMisc):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegMisc::opName):
(ARMv7DOpcodeHint32):
(JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::isDebugHint):
(JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::debugOption):
(JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::op):
(ARMv7DOpcodeFPTransfer):
(JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opH):
(JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opL):
(JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::rt):
(JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opC):
(JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opB):
(JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::vd):
(JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::vn):
(ARMv7DOpcodeDataLoad):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataLoad::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataLoad::op):
(ARMv7DOpcodeLoadRegister):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadRegister::immediate2):
(ARMv7DOpcodeLoadSignedImmediate):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::pBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::uBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::wBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::immediate8):
(ARMv7DOpcodeLoadUnsignedImmediate):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadUnsignedImmediate::immediate12):
(ARMv7DOpcodeLongMultipleDivide):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::smlalOpName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::smlaldOpName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::smlsldOpName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::rdLo):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::rdHi):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::op1):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::op2):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::nBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::mBit):
(ARMv7DOpcodeDataPushPopSingle):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataPushPopSingle::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataPushPopSingle::op):
(ARMv7DOpcodeDataStoreSingle):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataStoreSingle::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeDataStoreSingle::op):
(ARMv7DOpcodeStoreSingleImmediate12):
(JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate12::immediate12):
(ARMv7DOpcodeStoreSingleImmediate8):
(JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::pBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::uBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::wBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::immediate8):
(ARMv7DOpcodeStoreSingleRegister):
(JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleRegister::immediate2):
(ARMv7DOpcodeUnmodifiedImmediate):
(JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::opName):
(JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::shBit):
(JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::bitNumOrSatImmediate):
(JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::immediate5):
(JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::immediate12):
(JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::immediate16):
(ARMv7DOpcodeVMOVDoublePrecision):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::rt2):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::rt):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::globalData):
(ARMv7DOpcodeVMOVSinglePrecision):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::op):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::rt2):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::rt):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::globalData):
(ARMv7DOpcodeVMSR):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMSR::opL):
(JSC::ARMv7Disassembler::ARMv7DOpcodeVMSR::rt):
* disassembler/ARMv7Disassembler.cpp: Added.
(JSC::tryToDisassemble):
2013-05-07 Julien Brianceau <jbrianceau@nds.com>
Take advantage of pre-decrement and post-increment opcodes for sh4 base JIT.
https://bugs.webkit.org/show_bug.cgi?id=115722
Reviewed by Oliver Hunt.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::load8PostInc):
(MacroAssemblerSH4):
(JSC::MacroAssemblerSH4::load16Unaligned):
(JSC::MacroAssemblerSH4::load16PostInc):
(JSC::MacroAssemblerSH4::storeDouble):
(JSC::MacroAssemblerSH4::load32WithUnalignedHalfWords):
* assembler/SH4Assembler.h:
(JSC::SH4Assembler::movwMemRegIn):
(SH4Assembler):
(JSC::SH4Assembler::movbMemRegIn):
(JSC::SH4Assembler::printInstr):
2013-05-07 Anders Carlsson <andersca@apple.com>
Remove AlwaysInline.h from WTF
https://bugs.webkit.org/show_bug.cgi?id=115727
Reviewed by Brent Fulgham.
The macro that used to be in AlwaysInline.h is now in Compiler.h so there's no reason
to keep AlwaysInline.h around anymore.
* jit/JSInterfaceJIT.h:
* parser/Lexer.h:
* runtime/JSCJSValue.h:
* runtime/SymbolTable.h:
2013-05-07 Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com>
HashTraits<RefPtr<P> >::PeekType should be raw pointer for better performance
https://bugs.webkit.org/show_bug.cgi?id=115646
Reviewed by Darin Adler.
* bytecompiler/StaticPropertyAnalyzer.h:
(JSC::StaticPropertyAnalyzer::putById):
Updated accordingly to new HashMap<.., RefPtr>::get() semantics.
2013-05-06 Julien Brianceau <jbrianceau@nds.com>
Misc bugfix and cleaning in sh4 base JIT.
https://bugs.webkit.org/show_bug.cgi?id=115627
Reviewed by Oliver Hunt.
Get rid of loadX(RegisterID r0, RegisterID src, RegisterID dest) functions.
Remove misplaced extuw() implementation from MacroAssemblerSH4.
Add movbRegMemr0 and movwRegMemr0 functions in SH4Assembler.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::add32): Skip operation when first operand is a zero immediate.
(JSC::MacroAssemblerSH4::sub32): Skip operation when first operand is a zero immediate.
(JSC::MacroAssemblerSH4::load32): Fix wrong usage of r0 register.
(JSC::MacroAssemblerSH4::load8Signed): Handle "base == r0" case.
(MacroAssemblerSH4):
(JSC::MacroAssemblerSH4::load16): Handle "base == r0" case.
(JSC::MacroAssemblerSH4::load16Unaligned): Use extuw() implementation from SH4Assembler.
(JSC::MacroAssemblerSH4::load16Signed): Cosmetic change.
(JSC::MacroAssemblerSH4::store8): Fix unhandled BaseIndex offset and handle (base == r0) case.
(JSC::MacroAssemblerSH4::store16): Fix unhandled BaseIndex offset and handle (base == r0) case.
(JSC::MacroAssemblerSH4::store32):
* assembler/SH4Assembler.h:
(JSC::SH4Assembler::movwRegMemr0):
(SH4Assembler):
(JSC::SH4Assembler::movbRegMemr0):
(JSC::SH4Assembler::placeConstantPoolBarrier): Cosmetic change.
(JSC::SH4Assembler::maxJumpReplacementSize):
(JSC::SH4Assembler::replaceWithJump): Correct branch range and save an opcode.
(JSC::SH4Assembler::printInstr):
2013-05-06 Anders Carlsson <andersca@apple.com>
Stop using WTF::deleteAllValues in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=115670
Reviewed by Oliver Hunt.
Change the Vectors used to Vectors of OwnPtrs instead.
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::~DFGCodeBlocks):
(JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
2013-05-06 Andras Becsi <andras.becsi@digia.com>
Build with GCC 4.8 fails because of -Wmaybe-uninitialized
https://bugs.webkit.org/show_bug.cgi?id=115648
Reviewed by Michael Saboff.
Initialize values in Options::setOption since from
there we end up calling OptionRange::init with
uninitialized members.
* runtime/Options.cpp:
2013-05-06 Gabor Rapcsanyi <rgabor@webkit.org>
JSC ARM traditional failing on Octane NavierStokes test
https://bugs.webkit.org/show_bug.cgi?id=115626
Reviewed by Zoltan Herczeg.
Change the ARM traditional assembler to use double precision on value
conversions.
* assembler/ARMAssembler.h:
2013-05-03 Michael Saboff <msaboff@apple.com>
There should be a runtime option to constrain what functions get DFG compiled
https://bugs.webkit.org/show_bug.cgi?id=115576
Reviewed by Mark Hahnenberg.
Added OptionRange to Options to allow checking that something is within an option
or not. The new OptionClass supports range strings in the form of [!]<low>[:<high>].
If only one value is given, then it will be used for both low and high. A leading
'!' inverts the check. If no range is given, then checking for a value within a range
will always return true. Added the option "bytecodeRangeToDFGCompile" that takes an
OptionRange string to select the bytecode range of code blocks to DFG compile.
* dfg/DFGDriver.cpp:
(JSC::DFG::compile): Added new check for bytecode count within bytecodeRangeToDFGCompile
range.
* runtime/Options.cpp:
(JSC::parse): Added overloaded parse() for OptionRange.
(JSC::OptionRange::init): Parse range string and then initialize the range.
(JSC::OptionRange::isInRange): Function used by consumer to check if a value is within
the specified range.
(JSC::Options::dumpOption): Added code to dump OptionRange options.
* runtime/Options.h:
(OptionRange): New class.
(JSC::OptionRange::operator= ): This is really used as a default ctor for use within
the Option static array initialization.
(JSC::OptionRange::rangeString): This is used for debug. It assumes that the char*
passed into OptionRange::init is valid when this function is called.
2013-05-02 Oliver Hunt <oliver@apple.com>
Fix potential bug in lookup logic
https://bugs.webkit.org/show_bug.cgi?id=115522
Reviewed by Mark Hahnenberg.
Though not a problem in practise, it is technically possible
to inject an un-proxied global object into the scope chain
via the C API. This change makes sure that the scope walk
in BytecodeGenerator actually limits itself to scopes that
are statically bindable.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::resolve):
* runtime/JSObject.h:
(JSObject):
(JSC):
(JSC::JSObject::isStaticScopeObject):
2013-05-01 Roger Fong <roger_fong@apple.com>
Set Path in makefile for AppleWin.
* JavaScriptCore.vcxproj/JavaScriptCore.make:
2013-05-01 Benjamin Poulain <benjamin@webkit.org>
Remove the remaining wscript
https://bugs.webkit.org/show_bug.cgi?id=115459
Reviewed by Andreas Kling.
* wscript: Removed.
2013-04-30 Mark Lam <mark.lam@apple.com>
JSContextGroupSetExecutionTimeLimit() should not pass a callback to the
JSGlobalData watchdog if its client did not pass one in.
https://bugs.webkit.org/show_bug.cgi?id=115461.
Reviewed by Geoffrey Garen.
* API/JSContextRef.cpp:
(internalScriptTimeoutCallback):
(JSContextGroupSetExecutionTimeLimit):
* API/tests/testapi.c:
(main):
- Added test case when the time limit callback is 0.
- Also updated a check to verify that a TerminatedExecutionException is
thrown when the time out is cancelled.
- Also fixed some cosmetic typos.
2013-04-30 Geoffrey Garen <ggaren@apple.com>
Removed op_ensure_property_exists
https://bugs.webkit.org/show_bug.cgi?id=115460
Reviewed by Mark Hahnenberg.
It was unused, and whatever it was once used for was not optimized.
* JavaScriptCore.order:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
* jit/JITOpcodes32_64.cpp:
* jit/JITStubs.cpp:
* jit/JITStubs.h:
* llint/LLIntSlowPaths.cpp:
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
2013-04-30 Oliver Hunt <oliver@apple.com>
JSC Stack walking logic craches in the face of inlined functions triggering JSGlobalData re-entry
https://bugs.webkit.org/show_bug.cgi?id=115449
Reviewed by Geoffrey Garen.
Rename callframeishost to something that makes sense, and fix
getCallerInfo to correctly handle inline functions calling into
the JSGlobalData.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::codeOriginForReturn):
Make this more robust in the face of incorrect stack walking
* interpreter/CallFrame.cpp:
(JSC::CallFrame::trueCallerFrame):
Everyone has to perform a codeblock() check before calling this
so we might as well just do it here.
* interpreter/Interpreter.cpp:
(JSC::getCallerInfo):
2013-04-30 Julien Brianceau <jbrianceau@nds.com>
Bug fixing in sh4 base JIT and LLINT.
https://bugs.webkit.org/show_bug.cgi?id=115420
Reviewed by Oliver Hunt.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::lshift32):
(JSC::MacroAssemblerSH4::rshift32):
(JSC::MacroAssemblerSH4::branchMul32):
(JSC::MacroAssemblerSH4::urshift32):
(JSC::MacroAssemblerSH4::replaceWithJump):
(JSC::MacroAssemblerSH4::maxJumpReplacementSize):
* assembler/SH4Assembler.h:
(JSC::SH4Assembler::shldRegReg):
(JSC::SH4Assembler::shadRegReg):
(JSC::SH4Assembler::shalImm8r):
(SH4Assembler):
(JSC::SH4Assembler::sharImm8r):
(JSC::SH4Assembler::maxJumpReplacementSize):
(JSC::SH4Assembler::replaceWithJump):
* offlineasm/sh4.rb:
2013-04-30 Geoffrey Garen <ggaren@apple.com>
Objective-C JavaScriptCore API should publicly support bridging to C
https://bugs.webkit.org/show_bug.cgi?id=115447
Reviewed by Mark Hahnenberg.
For consistency, I renamed
+[JSValue valueWithValue:] => +[JSValue valueWithJSValueRef]
+[JSContext contextWithGlobalContextRef] => +[JSContext contextWithJSGlobalContextRef]
-[JSContext globalContext] => -[JSContext JSGlobalContextRef]
I searched svn to verify that these functions don't have clients yet,
so we won't break anything.
I also exported as public API
+[JSValue valueWithJSValueRef:]
+[JSContext contextWithJSGlobalContextRef:]
It's hard to integrate with the C API without these.
2013-04-30 Commit Queue <rniwa@webkit.org>
Unreviewed, rolling out r149349 and r149354.
http://trac.webkit.org/changeset/149349
http://trac.webkit.org/changeset/149354
https://bugs.webkit.org/show_bug.cgi?id=115444
The Thumb version of compileSoftModulo make invalid use of
registers (Requested by benjaminp on #webkit).
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARMv7Assembler.h:
(ARMv7Assembler):
* assembler/AbstractMacroAssembler.h:
(JSC::isARMv7s):
(JSC):
* assembler/MacroAssemblerARMv7.cpp: Removed.
* assembler/MacroAssemblerARMv7.h:
(MacroAssemblerARMv7):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileSoftModulo):
(DFG):
(JSC::DFG::SpeculativeJIT::compileIntegerArithDivForARMv7s):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2013-04-30 Zalan Bujtas <zalan@apple.com>
Animations fail to start on http://www.google.com/insidesearch/howsearchworks/thestory/
https://bugs.webkit.org/show_bug.cgi?id=111244
Reviewed by David Kilzer.
Enable performance.now() as a minimal subset of Web Timing API.
It returns DOMHighResTimeStamp, a monotonically increasing value representing the
number of milliseconds from the start of the navigation of the current document.
JS libraries use this API to check against the requestAnimationFrame() timestamp.
* Configurations/FeatureDefines.xcconfig:
2013-04-30 Zoltan Arvai <zarvai@inf.u-szeged.hu>
Unreviewed. Speculative build fix on Qt Arm and Mips after r149349.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileSoftModulo):
2013-04-29 Cosmin Truta <ctruta@blackberry.com>
[ARM] Expand the use of integer division
https://bugs.webkit.org/show_bug.cgi?id=115138
Reviewed by Benjamin Poulain.
If availability of hardware integer division isn't known at compile
time, check the CPU flags and decide at runtime whether to fall back
to software. Currently, this OS-specific check is implemented on QNX.
Moreover, use operator % instead of fmod() in the calculation of the
software modulo. Even when it's software-emulated, operator % is faster
than fmod(): on ARM v7 QNX, without hardware division, we noticed
>3% speedup on SunSpider.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::sdiv): Did not compile conditionally.
(JSC::ARMv7Assembler::udiv): Ditto.
* assembler/AbstractMacroAssembler.h:
(JSC::isARMv7s): Removed.
* assembler/MacroAssemblerARMv7.cpp: Added.
(JSC::isIntegerDivSupported): Added.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::supportsIntegerDiv): Added.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Checked MacroAssembler::supportsIntegerDiv() in ArithDiv case.
* dfg/DFGOperations.cpp:
(JSC::DFG::operationModOnInts): Added.
* dfg/DFGOperations.h:
(JSC::DFG::Z_DFGOperation_ZZ): Added.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileSoftModulo): Separated the X86-specific and ARM-specific codegen
from the common implementation; used operationModOnInts on ARM.
(JSC::DFG::SpeculativeJIT::compileIntegerArithDivForARM): Renamed from compileIntegerArithDivForARMv7.
(JSC::DFG::SpeculativeJIT::compileArithMod): Allowed run-time detection of integer div on ARM.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation): Added overloads with Z_DFGOperation_ZZ arguments.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Used compileIntegerArithDivForARM.
2013-04-29 Benjamin Poulain <benjamin@webkit.org>
Unify the data access of StringImpl members from JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=115320
Reviewed by Andreas Kling.
DFG accesses the member infos by directly calling the methods on StringImpl,
while the baseline JIT was using helper methods on ThunkHelpers.
Cut the middle man, and use StringImpl directly everywhere.
* jit/JITInlines.h:
(JSC::JIT::emitLoadCharacterString):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::stringGetByValStubGenerator):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::stringGetByValStubGenerator):
* jit/JSInterfaceJIT.h:
* jit/ThunkGenerators.cpp:
(JSC::stringCharLoad):
2013-04-29 Benjamin Poulain <bpoulain@apple.com>
Use push and pop for iOS math function thunks
https://bugs.webkit.org/show_bug.cgi?id=115215
Reviewed by Filip Pizlo.
The iOS ABI is a little different than regular ARM ABI regarding stack alignment.
The requirement is 4 bytes:
"The ARM environment uses a stack that—at the point of function calls—is 4-byte aligned,
grows downward, and contains local variables and a function’s parameters."
Subsequently, we can just use push and pop to preserve the link register.
* jit/ThunkGenerators.cpp:
2013-04-29 Brent Fulgham <bfulgham@webkit.org>
[Windows, WinCairo] Get rid of last few pthread include/link references.
https://bugs.webkit.org/show_bug.cgi?id=115375
Reviewed by Tim Horton.
* JavaScriptCore.vcproj/jsc/jscPostBuild.cmd:
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props:
* JavaScriptCore.vcxproj/jsc/jscCommon.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
* JavaScriptCore.vcxproj/testapi/testapiCommon.props:
2013-04-29 Roger Fong <roger_fong@apple.com>
Unreviewed. AppleWin VS2010 build fix.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
2013-04-26 Mark Hahnenberg <mhahnenberg@apple.com>
~BlockAllocator should ASSERT that it has no more Regions left
https://bugs.webkit.org/show_bug.cgi?id=115287
Reviewed by Andreas Kling.
* heap/BlockAllocator.cpp:
(JSC::BlockAllocator::~BlockAllocator):
(JSC::BlockAllocator::allRegionSetsAreEmpty):
* heap/BlockAllocator.h:
(RegionSet):
(JSC::BlockAllocator::RegionSet::isEmpty):
(BlockAllocator):
2013-04-29 Mark Hahnenberg <mhahnenberg@apple.com>
IndexingTypes should use hex
https://bugs.webkit.org/show_bug.cgi?id=115286
Decimal is kind of confusing/hard to read because they're used as bit masks. Hex seems more appropriate.
Reviewed by Geoffrey Garen.
* runtime/IndexingType.h:
2013-04-29 Carlos Garcia Campos <cgarcia@igalia.com>
Unreviewed. Fix make distcheck.
* GNUmakefile.list.am: Add missing headers files to compilation
and offlineasm/sh4.rb script.
2013-04-28 Dean Jackson <dino@apple.com>
[Mac] Disable canvas backing store scaling (HIGH_DPI_CANVAS)
https://bugs.webkit.org/show_bug.cgi?id=115310
Reviewed by Simon Fraser.
Remove ENABLE_HIGH_DPI_CANVAS_macosx.
* Configurations/FeatureDefines.xcconfig:
2013-04-27 Darin Adler <darin@apple.com>
Move from constructor and member function adoptCF/NS to free function adoptCF/NS.
https://bugs.webkit.org/show_bug.cgi?id=115307
Reviewed by Geoffrey Garen.
* heap/HeapTimer.cpp:
(JSC::HeapTimer::HeapTimer):
* runtime/JSGlobalData.cpp:
(JSC::enableAssembler):
Use adoptCF free function.
2013-04-27 Anders Carlsson <andersca@apple.com>
Try to fix the Windows build.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
2013-04-25 Geoffrey Garen <ggaren@apple.com>
Cleaned up pre/post inc/dec in bytecode
https://bugs.webkit.org/show_bug.cgi?id=115222
Reviewed by Filip Pizlo.
A few related changes here:
(*) Removed post_inc and post_dec. The two-result form was awkward to
reason about. Being explicit about the intermediate mov and to_number
reduces DFG overhead, removes some fragile ASSERTs from the DFG, and
fixes a const bug. Plus, we get to blow away 262 lines of code.
(*) Renamed pre_inc and pre_dec to inc and dec, since there's only one
version now.
(*) Renamed to_jsnumber to to_number, to match the ECMA name.
(*) Tightened up the codegen and runtime support for to_number.
* JavaScriptCore.order: Order!
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitInc):
(JSC::BytecodeGenerator::emitDec):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitToNumber):
(BytecodeGenerator): Removed post_inc and post_dec.
* bytecompiler/NodesCodegen.cpp:
(JSC::emitPreIncOrDec): Updated for rename.
(JSC::emitPostIncOrDec): Issue an explicit mov and to_number when needed.
These are rare, and they boil away in the DFG.
(JSC::PostfixNode::emitResolve):
(JSC::PrefixNode::emitResolve): For const, use an explicit mov instead
of any special forms. This fixes a bug where we would do string
add/subtract instead of number.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.h:
(JSC::DFG::canCompileOpcode):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_inc):
(JSC::JIT::emitSlow_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emitSlow_op_dec):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_op_inc):
(JSC::JIT::emitSlow_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emitSlow_op_dec): Removed post_inc/dec, and updated for renames.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emitSlow_op_to_number): Removed a test for number cells. There's
no such thing!
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_to_number): Use LowestTag to avoid making assumptions
about the lowest valued tag.
(JSC::JIT::emitSlow_op_to_number): Updated for renames.
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* jit/JITStubs.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/NodeConstructors.h:
(JSC::UnaryPlusNode::UnaryPlusNode): Removed post_inc/dec, and updated for renames.
* runtime/Operations.cpp:
(JSC::jsIsObjectType): Removed a test for number cells. There's
no such thing!
2013-04-27 Julien Brianceau <jbrianceau@nds.com>
REGRESSION(r149114): cache flush for SH4 arch may flush an extra page.
https://bugs.webkit.org/show_bug.cgi?id=115305
Reviewed by Andreas Kling.
* assembler/SH4Assembler.h:
(JSC::SH4Assembler::cacheFlush):
2013-04-26 Geoffrey Garen <ggaren@apple.com>
Re-landing <http://trac.webkit.org/changeset/148999>
Filled out more cases of branch folding in bytecode when emitting
expressions into a branching context
https://bugs.webkit.org/show_bug.cgi?id=115057
Reviewed by Phil Pizlo.
We can't fold the number == 1 case to boolean because all non-zero numbers
down-cast to true, but only 1 is == to true.
2013-04-26 Filip Pizlo <fpizlo@apple.com>
Correct indentation of SymbolTable.h
Rubber stamped by Mark Hahnenberg.
* runtime/SymbolTable.h:
2013-04-26 Roger Fong <roger_fong@apple.com>
Make Apple Windows VS2010 build results into and get dependencies from __32 suffixed folders.
Make the DebugSuffix configuration use _debug dependencies.
* JavaScriptCore.vcxproj/JavaScriptCore.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.vcxproj/JavaScriptCoreCF.props:
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
* JavaScriptCore.vcxproj/JavaScriptCoreDebug.props:
* JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorBuildCmd.cmd:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorDebug.props:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPreBuild.cmd:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorProduction.props:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props:
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedCommon.props:
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props:
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props:
* JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props:
* JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd:
* JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd:
* JavaScriptCore.vcxproj/JavaScriptCoreProduction.props:
* JavaScriptCore.vcxproj/JavaScriptCoreRelease.props:
* JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props:
* JavaScriptCore.vcxproj/build-generated-files.sh:
* JavaScriptCore.vcxproj/copy-files.cmd:
* JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
* JavaScriptCore.vcxproj/jsc/jscCommon.props:
* JavaScriptCore.vcxproj/jsc/jscDebug.props:
* JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd:
* JavaScriptCore.vcxproj/jsc/jscPreLink.cmd:
* JavaScriptCore.vcxproj/jsc/jscProduction.props:
* JavaScriptCore.vcxproj/jsc/jscRelease.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
* JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters:
* JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd:
* JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd:
* JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapiCommon.props:
* JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props:
* JavaScriptCore.vcxproj/testapi/testapiDebug.props:
* JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props:
* JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd:
* JavaScriptCore.vcxproj/testapi/testapiProduction.props:
* JavaScriptCore.vcxproj/testapi/testapiRelease.props:
* JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props:
2013-04-26 Roger Fong <roger_fong@apple.com>
Disable sub-pixel layout on mac.
https://bugs.webkit.org/show_bug.cgi?id=114999.
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2013-04-26 Oliver Hunt <oliver@apple.com>
Make stack tracing more robust
https://bugs.webkit.org/show_bug.cgi?id=115272
Reviewed by Geoffrey Garen.
CallFrame already handles stack walking confusion robustly,
so we should make sure that the actual walk handles that as well.
* interpreter/Interpreter.cpp:
(JSC::getCallerInfo):
2013-04-26 Mark Hahnenberg <mhahnenberg@apple.com>
REGRESSION(r149165): It made many tests crash on 32 bit
https://bugs.webkit.org/show_bug.cgi?id=115227
Reviewed by Csaba Osztrogonác.
m_reservation is uninitialized when ENABLE(SUPER_REGION) is false.
* heap/SuperRegion.cpp:
(JSC::SuperRegion::~SuperRegion):
2013-04-26 Julien Brianceau <jbrianceau@nds.com>
Fix SH4 build broken since r149159.
https://bugs.webkit.org/show_bug.cgi?id=115229
Add BranchTruncateType enum in SH4 port and handle it in branchTruncateDoubleToInt32.
Reviewed by Allan Sandfeld Jensen.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::branchTruncateDoubleToInt32):
2013-04-25 Mark Hahnenberg <mhahnenberg@apple.com>
SuperRegion doesn't call deallocate() on its PageReservation
https://bugs.webkit.org/show_bug.cgi?id=115208
Reviewed by Geoffrey Garen.
It should. This doesn't cause us to leak physical memory, but it does cause us to leak virtual
address space (and probably mach ports), which is also bad :-( FixedVMPoolExecutableAllocator
also has this bug, but it doesn't matter much because there's only one instance of that class
throughout the entire lifetime of the process, whereas each JSGlobalData has its own SuperRegion.
* heap/SuperRegion.cpp:
(JSC::SuperRegion::~SuperRegion):
* heap/SuperRegion.h:
(SuperRegion):
* jit/ExecutableAllocatorFixedVMPool.cpp:
(FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator):
2013-04-25 Filip Pizlo <fpizlo@apple.com>
DFG doesn't support to_jsnumber
https://bugs.webkit.org/show_bug.cgi?id=115129
Reviewed by Geoffrey Garen.
Based on Oliver's patch. Implements to_jsnumber as Identity(Number:@thingy), and then does
an optimization in Fixup to turn Identity(Number:) into Identity(Int32:) if the predictions
tell us to. Identity is later turned into Phantom.
Also fixed BackPropMask, which appeared to have NodeDoesNotExit included in it. That's
wrong; NodeDoesNotExit is not a backward propagation property.
Also fixed Identity to be marked as CanExit (i.e. not NodeDoesNotExit).
This more than doubles the FPS on ammo.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.h:
(JSC::DFG::canCompileOpcode):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(FixupPhase):
(JSC::DFG::FixupPhase::observeUseKindOnNode):
(JSC::DFG::FixupPhase::observeUseKindOnEdge):
* dfg/DFGNodeFlags.h:
(DFG):
* dfg/DFGNodeType.h:
(DFG):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
2013-04-24 Oliver Hunt <oliver@apple.com>
Add support for Math.imul
https://bugs.webkit.org/show_bug.cgi?id=115143
Reviewed by Filip Pizlo.
Add support for Math.imul, a thunk generator for Math.imul,
and an intrinsic.
Fairly self explanatory set of changes, DFG intrinsics simply
leverages the existing ValueToInt32 nodes.
* create_hash_table:
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsic):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::performNodeCSE):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
(DFG):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithIMul):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/ThunkGenerators.cpp:
(JSC::imulThunkGenerator):
(JSC):
* jit/ThunkGenerators.h:
(JSC):
* runtime/Intrinsic.h:
* runtime/MathObject.cpp:
(JSC):
(JSC::mathProtoFuncIMul):
* runtime/JSGlobalData.cpp:
(JSC::thunkGeneratorForIntrinsic):
2013-04-25 Filip Pizlo <fpizlo@apple.com>
Unreviewed, roll out http://trac.webkit.org/changeset/148999
It broke http://kripken.github.io/ammo.js/examples/new/ammo.html
* JavaScriptCore.order:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewArray):
(JSC::BytecodeGenerator::emitThrowReferenceError):
(JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::shouldEmitProfileHooks):
(BytecodeGenerator):
* bytecompiler/NodesCodegen.cpp:
(JSC):
(JSC::NullNode::emitBytecode):
(JSC::BooleanNode::emitBytecode):
(JSC::NumberNode::emitBytecode):
(JSC::StringNode::emitBytecode):
(JSC::IfNode::emitBytecode):
(JSC::IfElseNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createIfStatement):
(ASTBuilder):
* parser/NodeConstructors.h:
(JSC):
(JSC::NullNode::NullNode):
(JSC::BooleanNode::BooleanNode):
(JSC::NumberNode::NumberNode):
(JSC::StringNode::StringNode):
(JSC::IfNode::IfNode):
(JSC::IfElseNode::IfElseNode):
* parser/Nodes.h:
(JSC::ExpressionNode::isPure):
(JSC::ExpressionNode::isSubtract):
(StatementNode):
(NullNode):
(JSC::NullNode::isNull):
(BooleanNode):
(JSC::BooleanNode::isPure):
(NumberNode):
(JSC::NumberNode::value):
(JSC::NumberNode::isPure):
(StringNode):
(JSC::StringNode::isPure):
(JSC::StringNode::isString):
(BinaryOpNode):
(IfNode):
(JSC):
(IfElseNode):
(ContinueNode):
(BreakNode):
* parser/Parser.cpp:
(JSC::::parseIfStatement):
* parser/ResultType.h:
(ResultType):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::pureToBoolean):
* runtime/JSCell.h:
(JSCell):
* runtime/JSCellInlines.h:
(JSC):
2013-04-25 Filip Pizlo <fpizlo@apple.com>
PreciseJumpTargets should treat loop_hint as a jump target
https://bugs.webkit.org/show_bug.cgi?id=115209
Reviewed by Mark Hahnenberg.
I didn't add a test but I turned this into a release assertion. Running Octane is enough
to trigger it.
* bytecode/PreciseJumpTargets.cpp:
(JSC::computePreciseJumpTargets):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2013-04-25 Roman Zhuykov <zhroma@ispras.ru>
Fix problems with processing negative zero on DFG.
https://bugs.webkit.org/show_bug.cgi?id=113862
Reviewed by Filip Pizlo.
Fix NodeNeedsNegZero flag propagation in BackwardPropagationPhase.
Function arithNodeFlags should not mask NodeNeedsNegZero flag for ArithNegate and DoubleAsInt32
nodes and this flag should be always used to decide where we need to generate nezative-zero checks.
Remove unnecessary negative-zero checks from integer ArithDiv on ARM.
Also remove such checks from integer ArithMod on ARM and X86, and make them always to
check not only "modulo_result == 0" but also "dividend < 0".
Generate faster code for case when ArithMod operation divisor is constant power of 2 on ARMv7
in the same way as on ARMv7s, and add negative-zero checks into this code when needed.
Change speculationCheck ExitKind from Overflow to NegativeZero where applicable.
This shows 30% speedup of math-spectral-norm, and 5% speedup
on SunSpider overall on ARMv7 Linux.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::branchConvertDoubleToInt32):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::branchConvertDoubleToInt32):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branchConvertDoubleToInt32):
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::branchConvertDoubleToInt32):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::isNotNegZero):
(JSC::DFG::BackwardsPropagationPhase::isNotPosZero):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGNode.h:
(JSC::DFG::Node::arithNodeFlags):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
(JSC::DFG::SpeculativeJIT::compileSoftModulo):
(JSC::DFG::SpeculativeJIT::compileArithNegate):
2013-04-25 Oliver Hunt <oliver@apple.com>
Stack guards are too conservative
https://bugs.webkit.org/show_bug.cgi?id=115147
Reviewed by Mark Hahnenberg.
Increase stack guard to closer to old size.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::StackPolicy::StackPolicy):
2013-04-25 Oliver Hunt <oliver@apple.com>
Stack guards are too conservative
https://bugs.webkit.org/show_bug.cgi?id=115147
Reviewed by Geoffrey Garen.
Reduce the limits and simplify the decision making.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::StackPolicy::StackPolicy):
2013-04-25 Nick Diego Yamane <nick.yamane@openbossa.org>
JSC: Fix interpreter misbehavior in builds with JIT disabled
https://bugs.webkit.org/show_bug.cgi?id=115190
Reviewed by Oliver Hunt.
Commit http://trac.webkit.org/changeset/147858 modified
some details on how JS stack traces are built. The method
"getLineNumberForCallFrame", renamed in that changeset to
"getBytecodeOffsetForCallFrame" is always returning `0' when
JIT is disabled
How to reproduce:
- Build webkit with JIT disabled
- Open MiniBrowser, for example, with http://google.com
- In a debug build, WebProcess will hit the following ASSERT:
Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp:279 ASSERT(low);
* interpreter/Interpreter.cpp:
(JSC::getBytecodeOffsetForCallFrame):
2013-04-25 Oliver Hunt <oliver@apple.com>
Make checkSyntax take a JSGlobalData instead of an ExecState
RS=Tim
* jsc.cpp:
(runInteractive):
* runtime/Completion.cpp:
(JSC::checkSyntax):
* runtime/Completion.h:
(JSC):
2013-04-25 Michael Saboff <msaboff@apple.com>
32 Bit: Crash due to RegExpTest nodes not setting result type to Boolean
https://bugs.webkit.org/show_bug.cgi?id=115188
Reviewed by Geoffrey Garen.
Changed the RegExpTest node to set the AbstractValue to boolean, since that
what it is.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
2013-04-25 Julien Brianceau <jbrianceau@nds.com>
REGRESSION(r137994): Random crashes occur with SH4 JSC.
https://bugs.webkit.org/show_bug.cgi?id=115167.
Reviewed by Oliver Hunt.
Since r137994, uncommited pages could be inside the area of memory in
parameter of the cacheFlush function. That's why we have to flush each
page separately to avoid a fail of the whole flush, if an uncommited page
is in the area.
This patch is very similar to changeset 145194 made for ARMv7 architecture,
see https://bugs.webkit.org/show_bug.cgi?id=111441 for further information.
* assembler/SH4Assembler.h:
(JSC::SH4Assembler::cacheFlush):
2013-04-24 Mark Lam <mark.lam@apple.com>
Add watchdog timer polling for the DFG.
https://bugs.webkit.org/show_bug.cgi?id=115134.
Reviewed by Geoffrey Garen.
The strategy is to add a speculation check to the DFG generated code to
test if the watchdog timer has fired or not. If the watchdog timer has
fired, the generated code will do an OSR exit to the baseline JIT, and
let it handle servicing the watchdog timer.
If the watchdog is not enabled, this speculation check will not be
emitted.
* API/tests/testapi.c:
(currentCPUTime_callAsFunction):
(extendTerminateCallback):
(main):
- removed try/catch statements so that we can test the watchdog on the DFG.
- added JS bindings to a native currentCPUTime() function so that the timeout
tests can be more accurate.
- also shortened the time values so that the tests can complete sooner.
* bytecode/ExitKind.h:
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* runtime/Watchdog.cpp:
(JSC::Watchdog::setTimeLimit):
2013-04-24 Filip Pizlo <fpizlo@apple.com>
Special thunks for math functions should work on ARMv7
https://bugs.webkit.org/show_bug.cgi?id=115144
Reviewed by Gavin Barraclough and Oliver Hunt.
The only hard bit here was ensuring that we implemented the very special
"cheap C call" convention on ARMv7.
* assembler/AbstractMacroAssembler.h:
(JSC::isARMv7s):
(JSC):
(JSC::isX86):
* dfg/DFGCommon.h:
* jit/SpecializedThunkJIT.h:
(SpecializedThunkJIT):
(JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn):
* jit/ThunkGenerators.cpp:
(JSC::floorThunkGenerator):
(JSC::ceilThunkGenerator):
(JSC::roundThunkGenerator):
(JSC::expThunkGenerator):
(JSC::logThunkGenerator):
2013-04-24 Julien Brianceau <jbrianceau@nds.com>
Misc bugfix and cleaning in sh4 base JIT.
https://bugs.webkit.org/show_bug.cgi?id=115022.
Reviewed by Oliver Hunt.
Remove unused add32() and sub32() with scratchreg parameter to avoid
confusion as this function prototype means another behaviour.
Remove unused "void push(Address)" function which seems quite buggy.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::and32): Cosmetic change.
(JSC::MacroAssemblerSH4::lshift32): Cosmetic change.
(JSC::MacroAssemblerSH4::or32): Cosmetic change.
(JSC::MacroAssemblerSH4::xor32): Cosmetic change.
(MacroAssemblerSH4):
(JSC::MacroAssemblerSH4::load32): Cosmetic change.
(JSC::MacroAssemblerSH4::load8Signed): Fix invalid offset upper limit
when using r0 register and cosmetic changes.
(JSC::MacroAssemblerSH4::load8): Reuse load8Signed to avoid duplication.
(JSC::MacroAssemblerSH4::load16): Fix invalid offset upper limit when
using r0 register, fix missing offset shift and cosmetic changes.
(JSC::MacroAssemblerSH4::store32): Cosmetic change.
(JSC::MacroAssemblerSH4::branchAdd32): Store result value before branch.
2013-04-24 Patrick Gansterer <paroga@webkit.org>
[WIN] Remove pthread from Visual Studio files in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=114864
Reviewed by Brent Fulgham.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:
* JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops:
* JavaScriptCore.vcproj/jsc/jscCommon.vsprops:
* JavaScriptCore.vcproj/testRegExp/testRegExpCommon.vsprops:
* JavaScriptCore.vcproj/testapi/testapiCommon.vsprops:
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props:
* JavaScriptCore.vcxproj/jsc/jscCommon.props:
* JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
* JavaScriptCore.vcxproj/testapi/testapiCommon.props:
* JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props:
2013-04-24 Filip Pizlo <fpizlo@apple.com>
DFG should keep the operand to create_this alive if it's emitting code for create_this
https://bugs.webkit.org/show_bug.cgi?id=115133
Reviewed by Mark Hahnenberg.
The DFG must model bytecode liveness, or else OSR exit is going to have a really bad time.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2013-04-24 Roger Fong <roger_fong@apple.com>
Have VS2010 WebKit solution look in WebKit_Libraries/lib32 for dependencies.
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd:
* JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd:
* JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd:
* JavaScriptCore.vcxproj/jsc/jscPreLink.cmd:
* JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters:
* JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd:
* JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd:
* JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd:
2013-04-24 Geoffrey Garen <ggaren@apple.com>
32-bit build fix.
Unreviewed.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch): Explicitly
truncate to 32-bit to avoid compiler warnings. It's safe to truncate
because the payload of a boolean is the low bits on both 64-bit and 32-bit.
2013-04-23 Geoffrey Garen <ggaren@apple.com>
Filled out more cases of branch folding in the DFG
https://bugs.webkit.org/show_bug.cgi?id=115088
Reviewed by Oliver Hunt.
No change on the benchmarks we track, but a 3X speedup on a
microbenchmark that uses these techniques.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock): (!/=)= and (!/=)== can constant
fold all types, not just numbers, because true constants have no
side effects when type-converted at runtime.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateBoolean): Added support for fixing up
boolean uses, like we do for other types like number.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch):
(JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
(JSC::DFG::SpeculativeJIT::compare):
(JSC::DFG::SpeculativeJIT::compileStrictEq):
(JSC::DFG::SpeculativeJIT::compileBooleanCompare): Peephole fuse
boolean compare and/or compare-branch, now that we have the types for
them.
* dfg/DFGSpeculativeJIT.h: Updated declarations.
== Rolled over to ChangeLog-2013-04-24 ==