- Add --harmony-symbols flag.
- Add Symbol constructor; allow symbols as (unreplaced) return value from constructors.
- Introduce %CreateSymbol and %_IsSymbol natives and respective instructions.
- Extend 'typeof' code generation to handle symbols.
- Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols.
- Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method.
- Extend Object.prototype.toString to recognise symbols.
Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object).
(Baseline CL: https://codereview.chromium.org/12223071/)
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12296026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in preparation of the introduction of ES6 'symbols' (aka private/unique names).
The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.
The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12210083
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Unified parameter order of CreateHandle with the rest of v8 on the way. A few
Isolate::Current()s had to be introduced, which is not nice, and not every place
will win a beauty contest, but we can clean this up later easily in smaller steps.
Review URL: https://codereview.chromium.org/12300018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows Crankshaft to completely inline a f.apply() dispatch if the
exact number of arguments is known and the function is constant. The
deoptimizer doesn't generate the f.apply() frame during deoptimization,
so the materialized frames look like f.apply() did a tailcall.
R=jkummerow@chromium.org
TEST=mjsunit/compiler/inline-function-apply
Review URL: https://codereview.chromium.org/12263004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13665 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes:
* Adding support for saving callee-clobbered double registers in Crankshaft code.
* Adding a new "HTrapAllocationMemento" hydrogen instruction to handle AllocationSiteInfo data in crankshafted stubs.
* Adding a new "HAllocate" hydrogen instruction that can allocate raw memory from the GC in crankshafted code.
* Support for manipulation of the hole in HChange instructions for Crankshafted stubs.
* Utility routines to manually build loops and if statements containing hydrogen code.
Review URL: https://codereview.chromium.org/11659022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13585 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
With parallel recompilation enabled, objects made accessible by handles may
have changed between graph construction and graph optimization. Therefore
we must not assume that information on those objects remain the same between
those two phases. To police this, we forbid handle dereferencing during
graph optimization.
Exceptions to this rule are:
- Dereferencing the handle to obtain the raw location of the object. This
is safe since parallel recompilation acquires RelocationLock
- Some places that dereference the handle for a type check. These are checked
to be safe on a case-by-case basis.
R=jkummerow@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/12049012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13475 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
HCheckPrototypeMaps currently records the prototype and the holder of the
prototype chain (both ends of the chain) and assumes that the chain elements
and their maps did not change in during the entirety of Crankshaft. The actual
traversal of the prototype chain happens in Lithium at code generation.
With parallel compilation, this assumption is not longer correct.
R=mstarzinger@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/11864013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13454 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reduces the time take for mjsunit/limit-locals from 56.8s to 15.1s in debug
mode and from 12.0s to 1.6s in release mode.
Note that GrowableBitVector and BitVector should really be merged, and probably
have their allocation strategy parmeterized. The current state of affairs
involving tons of checks and delegation is extremely ugly, and it is far from
clear if all that special casing is a clear win. STL FTW! :-P
Review URL: https://codereview.chromium.org/11775016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13327 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Modules now have their own local scope, represented by their own context.
Module instance objects have an accessor for every export that forwards
access to the respective slot from the module's context. (Exports that are
modules themselves, however, are simple data properties.)
All modules have a _hosting_ scope/context, which (currently) is the
(innermost) enclosing global scope. To deal with recursion, nested modules
are hosted by the same scope as global ones.
For every (global or nested) module literal, the hosting context has an
internal slot that points directly to the respective module context. This
enables quick access to (statically resolved) module members by 2-dimensional
access through the hosting context. For example,
module A {
let x;
module B { let y; }
}
module C { let z; }
allocates contexts as follows:
[header| .A | .B | .C | A | C ] (global)
| | |
| | +-- [header| z ] (module)
| |
| +------- [header| y ] (module)
|
+------------ [header| x | B ] (module)
Here, .A, .B, .C are the internal slots pointing to the hosted module
contexts, whereas A, B, C hold the actual instance objects (note that every
module context also points to the respective instance object through its
extension slot in the header).
To deal with arbitrary recursion and aliases between modules,
they are created and initialized in several stages. Each stage applies to
all modules in the hosting global scope, including nested ones.
1. Allocate: for each module _literal_, allocate the module contexts and
respective instance object and wire them up. This happens in the
PushModuleContext runtime function, as generated by AllocateModules
(invoked by VisitDeclarations in the hosting scope).
2. Bind: for each module _declaration_ (i.e. literals as well as aliases),
assign the respective instance object to respective local variables. This
happens in VisitModuleDeclaration, and uses the instance objects created
in the previous stage.
For each module _literal_, this phase also constructs a module descriptor
for the next stage. This happens in VisitModuleLiteral.
3. Populate: invoke the DeclareModules runtime function to populate each
_instance_ object with accessors for it exports. This is generated by
DeclareModules (invoked by VisitDeclarations in the hosting scope again),
and uses the descriptors generated in the previous stage.
4. Initialize: execute the module bodies (and other code) in sequence. This
happens by the separate statements generated for module bodies. To reenter
the module scopes properly, the parser inserted ModuleStatements.
R=mstarzinger@chromium.org,svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/11093074
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously Crankshaft emitted a generic load for these, now we emit a load of a
named field, guarded by a proto chain check.
LCheckPrototypeMaps now returns the holder, which is for free, because it
already had to check its map as the last step, anyway. This is in sync with what
StubCompiler::CheckPrototype does.
Review URL: https://codereview.chromium.org/11338030
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12847 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We iteratively remove all dead Hydrogen instruction until we reach a fixed point. We consider an instruction dead if it is unused, has no observable side effects and is deletable. The last part of the condition is currently not very nice: We basically have to whitelist "safe" instructions, because we are missing more detailed dependencies and/or more detailed tracking of side effects.
We disable dead code elimination for now in our test runners, because we have tons of poorly written tests which wouldn't test anymore what they are supposed to test with this phase enabled. To get test coverage for dead code elimination itself, we should enable it on a few build bots. This is not really a perfect state, but the best we can do for now.
This patch includes a few const-correctness fixes, most of them were necessary for this CL.
Review URL: https://codereview.chromium.org/11088027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12697 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes materialization of arguments objects for strict mode functions during
deoptimization. We materialize arguments from the stack area where optimized
code pushes the arguments when entering the inlined environment. For adapted
invocations we use the arguments adaptor frame for materialization.
R=svenpanne@chromium.org
BUG=v8:2261
TEST=mjsunit/regress/regress-2261,mjsunit/compiler/inline-arguments
Review URL: https://chromiumcodereview.appspot.com/10908194
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12489 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
xmm0 is not saved across runtime call on x64 because MacroAssembler::EnterExitFrameEpilogue preserves only allocatable XMM registers unlike on ia32 where it preserves all registers.
Cleanup handling of shifts: SHR can deoptimize only when its a shift by 0, all other shift never deoptimize.
Fix type inference for i-to-t change instruction. On X64 this ensures that write-barrier is generated correctly.
R=danno@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10868032
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12373 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Safe operations are those that either do not observe unsignedness or have special support for uint32 values:
- all binary bitwise operations: they perform ToInt32 on inputs;
- >> and << shifts: they perform ToInt32 on left hand side and ToUint32 on right hand side;
- >>> shift: it performs ToUint32 on both inputs;
- stores to integer external arrays (not pixel, float or double ones): these stores are "bitwise";
- HChange: special support added for conversions of uint32 values to double and tagged values;
- HSimulate: special support added for deoptimization with uint32 values in registers and stack slots;
- HPhi: phis that have only safe uses and only uint32 operands are uint32 themselves.
BUG=v8:2097
TEST=test/mjsunit/compiler/uint32.js
Review URL: https://chromiumcodereview.appspot.com/10778029
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12367 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in anticipation of the upcoming lexical global scope.
Mostly automatised as:
for FILE in `egrep -ril "global[ _]?context" src test/cctest`
do
echo $FILE
sed "s/Global context/Native context/g" <$FILE >$FILE.0
sed "s/global context/native context/g" <$FILE.0 >$FILE.1
sed "s/global_context/native_context/g" <$FILE.1 >$FILE.2
sed "s/GLOBAL_CONTEXT/NATIVE_CONTEXT/g" <$FILE.2 >$FILE.3
sed "s/GlobalContext/NativeContext/g" <$FILE.3 >$FILE
rm $FILE.[0-9]
done
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10832342
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12325 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently only simple setter calls are handled (i.e. no calls in count
operations or compound assignments), and deoptimization in the setter is not
handled at all. Because of the latter, we temporarily hide this feature behind
the --inline-accessors flag, just like inlining getters.
We now use an enum everywhere we depend on the handling of a return value,
passing around several boolean would be more confusing.
Made VisitReturnStatement and the final parts of TryInline more similar, so
matching them visually is a bit easier now.
Simplified the signature of AddLeaveInlined, the target of the HGoto can simply
be retrieved from the function state.
Review URL: https://chromiumcodereview.appspot.com/10836133
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12286 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When inlining is being done, it is crucial to use the correct type feedback
oracle with a given type feedback ID. To ensure this, TestContext now carries an
oracle which is associated with the context's condition, and these are both used
together in TestContext::BuildBranch.
Note that in VisitReturnStatement and TryInline we are currently lucky that the
oracles don't go out of sync in an observable way, but this will change when we
inline setters. Therefore, there is no separate test case...
Review URL: https://chromiumcodereview.appspot.com/10834247
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12284 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The underlying problem is that for compound/count operations we use the *load*
type feedback for storing, too. For normal properties this doesn't matter, but
for accessor properties we should better use the *store* type feedback, which
would be available, too. This consistent feedback usage could be guaranteed if
we removed the heavy copy-n-paste in the crankshaft code generation for
compound/count operations and assignments/property loads.
To be on the safe side, we postpone this refactoring and do a quick and easily
mergeable fix.
BUG=140083
TEST=mjsunit/regress/regress-crbug-140083.js
Review URL: https://chromiumcodereview.appspot.com/10828146
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12252 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently only simple getter calls are handled (i.e. no calls in count
operations or compound assignments), and deoptimization in the getter is not
handled at all. Because of the latter, we temporarily hide this feature behind a
new flag --inline-accessors, which is false by default.
Review URL: https://chromiumcodereview.appspot.com/10828066
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12223 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a refactoring-only CL and the third one in a series for enabling
inlining of accessors. The goal of this CL is to move the builders for accessors
to the places where we might be able to inline them later, i.e. the VisitFoo and
HandleBar member functions of HGraphBuilder.
Extracted duplicate code into LookupAccessorPair.
Review URL: https://chromiumcodereview.appspot.com/10831047
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12209 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a refactoring-only CL and the first one in a series for enabling
inlining of accessors. The naming and argument order has been unified a bit, and
some tests have been pushed to the caller in order to get a simpler
signature. Note that the latter temporarily introduces some code redundancy, but
this will be cleaned up in one of the next CLs.
Review URL: https://chromiumcodereview.appspot.com/10826028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12198 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The previous fix was for "real" calls, this one is for getters. It is a bit
unfortunate that this has to be fixed twice: We should really break up
Call::ComputeTarget into a predicate and 1 or 2 getters, so code can be reused.
The regression test has been modified a bit to make things more uniform.
Review URL: https://chromiumcodereview.appspot.com/10702164
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12053 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In this design maps contain descriptor arrays, which in turn can contain transition arrays. If transitions are needed when no descriptor array is present, a descriptor array without real descriptors is inserted just so it can point at the transition array.
The transition array does not contain details about the field it transitions to. In order to weed out transitions to FIELDs from CONSTANT_FUNCTION (what used to be MAP_TRANSITION vs CONSTANT_TRANSITION), the transition needs to be followed and the details need to be looked up in the target map. CALLBACKS transitions are still easy to recognize since the transition targets are stored as an AccessorPair containing the maps, rather than the maps directly.
Currently AccessorPairs containing a transition and an accessor are shared between the descriptor array and the transition array. This simplifies lookup since we only have to look in one of both arrays. This will change in subsequent revisions, when descriptor arrays will become shared between multiple maps, since transitions cannot be shared.
Review URL: https://chromiumcodereview.appspot.com/10697015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11994 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Ensure that IsFound() is only used when not in combination with other
checks. To do so, the default type is NONEXISTENT rather than NORMAL;
and NotFound() also resets the type to NONEXISTENT.
- Use test methods rather than .type() == A_PROPERTY_TYPE.
Review URL: https://chromiumcodereview.appspot.com/10626004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11899 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The CompilationInfo record now saves a Zone, and the compiler pipeline
allocates memory from the Zone in the CompilationInfo. Before
compiling a function, we create a Zone on the stack and save a pointer
to that Zone to the CompilationInfo; which then gets picked up and
allocated from.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10534139
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11877 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Extend HValue interface to allow splitting observed input representation (comming from type feedback) from required input representation (dictated by instruction itself). Currently all instructions except for bitwise binary operations have this representations match. For bitwise binary operations hydrogen builder unconditionaly forces Integer32 representation for those operations that have Double type feedback. Thus causing representation inference to incorrectly count such uses as Integer32 instead of Double. This change also prepares for more fine grained type feedback for inputs of binary operations.
- For phies that are not convertable to Integer32 discard direct and indirect use count of Integer32 type to avoid propagation of these uses to connected phies.
R=jkummerow@chromium.org
BUG=v8:2096
Review URL: https://chromiumcodereview.appspot.com/10540049
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11737 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Removes 6 out of 8 of our remaining unintentional failures on test262.
Also fixes treatment of inherited setters added after the fact.
Specifically:
- In the runtime, when looking for setter callbacks in the prototype chain,
also look for read-only properties. If one is found, reject (exception in
strict mode). If a proxy is found, invoke proper trap.
Note: this folds in the CanPut function from the spec and avoids an extra
lookup over the prototype chain.
- In generated code for stores, insert a test for the maps from the prototype
chain, but only up to the object where the property already exists (which
may be the object itself).
In Hydrogen, if the found property is read-only or not cacheable (e.g. a
proxy), bail out; in a stub, generate an unconditional miss (to get an
exception in strict mode).
- Add test cases and adapt existing test expectations.
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10388047
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11694 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When an array index (in an array access) is a simple "expression + constant", just embed the constant in the array access operation so that the full index expression is (potentially) no longer used and its live range can be much shorter.
This is effective in conjunction with array bounds check removal (otherwise the index is anyway used in the check).
Review URL: https://chromiumcodereview.appspot.com/10382055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11596 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As a special case, for checks on index expressions with the form (expr + constant) if a smaller constant is checked later in the DT also eliminate the check.
Finally, if a larger constant is checked later in the same BB do the more general check (larger constant) earlier instead of the less general one.
This will not cause useless deoptimizations because, since we are in the same BB, all the checks would have been executed anyway.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10032029
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11437 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Constructs the (generally cyclic) graph of module instance objects
and populates their exports. Any exports other than nested modules
are currently set to 'undefined' (but already present as properties).
Details:
- Added new type JSModule for instance objects: a JSObject carrying a context.
- Statically allocate instance objects for all module literals (in parser 8-}).
- Extend interfaces to record and unify concrete instance objects,
and to support iteration over members.
- Introduce new runtime function for pushing module contexts.
- Generate code for allocating, initializing, and setting module contexts,
and for populating instance objects from module literals.
Currently, all non-module exports are still initialized with 'undefined'.
- Module aliases are resolved statically, so no special code is required.
- Make sure that code containing module constructs is never optimized
(macrofy AST node construction flag setting while we're at it).
- Add test case checking linkage.
Baseline: http://codereview.chromium.org/9722043/R=svenpanne@chromium.org,mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9844002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11336 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Do proper dispatch on declaration type instead of mingling together
different code generation paths. Once we add more declaration forms,
this is more scalable.
In separate steps, I'd like to (1) clean up the logic for DeclareGlobal,
and (2) try to reduce the special handling of the name function var if
possible.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9704054
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11331 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change allows hydrogen instructions to keep track of instructions
that dominate certain side-effects (GVN flags) in the hydrogen graph. We
use the GVN pass to keep track of side-effects because accurate flags
are already in place.
It also adds a new side-effect (kChangesNewSpacePromotion) indicating
whether an instruction can cause a GC and have objects be promoted to
old-space. An object allocated in new-space is sure to stay on paths not
having said side-effect.
R=erik.corry@gmail.com
TEST=mjsunit/compiler/inline-construct
Review URL: https://chromiumcodereview.appspot.com/10031031
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11270 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Lithium translation rebuilds hydrogen environments from scratch so we have to ensure that arguments object is correctly bound on function entry otherwise deoptimization will not materialize it.
This fix was implemented as part of r11109 and then reverted.
R=danno@chromium.org
BUG=v8:2045
TEST=test/mjsunit/regress/regress-2045.js
Review URL: https://chromiumcodereview.appspot.com/9963008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11194 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Inlined strict mode functions (that are not called as methods) will get
their receiver reset to undefined. This should not happen when inlining
constructors.
This change also simplifies the test suite to reuse the same closures
into which constructors get inlined and use gc() to force V8 to forget
collected type feedback.
R=vegorov@chromium.org
TEST=mjsunit/compiler/inline-construct
Review URL: https://chromiumcodereview.appspot.com/9597017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10920 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The old code used a separate HToInt32 instruction which had a wrong register
constraint for the input register which caused wrong result when the stored value
is used after a typed array store. (UseRegister instead of UseTempRegister) when no
SSE3 is available.
This change fixes it by replacing HToInt32 with the corresponding HChange
instruction which has correct register contraints.
TEST=mjsunit/compiler/regress-toint32.js
Review URL: https://chromiumcodereview.appspot.com/9565007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10891 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL is a step towards removing ZoneObject's new operator without a Zone
parameter, which uses Isolate::Current. For e.g. the bulletben benchmark, this
CL reduces the number of calls to this new operator by roughly 120k, but we are
still left with 780k calls from other sites...
Review URL: https://chromiumcodereview.appspot.com/9487010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10860 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Modify PreProcessOsrEntry to work with OSR entries that have non-empty expression stack.
Modify graph builder to take for-in state from environment instead of directly referencing emitted instructions.
Extend %OptimizeFunctionOnNextCall with an argument to force OSR to make writing OSR tests easier: %OptimizeFunctionOnNextCall(f, "osr").
R=fschneider@chromium.org
TEST=test/mjsunit/compiler/optimized-for-in.js
Review URL: https://chromiumcodereview.appspot.com/9431030
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10796 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Only JSObject enumerables with enum cache (fast case properties, no interceptors, no enumerable properties on the prototype) are supported.
HLoadKeyedGeneric with keys produced by for-in enumeration are recognized and rewritten into direct property load by index. For this enum-cache was extended to store property indices in a separate array (see handles.cc).
New hydrogen instructions:
- HForInPrepareMap: checks for-in fast case preconditions and returns map that contains enum-cache;
- HForInCacheArray: extracts enum-cache array from the map;
- HCheckMapValue: map check with HValue map instead of immediate;
- HLoadFieldByIndex: load fast property by it's index, positive indexes denote in-object properties, negative - out of object properties;
Changed hydrogen instructions:
- HLoadKeyedFastElement: added hole check suppression for loads from internal FixedArrays that are knows to have no holes inside.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9425045
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10794 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This extends the current support for nested object literals we already
have in Crankshaft, to also support nested array literals and mixed
nested literals containing arrays and objects. All three types are
generated by the unified HFastLiteral instruction.
All previous upper bounds on nested literal graphs remain unchanged,
keeping the size of generated code in check.
The main intention is to boost performance of two-dimensional array
literals containing constant elements (aka. matrices).
R=danno@chromium.org
TEST=mjsunit/compiler/literals-optimized
Review URL: https://chromiumcodereview.appspot.com/9403018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10734 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change enables optimization of top-level and eval-code. For this to work, it adds
support for declaring global variables in optimized code.
At the same time it disables the eager generation of deoptimization support data
in the full code generator (originally introduced in
r10040). This speeds up initial compilation and saves
memory for functions that won't be optimized. It requires
recompiling the function with deoptimization
support when we decide to optimize it.
Review URL: https://chromiumcodereview.appspot.com/9187005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10700 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Until now we only could inline as specialized HIR instructions when called
as a method (e.g. Math.abs)
It is very common practice to abbreviate calls to those functions by defining
a global or local variable like:
var a = Math.abs;
var x = a(123);
This change allows inlining them when called as a function (global or local).
Review URL: https://chromiumcodereview.appspot.com/9365013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10640 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1. Instead of checking upfront and estimating a limit for the number, we
now are able to stop register allocation and bailout when we don't
have enough virtual registers.
2. GCed some out-dated flags from flag-definition.h
3. Simplified the interface from the Lithium builder to the
register allocator in lithium-*.cc: For uses and definitions, we
just record the virtual register number given by the Hydrogen value id.
For temporaries, we request a new virtual register from the allocator.
For fixed temps, we don't need to do anything.
4. Increased number of deoptimization entries to 16K. Eventually we
probably want to make this array grow dynamically.
Review URL: https://chromiumcodereview.appspot.com/9325019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10597 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Yak shaving for map sharing with accessor properties contd.: When CALLBACKS can
have map transitions, simply looking at the property type is not sufficient
anymore to decide if a property is there or not. One has to look at the actual
contents of the descriptor entry then, but this breaks down sometimes when the
lookup is being done with a NULL holder. Luckily enough, we can oftren replace
IsProperty by the simpler IsFound, because we inspect the type immediately
afterwards, anyway.
Review URL: https://chromiumcodereview.appspot.com/9280007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10474 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Loosen the requirement for Map equivalency on several map checks, including checks up the prototype chain, that are not sensitive to ElementsKinds. These selected map checks should also match against FAST_DOUBLE_ELEMENT and FAST_ELEMENT transitions of the original map. This specifically helps all variants of transitioned JSArrays to still efficiently call builtins like push, pop and sort.
BUG=none
TEST=none
Committed: http://code.google.com/p/v8/source/detail?r=10331
Review URL: http://codereview.chromium.org/9015020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10356 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Loosen the requirement for Map equivalency on several map checks, including checks up the prototype chain, that are not sensitive to ElementsKinds. These selected map checks should also match against FAST_DOUBLE_ELEMENT and FAST_ELEMENT transitions of the original map. This specifically helps all variants of transitioned JSArrays to still efficiently call builtins like push, pop and sort.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/9015020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10331 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL adds support for loading from and storing to context slots
belonging to harmony let or const bound variables. Checks for the
hole value are performed and the function is deoptimized if they fail.
The full-codegen generated code will take care of properly throwing
a reference error in these cases.
TEST=mjsunit/harmony/block-let-crankshaft.js
Review URL: http://codereview.chromium.org/8820015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Now with arm and x64 support. Additionally, added default unreachable case to switch statement in CompareIC::TargetState to make win and mac compilers happy.
Reviewer guide:
This is an exact copy of 10216 except:
src/arm/*
src/x64/*
src/ic.cc (added default case to swith in CompareIC::TargetState)
Review URL: http://codereview.chromium.org/8872060
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10219 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes specialcasing the generation when we know that the maps
of the two objects are the same. In addition, a new specialized
compare ic known objects cache is created.
The reason for the cache is that we need to have access to the stub
code from the roots; if we do not, the GC will collect the stub. In
this specialized case we use the map pointer as key in the cache, and
we always do a lookup before generating code. Actually hitting
something in the cache will happen very rarely, but we could
potentially overwrite an existing stub, which again will lead to the
GC collecting this old stub (even if it is referenced from other code
objects)
Review URL: http://codereview.chromium.org/8520006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10216 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is the first CL in a series that add support for the harmony scoping
features to crankshaft. This CL specifically adds support for stack
allocated 'let' and 'const' declared variables in function scopes.
TEST=mjsunit/harmony/block-let-crankshaft.js
Review URL: http://codereview.chromium.org/8806012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10171 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
So far we had two types of stack checks: one used for function entries
and one used at loop back edges which uses a deferred code object to
avoid spilling of registers in the loop.
After refactoring lazy deoptimization the first stack check can also
use deferred code. This change removes the first type of stack check
instruction in Crankshaft and uses a deferred stack check in all
places.
Review URL: http://codereview.chromium.org/8775002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10118 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.
The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.
This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
ResolvePossiblyDirectEval, InitializeVarGlobal,
DeclareGlobals
The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache
Review URL: http://codereview.chromium.org/8417035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This generates optimized code for deep-copying of nested object literal
boilerplates which are statically known. Most of the boilerplates have
already been generated at crankshaft time, so this optimization should
kick in for virtually every object literal. Only nested object literal
graphs up to a certain depth and containing up to a certain total number
of properties are considered for this optimization. This will prevent
explosion of code size due to large object literals (e.g. eval on JSON).
Improves splay performance because object literals are created often.
R=fschneider@chromium.org
Review URL: http://codereview.chromium.org/8640001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10061 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In case of a degenerated CFG like in the example below processing
predecessors in the wrong order yields n^2 runtime.
do {
if (x) break;
if (x) break;
if (x) break;
if (x) break;
if (x) break;
if (x) break;
if (x) break;
if (x) break;
if (x) break;
if (x) break;
if (x) break;
// etc.
} while (false);
Reversing iteration order avoids this.
Review URL: http://codereview.chromium.org/8502012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9905 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This was pretty heavyweight. It was kept in just for a few corner cases
that assumed it was there. We can work around them by making sure that the
expression in a reified test context is always really the expression that
was visited in that context; and by inspecting the context manually and
consing up a pair of extra AST IDs for the unusual case of unary not in a
value AST context.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8386037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9863 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change fixes a off-by-one level error when dropping the
function from the environment. The function of the outermost
environment was not dropped.
BUG=v8:1785
TEST=test/mjsunit/compiler/regress-inline-callfunctionstub.js
Review URL: http://codereview.chromium.org/8341019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9789 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements block scoped 'const' declared variables in harmony mode. They
have a temporal dead zone semantics similar to 'let' bindings, i.e. accessing
uninitialized 'const' bindings in throws a ReferenceError.
As for 'let' bindings, the semantics of 'const' bindings in global scope is not
correctly implemented yet. Furthermore assignments to 'const's are silently
ignored. Another CL will introduce treatment of those assignments as early
errors.
Review URL: http://codereview.chromium.org/7992005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change is based on my previous change enabling inlining calls-as-function
fixing the bugs related to deoptimization.
The function value on top of the environment was dropped too late in the old code.
As a result we could get a wrong value on top after deoptimization.
This change includes r9619. It was reverted because of test failures that are fixed
with this patch.
Review URL: http://codereview.chromium.org/8360001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9758 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Named function expression have an implicit local variable that
refers to the current function (ThisFunction). Before we only could inline
anonymous function expressions like:
A.prototype.foo = function() {}
as opposed to
A.prototype.foo = function foo() {}
This change enables inlining function of expressions like this.
Review URL: http://codereview.chromium.org/8346032
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9699 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This time, we initially leave the HTypeof instruction in the Hydrogen graph,
even for the special cases. We later try to remove this instruction (and any
HConstant) in the canonicalization pass, if possible. Always removing the
HTypeof during the initial graph construction is wrong if e.g. it is used in an
HSimulate.
The removals can be generalized a bit, but this will happen in a separate CL.
TEST=mjsunit/optimized-typeof.js
Review URL: http://codereview.chromium.org/8334021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9688 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1. Record AST id for CallFunctionStub.
2. Correctly extract cached target from CallFunctionStub inline cache.
3. Fix a bug when inling call as a function in effect or value context:
Handle abnormal exits correcty.
4. Fix a bug when inlining call as a function in test context: drop function
correctly from true and false block.
5. Avoid inlining mutually recursive functions by checking the stack of function
states before inlining. This was not a bug, but is just a more general
check to avoid recursive inlining.
Review URL: http://codereview.chromium.org/8258012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9619 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously, comparisons against null/undefined and comparisons of the result of
typeof against a constant string were done syntactically. Now we do this via
pattern matching on the hydrogen graph, which opens up more opportunities for
better code generation, e.g. the following comparisons are now recognized to be
special:
var bar = typeof foo;
var baz = "undefined";
if (bar == baz) ...
var blah = undefined;
if (hurz == blah) ...
If we did this handling of special cases even later at lithium generation time,
even more cases could be recognized, but this would involve bigger changes and
this CL handles most common cases.
Review URL: http://codereview.chromium.org/8242002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9612 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This eliminates compile-errors when assigning Handle<SerializedScopeInfo> to
Handle<Object> in a place where the declaration was not available because
variables.h was not included.
As a result I had to also move the enum Variable::Mode to v8globals.h and
rename it to VariableMode.
Review URL: http://codereview.chromium.org/8221004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9575 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
