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