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
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
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
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
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
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
