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

src/arm/lithium-codegen-arm.cc

Index: src/arm/lithium-codegen-arm.cc
diff --git a/src/arm/lithium-codegen-arm.cc b/src/arm/lithium-codegen-arm.cc
index ee36314209eb21a95e5c9b93a93ff3130ab0cef8..dc93aea3461da251a785470be020995d790024b0 100644
--- a/src/arm/lithium-codegen-arm.cc
+++ b/src/arm/lithium-codegen-arm.cc
@@ -551,6 +551,13 @@ void LCodeGen::CallCodeGeneric(Handle<Code> code,
   RecordPosition(pointers->position());
   __ Call(code, mode);
   RegisterLazyDeoptimization(instr, safepoint_mode);
+
+  // Signal that we don't inline smi code before these stubs in the
+  // optimizing code generator.
+  if (code->kind() == Code::BINARY_OP_IC ||
+      code->kind() == Code::COMPARE_IC) {
+    __ nop();
+  }
 }
 
 
@@ -1506,6 +1513,7 @@ void LCodeGen::DoArithmeticT(LArithmeticT* instr) {
 
   BinaryOpStub stub(instr->op(), NO_OVERWRITE);
   CallCode(stub.GetCode(), RelocInfo::CODE_TARGET, instr);
+  __ nop();  // Signals no inlined code.

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

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.

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

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.

 }