Avoid patching code after the call to binary operation stub in optimized code

Avoid patching code after the call to binary operation stub in optimized code

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

Committed: http://code.google.com/p/v8/source/detail?r=8623

[danno, 2011-07-13 08:11:10]

LGTM.

http://codereview.chromium.org/7350015/diff/1/src/arm/lithium-codegen-arm.cc
File src/arm/lithium-codegen-arm.cc (right):

http://codereview.chromium.org/7350015/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:1516: __ nop();  // Signals no inlined code.
Is it at all possible to create something like CallBinaryOpStub to ensure that a
nop or the correct test always gets inserted? Seems like we should try to make
it very difficult to forget to insert the nop.

[danno, 2011-07-13 08:11:11]

LGTM.

[Søren Thygesen Gjesse, 2011-07-13 09:26:15]

http://codereview.chromium.org/7350015/diff/1/src/arm/lithium-codegen-arm.cc
File src/arm/lithium-codegen-arm.cc (right):

http://codereview.chromium.org/7350015/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:1516: __ nop();  // Signals no inlined code.
On 2011/07/13 08:11:10, danno wrote:
> Is it at all possible to create something like CallBinaryOpStub to ensure that
a
> nop or the correct test always gets inserted? Seems like we should try to make
> it very difficult to forget to insert the nop.

I am not sure, we already have special handling in CallCodeGeneric. The patch
which had regressions is probably the right way, and if we can find a faster way
to checking whether we are calling from optimized code or not it can all be
handled in the runtime performing the patch.