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 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
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 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
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
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
This change adds a new IR instruction for polymorphic loads. It performs
map compares and loads in one IR instruction instead of splitting each
load into a graph of map-compares and field loads.
The advantage is a smaller IR and less basic blocks, plus it allows to
do GVN on polymorphic loads.
Review URL: http://codereview.chromium.org/6708085
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7336 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Change the way we construct the graph for polymorphic loads to match that of
polymorphic stores.
Introduce a stack-allocated helper for saving and restoring all the
function-specific graph builder state that needs to change when we begin
translating an inlined function. Make this class authoritative by moving
redundant state out of the builder and deferring to the current function's
state.
Ensure that we always print a tracing message when abandoning an inlining
attempt.
Review URL: http://codereview.chromium.org/6628012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7074 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The old version only added extra space when we did indirect calls, but
the problem remains the same with normal calls that can be represented
as a single byte. When doing patching each call will always be at
least 2 bytes long because we use RUNTIME_ENTY as the reloc mode.
Review URL: http://codereview.chromium.org/6541053
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6894 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Strict mode flag is passed to runtime DELETE function
and then to JSObject::Delete(Property/Element) as STRICT_DELETION enum.
When deleting non-configurable property/eleemnt, TypeError is thrown.
Adding mozilla test to .gitignore.
Incorporate CR feedback.
Review URL: http://codereview.chromium.org/6515005/
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6782 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Make esi available to the register allocator rather than dedicating it
permanently to the context.
The context is still passed in register esi to JavaScript and to the runtime
as part of the calling convention. Because some stubs might end up calling
JS or the runtime, it is also conservatively passed to stubs.
Roughly half the calls have been modified to use the context as an input
value in fixed register esi. The other half are marked as calls or deferred
code so esi is spilled and can be explicitly set.
It is no longer necessary to restore the context to esi after a call that
might change it.
Review URL: http://codereview.chromium.org/6452001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6713 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Refactor SafepointTableBuilder::DefineSafepoint and ARM LCodeGen::RecordSafepoint to use an enum for different kinds of safepoints. This change removes a lot of duplicated code and makes it easier to include new kinds of safepoints in the future. The remaining variants of LCodeGen::RecordSafepoint remain as a convinient way to record common safepoint kinds.
BUG=http://code.google.com/p/v8/issues/detail?id=1043
TEST=none
Review URL: http://codereview.chromium.org/6341008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6505 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch adds H- and L-variants of StringCharCodeAt and StringLength.
StringCharCodeAt is used to inline a constant function call of
String.prototype.charCodeAt and to implement the corresponding inline
runtime function. It does not yet use the recently introduced extra IC
state. (We can specialize on string encoding and avoid deopts because
of out of bounds accesses.)
StringLength needs more work because the stub version of it also
supports strings wrappers and it matters in some cases. (We have to
separate the string only case.)
Review URL: http://codereview.chromium.org/6243008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6408 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instead of spilling and then immediately restoring eax to resolve
memory to memory moves, the gap move resolver now tracks registers
that are known to be free and uses one if available. If not it spills
but restores lazily when the spilled value is needed or at the end of
the algorithm.
Instead of using esi for resolving cycles and assuming it is free to
overwrite because it can be rematerialized, the gap move resolver now
resolves cycles using swaps, possibly using a free register as above.
The algorithm is also changed to be simpler: a recursive depth-first
traversal of the move dependence graph. It uses a list of moves to be
performed (because it mutates the moves themselves), but does not use
any auxiliary structure other than the control stack. It does not
build up a separate list of scheduled moves to be interpreted by the
code generate, but emits code on the fly.
Review URL: http://codereview.chromium.org/6263005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
