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
