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
Until now we always recorded two deoptimization environments for instructions
that are marked as calls. We actually don't need two for all LIR
instructions except one (LInstanceOfKnownGlobal) where there is a lazy
deoptimization point in deferred code.
This change remove on of them and uses one virtual function instead
to make LInstanceOfKnownGlobal work as before.
Additionally, this change removes an unused predicate save_doubles_ from LIR
instructions and removes some helper functions that are used only in one place.
Review URL: https://chromiumcodereview.appspot.com/10035021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11454 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
Some GWT compiled code results in array access that has a heap number (e.g. -0)
as an index. Until now this would result in a generic IC.
For example:
a[-0] === a[0] or
a[0.25 * 4] === a[1]
This change detects heap numbers that are representable as a smi
and converts them. As a result we can still use the fast keyed monomorphic
ICs. Optimized code already handles keyed access with a double-key efficiently.
As a result the frame rate on the reported benchmark improves by roughly 2x.
BUG=v8:1388,v8:1295
Review URL: https://chromiumcodereview.appspot.com/9837109
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11282 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
regexp can match by using a Boyer-Moore-like table. This is done by identifying
non-greedy non-capturing loops in the nodes that eat any character one at a time.
For example in the middle of the regexp /foo[\s\S]*?bar/ we find such a loop.
There is also such a loop implicitly inserted at the start of any non-anchored
regexp.
When we have found such a loop we look ahead in the nodes to find the set of
characters that can come at given distances. For example for the regexp
/.?foo/ we know that there are at least 3 characters ahead of us, and the sets
of characters that can occur are [any, [f, o], [o]]. We find a range in the
lookahead info where the set of characters is reasonably constrained. In our
example this is from index 1 to 2 (0 is not constrained). We can now look 3
characters ahead and if we don't find one of [f, o] (the union of [f, o] and
[o]) then we can skip forwards by the range size (in this case 2).
For Unicode input strings we do the same, but modulo 128.
We also look at the first string fed to the regexp and use that to get a hint
of the character frequencies in the inputs. This affects the assessment of
whether the set of characters is 'reasonably constrained'.
We still have the old lookahead mechanism, which uses a wide load of multiple
characters followed by a mask and compare to determine whether a match is
possible at this point.
Review URL: http://codereview.chromium.org/9965010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11204 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
To do this, we collect all accessor properties in a first pass and emit code for
defining those properties afterwards in a second pass.
As a finger exercise, the table used for collecting accessors has a (subset of
an) STL-like iterator interface, including STL-like names and operators.
Although C++ is quite verbose here (as usual, but partly this is caused by our
current slightly clumsy classes/templates), things work out quite nicely and it
cleans up some confusion, e.g. a table entry is not an iterator etc.
Everything compiles into very efficient code, e.g. the loop condition 'it !=
accessor_table.end()' compiles into a single 'testl' instruction on ia32.
+1 for using standard APIs!
Review URL: https://chromiumcodereview.appspot.com/9691040
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11051 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change includes two CLs by pliard@chromium.org:
1. http://codereview.chromium.org/9447052/ (Add CallOnce() and simple LazyInstance implementation):
Note that this implementation of LazyInstance does not handle global destructors (i.e. the lazy instances are never deleted).
This CL was initially reviewed on codereview.appspot.com:
http://codereview.appspot.com/5687064/
2. http://codereview.chromium.org/9455088/ (Remove static initializers in v8):
This CL depends on CL 9447052 (adding CallOnce and LazyInstance).
It is based on a patch sent by Digit.
With this patch applied, we have only one static initializer left (in atomicops_internals_x86_gcc.cc). This static initializer populates a structure used by x86 atomic operations. It seems that we can hardly remove it. If possible, it will be removed in a next CL.
This CL also modifies the presubmit script to check the number of static initializers.
BUG=v8:1859
Review URL: https://chromiumcodereview.appspot.com/9666052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously, there were 1 or 2 calls to the runtime when accessors were changed
or set. This doesn't really work well with property attributes, leading to some
hacks and complicates things even further when trying to share maps in presence
of accessors. Therefore, the runtime entry now takes the full triple (getter,
setter, attributes), where the getter and/or the setter can be null in case they
shouldn't be changed.
For now, we do basically the same on the native side as we did before on the
JavaScript side, but this will change in future CLs, the current CL is already
large enough.
Note that object literals with a getter and a setter for the same property still
do 2 calls, but this is a little bit more tricky to fix and will be handled in a
separate CL.
Review URL: https://chromiumcodereview.appspot.com/9616016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10956 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
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
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
CPU-eating DOS attacks against node.js servers. Based on code from
Bert Belder. This version only solves the issue for those that compile
V8 themselves or those that do not use snapshots. A snapshot-based
precompiled V8 will still have predictable string hash codes.
Review URL: http://codereview.chromium.org/9086006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10330 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This introduces an additional check into the StoreIC_ArrayLength builtin
checking that the array still has fast properties. Redifinitions of the
length property that would cause it's type or attributes to change, will
switch to slow properties, thereby invalidating said optimization.
R=svenpanne@chromium.org
BUG=v8:1756
TEST=test262
Review URL: http://codereview.chromium.org/8895025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10254 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
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 shaves 416+ KB, just under 1% off the size of the debug d8 executable
on Linux (mostly because the CheckHelper functions for assertions were
getting separate copies for each compilation unit). The difference in
release builds is negligible---a size reduction of 0.1%.
Also, change namespace-level 'static const' variables to remove the static
storage class as it's the default.
R=danno@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8680013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10083 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
Changes the way we do lazy deoptimization:
1. For side-effect instructions, we insert the lazy-deopt call at
the following LLazyBailout instruction.
CALL
GAP
LAZY-BAILOUT ==> lazy-deopt-call
2. For other instructions (StackCheck) we insert it right after the
instruction since the deopt targets an earlier deoptimization environment.
STACK-CHECK
GAP ==> lazy-deopt-call
The pc of the lazy-deopt call that will be patched in is recorded in the
deoptimization input data. Each Lithium instruction can have 0..n safepoints.
All safepoints get the deoptimization index of the associated LAZY-BAILOUT
instruction. On lazy deoptimization we use the return-pc to find the safepoint.
The safepoint tells us the deoptimization index, which in turn finds us the
PC where to insert the lazy-deopt-call.
Additional changes:
* RegExpLiteral marked it as having side-effects so that it
gets an explicitlazy-bailout instruction (instead of
treating it specially like stack-checks)
* Enable target recording CallFunctionStub to achieve
more inlining on optimized code.
BUG=v8:1789
TEST=jslint and uglify run without crashing, mjsunit/compiler/regress-lazy-deopt.js
Review URL: http://codereview.chromium.org/8492004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Original commit message:
Add a level of indirection to exception handler addresses.
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets. The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.
R=vegorov@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8538011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9977 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets. The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.
R=vegorov@chromium.org,fschneider@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8462010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9975 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
Previously we omitted all cases where the global eval property was shadowed,
even if by a variable holding the same value. ES5 requires us to treat these
as direct calls.
We still throw if calling indirect eval with a detached global object.
BUG=v8:994
TEST=mjsunit/eval.js
Review URL: http://codereview.chromium.org/8343054
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9838 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This function relies on a number of helpers for checking prototypes and
probing dictionaries. It is not possible to wrap these helpers to retry
after allocation failure in a safe way---the assembler has no way to undo
what it has already assembled.
These functions have all been duplicated with handle and raw versions. The
raw versions will eventually be removed completely.
R=ulan@chromium.org,vegorov@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8332003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9769 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
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 refactoring (almost) gets rid of the requirement to get the target
object address for an object pointer embedded in code objects. This is
not possible on MIPS as pointers are encoded using two instructions. All
usages of RelocInfo::target_object_address() are (almost) obsoleted by
this change. The serializer still uses it, so MIPS will not yet work
with snapshots turned on.
R=danno@chromium.org,vegorov@chromium.org
Review URL: http://codereview.chromium.org/8245007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9597 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
Currently we avoid checking for the hole value after array loads, if the
result is only used by instructions that definitely deoptimize in case
of the hole value (HChange instructions).
This change performs the same procedure for loading from deleteable/read-only
global variable where we can also avoid the check in the same cases.
Review URL: http://codereview.chromium.org/8054008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9453 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
All slots that were recorded on these objects during incremental marking should be ignored as they are no longer valid.
To filter such invalidated slots out during slots buffers iteration we set all markbits under the invalidated code object to 1 after the code space was swept and before slots buffers are processed.
R=erik.corry@gmail.com
BUG=v8:1713
TEST=test/mjsunit/regress/regress-1713.js
Review URL: http://codereview.chromium.org/7983045
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9402 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This prevents potential misuse of SeqString::kHeaderSize as in the
case of live byte counting in incremental marking stub. All stubs
picked up the undefined size constant SeqString::kHeaderSize, thus
the computed size of all strings was off by two pointers slots.
R=lrn@chromium.org
BUG=v8:1672
TEST=mjsunit/object-seal.js,...
Review URL: http://codereview.chromium.org/7971009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9349 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Although this patch is not small, most parts of it are rather mechanical:
* First of all, the concept of a 'nil-like' value is introduced, which can be
null or undefined. They are treated symmetrically regarding comparisons, so
it makes sense to handle them in a uniform manner. It is a mystery why
JavaScript defines two of those beasts, when even *one* is a design wart...
* Extended and renamed a few things which now handle undefined in addition to
null.
* Made the parts of the full code generator and the hydrogen generation which
deal with comparisons a bit more similar regarding their handling of special
cases.
* Refactored the syntactical detection of special cases for comparisons,
hopefully making them a bit more readable and less copy-n-paste-oriented.
Things like this should really be a one-liner in any sane programming
language... :-P
* Cut down the length of the argument lists of a few functions to something
less insane, making them more easily understandable locally. This involves
minor code duplication, but this was a good tradeoff and can be remedied
later if necessary.
* Replaced some boolean arguments with more readable enums.
* Fixed a TODO: Values which are definitely a Smi or unboxed can never be equal
to null or undefined.
Review URL: http://codereview.chromium.org/7918012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9323 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1) Don't make a call to C without having a valid frame on the stack.
2) Don't generate a call to a stub while generating a stub, unless we can be
sure that the stub we are calling has already been generated (the stub
generation code is not reentrant wrt. GC).
Review URL: http://codereview.chromium.org/7891042
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9297 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The Great Master Plan is to move the recognition of special cases for
comparisons further down the compilation pipeline where more information is
available. This is a first step into this direction: The special handling of
equality comparisons involving null is pushed from the parser to the code
generators, removing the need for a special AST node. (There are rumors from
usually well-informed sources that this node type is actually a relic of ancient
crankshaft days...)
The next steps will be the unification of null/undefined handling and pushing
the special case handling in crankshaft even further down the pipeline, enabling
the recognition of cases like "var foo=null; if (foo === bar) ...", but these
will be in separate CLs.
Review URL: http://codereview.chromium.org/7887037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9293 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Use the BitField helper class for the code flags, so that we do not have to
define both a shift and a mask explicitly. This makes changing the flags
layout simpler.
Also, make the 'mask' and 'max' members of BitField into constants, because
they are constant and so that they can be used as constant expressions.
E.g., so they can be used in declaring other const members or in static
asserts.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/7787028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9232 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The changes to scopes and parser introduce a VariableProxy
wrapping the function-name variable for function literals.
It seems the easiest way to get an AST id for the HSimulate
after context-slot stores in declarations.
Review URL: http://codereview.chromium.org/7826009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We have to emit code for declarations later into the body block
(and not into the start block) so that the environment contains
the correct values.
In order to capture the environment effect of the declarations
that generate code (function declarations) I inserted a separate
AST id and a HSimulate after the declarations are visited.
Also fixes handling deopt in named function expressions:
BUG=v8:1647
TEST=test/mjsunit/regress/regress-fundecl.js, test/mjsunit/regress/regress-1647.js
Review URL: http://codereview.chromium.org/7776009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9083 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The ARM and MIPS assemblers had a bug where they did not handle the last element
in the list of code positions correctly during the fixup of offsets for forward
jumps. This happened when the first instruction contained a forward jump to a
label, and that label was used in a forward jump later, too.
Unified the code for Assembler::next on ARM and MIPS while we were there.
Added test cases, even for ia32/x64, which seem to be correct, even I don't
fully understand why... %-}
BUG=v8:1644
Review URL: http://codereview.chromium.org/7786001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9063 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changes GetGlobalReceiver() to GetDefaultReceiver(func) that returns undefined
for strict and native functions, and the function's context's global proxy
for "normal" functions.
BUG=v8:1547
TEST=cctest/api-test/ForeignFunctionReceiver
Review URL: http://codereview.chromium.org/7741042
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9030 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Remove the try/finally used for with and catch. Instead of using
try/finally to handle break and continue from with or catch,
statically track nesting dept and clean up when compiling break or
continue.
And instead of using try/finally to handle throw to handler in a frame
whose pc is inside a with or catch, store the context that the handler
should run in in the handler itself.
BUG=
TEST=
Review URL: http://codereview.chromium.org/7618007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8922 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Non-ancient versions of the ARM-ARM explicitly deprecate most uses of the PC
within instructions and older ARM implementations have a non-predictable offset
(8 or 12) for some of these deprecated uses. Avoiding the deprecated instruction
costs us one additional instruction in DirectCEntryStub::GenerateCall, but this
should not cause any significant performance degradation.
The deoptimizer still uses the PC in a stm instruction, but it is a bit unclear
what to do about that, so simply a comment has been added to reconsider this in
the future.
Review URL: http://codereview.chromium.org/7633014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8916 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changing our builtin JavaScript code slightly, we can make sure that we never
see internal objects as arguments for ToBoolean at runtime. Removing that case
from the stub generator and crankshaft makes things a lot easier.
Heap numbers can never be undetectable (only strings and spec objects can), so
we can leave out a useless test.
Try to re-use a non-null register value when returning 'true' in some cases.
Removed special handling of the 'handle all' case, it will very probably never
happen in real code and only makes things more complicated.
Improved naming of the ToBoolean stubs a bit, reflecting the order in which
cases are handled in the code itself.
Review URL: http://codereview.chromium.org/7497063
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8886 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Bug fix for range analysis (contributed by Andy Wingo). Ranges of
double values have to include negative zero. Original code review:
http://codereview.chromium.org/7514040/
* Fix a bug in optimized Math.round on ARM. When emitting minus-zero checks
we previously return a wrong result because of incorrect register assignment.
* Fix performance problem in IA32 and x64. Refine the checks
for minus zero and avoid unnecessary deoptimizations on Math.floor.
* Improve mjsunit test for Math.round to make sure we also
get the optimized version of the code for each test case.
Review URL: http://codereview.chromium.org/7604028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8877 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When creating a CompilationInfo we always have the script and can
determine if it is a natives script.
Now that all natives functions are recognized as such, many of them
are called with undefined as the receiver. We have to use different
filtering for builtins functions when printing stack traces.
Also, fixed one call of CALL_NON_FUNCTION to be correctly marked as a
method call (with fixed receiver). Now that CALL_NON_FUNCTION is
marked as a native function this caused the receiver to be undefined.
R=svenpanne@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/7395030
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8680 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
C++'s 'great' idea of implicitly converting an enum to an integral value hit us
again, this time resulting in silly (but currently non-harmful) entries in the
relocation table. Encapsulated the AST ID recording a bit, which helped a lot to
find the culprit.
Review URL: http://codereview.chromium.org/7400016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8671 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Using a C++-style method PrintName (a.k.a. << ;-), things get a lot easier when
two unrelated concerns are separated. Stubs don't need a name cache anymore,
simpler code while generating the stub name, memory allocation is centralized,
etc.
Review URL: http://codereview.chromium.org/7342042
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8627 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch just adds a nop after the call to the binary operation stub in optimized code to avoid the patching for the inlined smi case used in the full code generator to kick in if the next instruction generated by the lithium code generator should accidentially enable that. For calls generated by CallCodeGeneric this was already handled on Intel platforms, but missing on ARM.
On IA-32 I did also try to check for whether the code containing the call was optimized (patch below), but that caused regressions on some benchmarks.
diff --git src/ia32/ic-ia32.cc src/ia32/ic-ia32.cc
index 5f143b1..f70e208 100644
--- src/ia32/ic-ia32.cc
+++ src/ia32/ic-ia32.cc
@@ -1603,12 +1603,18 @@ void CompareIC::UpdateCaches(Handle<Object> x, Handle<Object> y) {
// Activate inlined smi code.
if (previous_state == UNINITIALIZED) {
- PatchInlinedSmiCode(address());
+ PatchInlinedSmiCode(address(), isolate());
}
}
-void PatchInlinedSmiCode(Address address) {
+void PatchInlinedSmiCode(Address address, Isolate* isolate) {
+ // Never patch in optimized code.
+ Code* code = isolate->pc_to_code_cache()->GetCacheEntry(address)->code;
+ if (code->kind() == Code::OPTIMIZED_FUNCTION) {
+ return;
+ }
+
// The address of the instruction following the call.
Address test_instruction_address =
address + Assembler::kCallTargetAddressOffset;
diff --git src/ic.cc src/ic.cc
index f70f75a..62e79da 100644
--- src/ic.cc
+++ src/ic.cc
@@ -2384,7 +2384,7 @@ RUNTIME_FUNCTION(MaybeObject*, BinaryOp_Patch) {
// Activate inlined smi code.
if (previous_type == BinaryOpIC::UNINITIALIZED) {
- PatchInlinedSmiCode(ic.address());
+ PatchInlinedSmiCode(ic.address(), isolate);
}
}
diff --git src/ic.h src/ic.h
index 11c2e3a..9ef4b20 100644
--- src/ic.h
+++ src/ic.h
@@ -721,7 +721,7 @@ class CompareIC: public IC {
};
// Helper for BinaryOpIC and CompareIC.
-void PatchInlinedSmiCode(Address address);
+void PatchInlinedSmiCode(Address address, Isolate* isolate);
} } // namespace v8::internal
R=danno@chromium.org
BUG=none
TEST=none
Review URL: http://codereview.chromium.org//7350015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8623 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The preprocessor defines ENABLE_LOGGING_AND_PROFILING and ENABLE_VMSTATE_TRACKING has been removed as these where required to be turned on for Crankshaft to work. To re-enable reducing the binary size by leaving out heap and CPU profiler a new set of defines needs to be created.
R=ager@chromium.org
BUG=v8:1271
TEST=all
Review URL: http://codereview.chromium.org//7350014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8622 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
architecture-independent.
jsregexp.h is itself included transitively quite a lot, and by getting rid of 19
of its dependencies (which even included things like src/cpu.h, the various
assemblers, etc.), the recompilation behaviour is a bit less funny than it was.
Review URL: http://codereview.chromium.org/7331014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8589 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The debugger can be entered from the deferred stack check in optimized code. This can cause both lazy deoptimization and debugger deoptimization (setting the first break point and inspecting the stack for optimized code respectively). This required deoptimization support from the deferred stack check.
The lazy deoptimiztion call is inserted when the deferred code is done including restoring the registers. The bailout to the full code is the begining of the loop body as that is where the stack check is sitting in the optimized code. The bailout is not to the stack check in the full code as that is sitting at the end of the loop.
R=kmillikin@chromium.org
BUG=none
TEST=none
Review URL: http://codereview.chromium.org//7212025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8535 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Due to issues relating mostly to chrome extensions we have lately been
running into OOMs that are caused by our executable space running
out. This change introduces flushing of code from regexps if we have
not used the code for 5 mark sweeps.
The approach is different from the normal function code flusing. Here
we make a copy of the code inside the data array, and exchange the
original code with a smi determined by the sweep_generation (a new
heap variable increased everytime we do mark sweep/compact). If we
encounter a smi in EnsureCompiled we simply reinstate the code
object. If, in the marking phase of mark sweep, we find a regexp that
already have a smi in the code field, and this is more than 5
generations old we flush the code from the saved index.
Review URL: http://codereview.chromium.org/7282026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8532 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Eliminates the enum flag RESTORE_CONTEXT and CONTEXT_ADJUSTED, and adds a context HValue and LOperand to many hydrogen and lithium instructions.
Context is still used from the stack from in CallKnownFunction (this seems safe), and in CallRuntimeFromDeferred in lithium-codegen-ia32.cc, which needs to be fixed.
BUG=
TEST=
Review URL: http://codereview.chromium.org/7132002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8529 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The catch variable is bound in the catch scope. For simplicity in this
initial implementation, it is always allocated even if unused and always
allocated to a catch context even if it doesn't escape. The presence of
catch is no longer treated as a with.
In this change, care must be taken to distinguish between the scope where a
var declaration is hoisted to and the scope where the initialization occurs.
R=ager@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/7280012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8496 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Optimized frames are now handled by the debugger. When discovering optimized frames during stack inspection in the debugger they are "deoptimized" using the normal deoptimization code and the deoptimizer output information is used to provide frame information to the debugger.
Before this change the debugger reported each optimized frame as one frame no matter the number of inlined functuions that might have been called inside of it. Also all locals where reported as undefined. Locals can still be reposted as undefined when their value is not "known" by the optimized frame.
As the structures used to calculate the output frames when deoptimizing are not GC safe the information for the debugger is copied to another structure (DeoptimizedFrameInfo) which is registered with the global deoptimizer data and processed during GC.
R=fschneider@chromium.org
BUG=v8:1140
TEST=test/mjsunit/debug-evaluate-locals-optimized*
Review URL: http://codereview.chromium.org//7230045
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8464 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Before: every context cached the nearest enclosing function context. This
assumed that for nested contexts (i.e., with and catch contexts) the
enclosing function had a materialized link in the context chain.
Now: when necessary, we loop up the context chain to find such a context.
This enables catch contexts without forcing the enclosing function to
allocate its own context.
R=ager@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/7230047
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8452 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/hydrogen.cc (HEnvironment::CopyForInlining): As the code for both
the ::HYDROGEN and ::LITHIUM compilation phases is the same, just use
one code path and remove the arg.
* src/hydrogen.h (HEnvironment): Remove now-unused CompilationPhase
enum type and arg to CopyForInlining.
* src/arm/lithium-arm.cc (LChunkBuilder::DoEnterInlined):
* src/ia32/lithium-ia32.cc (LChunkBuilder::DoEnterInlined):
* src/x64/lithium-x64.cc (LChunkBuilder::DoEnterInlined): Adapt
callers.
* AUTHORS: Add Igalia.
BUG=
TEST=I ran tools/test.py.
Review URL: http://codereview.chromium.org/7272002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8442 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The hydrogen stack check instruction is now added to each loop and the stack check handling on the back edge has been removed.
This change causes regression on small tight loops as the stack check is now at the top of the loop instead of at the bottom, and that requires one additional unconditional jump per loop iteration. However the reason for this change is to avoid worse regressions for upcoming changes to correctly support debugger break in optimized code.
R=fschneider@chromium.org
BUG=none
TEST=none
Review URL: http://codereview.chromium.org//7216009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8428 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Detect the pattern in both, the full compiler and crankshaft and generate direct pointer
comparisons. Along the way I cleaned up 'typeof <expression> == <string literal>' comparisons
as well by lifting platform independent code and checking the symmetric case.
BUG=v8:1440
TEST=cctest/test-api.cc
Review URL: http://codereview.chromium.org/7216008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8420 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reverts r8381.
It was causing Mozilla test mozilla/ecma/Date/15.9.3.8-5 to fail and Sputnik tests S15.9.3.1_A5_T5, S15.9.3.1_A5_T1, S15.9.3.1_A5_T2, S15.9.3.1_A5_T4, S15.9.3.1_A5_T3 and S15.9.3.1_A5_T6 to timeout.
R=ager@chromium.org
BUG=none
TEST=mozilla/ecma/Date/15.9.3.8-5, S15.9.3.1_A5_T5, S15.9.3.1_A5_T1, S15.9.3.1_A5_T2, S15.9.3.1_A5_T4, S15.9.3.1_A5_T3 and S15.9.3.1_A5_T6
Review URL: http://codereview.chromium.org//7246004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8397 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The declaration of the ToBoolean class moved to the platform-independent part
and its implementations are now structurally very similar. This is just an
intermediate cleanup step to add type recording at the call site.
Note that the MIPS implementation has not really been touched, so it should
continue to work, too.
Review URL: http://codereview.chromium.org/7218012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8359 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* AST Expression nodes get a separate testing ID to record type info in
ToBooleanStub later. This is necessary to avoid clashes with other uses of
already existing IDs.
* In order to avoid threading the condition expression through tons of places,
TestContexts carry it now with them. Note that we will probably only need the
testing ID of the expression, but having the whole thing at hand makes
debugging easier. Probably we will change this later...
Review URL: http://codereview.chromium.org/7046073
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8274 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change makes the number of successors of a control instruction
configurable with a template parameter and changes the existing instructions
to use it.
To iterate over all successors I added an iterator instead of always calling
First- and SecondSuccessor.
Review URL: http://codereview.chromium.org/7114004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8262 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Introduce separate maps for function and with contexts. Use the function
context map for testing whether a context is a function context (global
contexts are no longer function contexts).
Split the paths for allocating with and catch contexts.
Rename some functions. Generally refactor code to make it simpler.
R=ager@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/7003058
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8231 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Mainly, there were errors concerning blank lines before and after class access
control sections [whitespace/blank_line].
BEFORE an access control section (e.g. public:, private:) there should be a
blank line (except for the section right after the class declaration).
AFTER an access control section there should be no blank line.
TBR=ager@chromium.org
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8193 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The Advance() function of the class responsible for iterating
environment uses didn't always advance as far as it could (relying on
the HasNext predicate to finish advancing). This is brittle.
The HasNext predicate also didn't advance as far as it could when it
was at the end of an environment level. This is a bug.
R=jkummerow@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/6993023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8181 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If type-feedback indicates that an expression was never executed in
the non-optimized code, we insert a forced deoptimization right away
to enable re-optimization if we ever hit this path.
With this change we still continue to build the graph. As a next step, we
should remove the dead code after the deoptimize.
I had to remove one assert about the optimization status in a test since
we now immediately deoptimize after exiting the loop that triggers OSR.
Also remove a restriction that control-flow from an inlined function in a
test context always reaches both true- and false-target.
Review URL: http://codereview.chromium.org/7105015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Introduce a class JSReceiver, that is a common superclass of JSObject and
JSProxy. Use JSReceiver where appropriate (probably lots of places that we
still have to migrate, but we will find those later with proxy test suite).
- Move appropriate methods to JSReceiver class (SetProperty,
GetPropertyAttribute, Get/SetPrototype, Lookup, and so on).
- Introduce new JSFunctionProxy subclass of JSProxy. Currently only a stub.
- Overhaul enum InstanceType:
* Introduce FIRST/LAST_SPEC_OBJECT_TYPE that ranges over all types that
represent JS objects, and use that consistently to check language types.
* Rename FIRST/LAST_JS_OBJECT_TYPE and FIRST/LAST_FUNCTION_CLASS_TYPE
to FIRST/LAST_[NON]CALLABLE_SPEC_OBJECT_TYPE for clarity.
* Eliminate the overlap over JS_REGEXP_TYPE.
* Also replace FIRST_JS_OBJECT with FIRST_JS_RECEIVER, but only use it where
we exclusively talk about the internal representation type.
* Insert JS_PROXY and JS_FUNCTION_PROXY in the appropriate places.
- Fix all checks concerning classification, especially for functions, to
use the CALLABLE_SPEC_OBJECT range (that includes funciton proxies).
- Handle proxies in SetProperty (that was the easiest part :) ).
- A few simple test cases.
R=kmillikin@chromium.org
Review URL: http://codereview.chromium.org/6992072
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8126 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Centralized AND/OR handling, keeping related code together.
* Removed HandleExpression/HandleInNonTestContext and introduced VisitInSameContext instead, making it more obvious what's actually going on.
* Consistently use a new context when visiting the left sub-expression of an AND/OR. Note that the context stacks in the full code generator and crankshaft are still a bit out of sync for the right sub-expression.
Review URL: http://codereview.chromium.org/6976028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8124 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The approach is to handle the common case in the optimizing
compiler and to bailout for the rare corner cases.
This is done by initializing all local const-variables with
the hole value and disallowing any use of the hole value statically.
Review URL: http://codereview.chromium.org/6026006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8104 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Only IA32 version for now. I'll start porting.
Strict mode functions are to get 'undefined' as the receiver when
called with an implicit receiver. Modes are bad! It forces us to have
checks on all function calls.
This change attempts to limit the cost by passing information about
whether or not a call is with an implicit or explicit receiver in ecx
as part of the calling convention. The cost is setting ecx on all
calls and checking ecx on entry to strict mode functions.
Implicit/explicit receiver state has to be maintained by ICs. Various
stubs have to not clobber ecx or save and restore it.
CallFunction stub needs to check if the receiver is implicit when it
doesn't know from the context.
Review URL: http://codereview.chromium.org/7039036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8040 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
KeyedLoadStubCompiler::GenerateLoadExternalArray is tail-calling a stub, which it is not allowed to, because its major key is higher than InstanceOf. Instead of changing the major key I decided to provide an inline implementation.
TEST=test-api/ExternalArrays with --noenable-vfp3
R=danno@chromium.org
Review URL: http://codereview.chromium.org/7060007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8002 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When the stub return a heap number we do a state transition to
a version HEAP_NUMBER that can handle -0.
There is room for further improvement in the typefeedback for the
case of -0. This change however does not address this and only fixes
the acute issue.
Review URL: http://codereview.chromium.org/7037025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Better support for 'polymorphic' JS and external arrays
Allow keyed store/load stubs to switch between external array and fast JS arrays without forcing a state transition to the generic stub.
There CL consists of two pieces of functionality. First, code stubs for fast element arrays don't immediately transition to the MEGAMORPHIC state when there's a map mismatch. Second, two ICs are cached per map for fast elements, the MONOMORPHIC version, and a new MEGAMORPHIC version that handles two or more different maps and dispatches to shared stubs to perform the array operation.
Review URL: http://codereview.chromium.org/7036016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7935 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As a side note, this change has some positive impact on the performace, e.g. imaging-darkroom is 8.3% faster and ws-ieee754conv is even 19.9% faster. No idea why the speedup is so big in some cases, but never look a gift horse in the mouth... ;-)
Review URL: http://codereview.chromium.org/7042004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7926 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allow keyed store/load stubs to switch between external array and fast JS arrays without forcing a state transition to the generic stub.
There CL consists of two pieces of functionality. First, code stubs for fast element arrays don't immediately transition to the MEGAMORPHIC state when there's a map mismatch. Second, two ICs are cached per map for fast elements, the MONOMORPHIC version, and a new MEGAMORPHIC version that handles two or more different maps. Currently, the only array types supported by the MEGAMORPHIC stub are fast elements for objects and JSArrays.
BUG=
TEST=
Review URL: http://codereview.chromium.org/6894003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7917 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The profiler did not correctly identify when there was a JS frame
on the stack after an exception was thrown.
I also refactored the code to use PopTryHandler macro-instructions on all platforms
BUG=73722
TEST=No more valgrind errors related to v8::internal::StackFrameIterator.
Review URL: http://codereview.chromium.org/7019010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7910 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows us to get rid of totally fake LAST_STRING_TYPE and makes
it possible to test for symbols.
I considered splitting HCheckInstanceType into two instructions, but
it seems nice to be able to hide the instance type implementation
details from the hydrogen level.
Review URL: http://codereview.chromium.org/6964011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7840 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If the result of an fast elements load is converted to an untagged
representation we can omit the hole check if the value is not used
anywhere else except for HChange instructions converting it to
an untagged representation since those will deoptimize for the hole
value anyway.
Review URL: http://codereview.chromium.org/6964012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7827 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Use a special slot for HContext, and fetch the value from there each time it is used. Allocate space for special slots in every HEnvironment. Fill them with constant undefined. Do not copy them to LEnvironment.
BUG=
TEST=
Review URL: http://codereview.chromium.org/6929066
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7807 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In my previous change I mixed up "compare" and "equals". This made us
miss the fast length check before comparing strings for equality.
Now we have a separate helper for "equals". It shares some of the
inner loop details with "compare". I'll see if this can be cleaned up
without making it unreadable.
Review URL: http://codereview.chromium.org/6928020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7794 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The only difference to revision 7763 is the implementation in the
builtins file for arm and x64, plus a move of Array.prototype.toString
and Array.prototype.toLocaleString from should throw on null or
undefined to the non generic test cases in the function-call test (due
to us not currently supporting generic cases with these to functions)
Review URL: http://codereview.chromium.org/6928007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Always use CpuFeaturesImpliedByCompiler() when selecting CPU features. This checks both for CAN_USE_ARMV7_INSTRUCTIONS and CAN_USE_VFP_INSTRUCTIONS and for GCC preprocessor symbols. This will support using the CAN_USE_XXX for a simulator build used for generating a snapshot followed by a crosscompile using -march= and -mfpu= for selecting the (minimal) target device CPU features. The snapshot will use instructions based on the CAN_USE_XXX whereas the target will at least use features based on both CAN_USE_XXX and -march= and -mfpu=, but will try runtime CPU feature detection a well looking for somethis better.
Remove the compiler based CPU feature detection from the OS::CpuFeaturesImpliedByPlatform() as it did not belong there. Also was already in the CpuFeaturesImpliedByCompiler().
Add the variable 'v8_can_use_vfp_instructions' to the GYP file which can be used to turn on CAN_USE_VFP_INSTRUCTIONS when building V8. I did not add any -mfpu= cflags for this, as there are several options here (e.g. vfp and neon).
R=erik.corry@gmail.com, karlklose@chromium.org
BUG=none
TEST=none
Review URL: http://codereview.chromium.org//6904164
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7754 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add option armeabi to the SCons build for selecting the floating point variant to use. Also add externally defined CCFLAGS environment for all targets. Run test.py with option -S armeabi=hardfloat to test with hardfloat enabled.
Make selecting hardfloat EABI variant a build-time option instead of a runtime option.
Add a simple check of the EABI variant during V8 initialization to exit if the compilation was not configured correctly. The reason for this is that GCC does not provide a compile time symbol defining the EABI variant. This check is not fool-proof as it cannot check the compilation configuration used for the snapshot if any.
R=karlklose@chromium.org, erik.corry@gmail.com
BUG=none
TEST=none
Review URL: http://codereview.chromium.org//6905098
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reduces the binary size by making the Is* type-test functions non-virtual.
I had to change Gap and Label instructions to have a common abstract superclass because both act as gap-instructions for the register allocator.
Review URL: http://codereview.chromium.org/6880204
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7691 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Rather than representing a use as a pointer to an HValue and then searching
for the specific (ambiguous) operand, we now represent a use as a pair of an
HValue and the input operand index. Additionally, use a linked list instead
of a growable array list since we never use random access.
This allows us to remove a bunch of similarly named and subtly different
functions from the HValue API. The cost in extra zone allocation per use is
partially offset by reusing use list nodes when replacing a use of one value
with another.
R=danno@chromium.org,fschneider@chromium.org
Review URL: http://codereview.chromium.org/6881044
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7674 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For instructions that are marked as calls we can use:
1. Fixed input registers
2. Use-at-start policy (register, memory or constant).
(Memory or constant would not need the use-at-start policy, but
not specifying use-at-start prevents the allocator from using
a register even if there is one available. That's why use-at-start
is required and guarded by assertion)
Review URL: http://codereview.chromium.org/6853010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7616 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The type recording binary operations stub contained a number of issues which broke V8 when running without VFPv3 supoort.
1. The order of the high/low words of doubles in core register pairs where wrong
2. Missing allocation of a heap number for the result
3. Missing call to runtime
Added the option for printing the double values in register pairs to the simulator.
R=karlklose@chromium.org
BUG=v8:1315
TEST=
Review URL: http://codereview.chromium.org//6834020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7603 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- mutual inlining strict and non-strict functions in crankshaft.
- assignment to undefined variable with eval in scope.
- propagation of strict mode through lazy compilation.
BUG=
TEST=test/mjsunit/strict-mode.js test/mjsunit/strict-mode-opt.js
Review URL: http://codereview.chromium.org/6814012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7561 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Crankshaft is now the default on all platforms. This is the first
patch on the way to removing the classic code generator from the
system.
This time with no removal of the crankshaft flag. --nocrankshaft is
not at all the same as --always-full-compiler which I had used instead
for testing. That was what caused timeouts on the buildbots because of
repeated attempts to optimize hot functions. It makes sense to keep
the crankshaft flag in case you want to run only with the full
compiler and with no adaptive compilation.
R=vitalyr@chromium.org
Review URL: http://codereview.chromium.org/6759070
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7486 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the cases where a global property cell cannot be used in the optimized code
use standard load ic to get the property instead of bailing out.
This is re-committing r7212 and r7215 which where reverted in r7239 with the addition of recoring the source position in the hydrogen code for the LoadGlobalCell instruction. To record that position an optional position field has been added to the variable proxy AST node.
Review URL: http://codereview.chromium.org/6758007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7474 ce2b1a6d-e550-0410-aec6-3dcde31c8c00