Experimental: three small codegen changes....

src/jump-target-ia32.cc

Index: src/jump-target-ia32.cc
===================================================================
--- src/jump-target-ia32.cc	(revision 927)
+++ src/jump-target-ia32.cc	(working copy)
@@ -108,7 +108,17 @@
       expected_frame_->Forget(expected_frame_->height());
     }
     if (!expected_frame_->IsMergable()) {
+      // For a branch, the frame at the fall-through basic block (not
+      // labeled) does not need to be mergable, but only the other (labeled)
+      // one.  That is achieved by reversing the condition and emitting the
+      // make mergable code as the actual fall-through block.
+      Label original_fall_through;
+      __ j(NegateCondition(cc), &original_fall_through, NegateHint(hint));
       expected_frame_->MakeMergable();
+      __ jmp(&label_);
+      __ bind(&original_fall_through);

[iposva, 2008/12/08 06:32:32]

How often do you expect this double jump to happen?

[Kevin Millikin (Chromium), 2008/12/08 08:26:28]

Only when the frame contains constants that are synched to memory and nothing
else that's problematic---then it can become mergable by just forgetting about
the constants.

I don't expect it to be the common case, but it happens right now for the stack
check on function entry where the locals are constants (the undefined value). 
For total correctness with the debugger, the stack check should probably be
special-cased and avoid the double jump but I'd still like to avoid it in other
cases too.

+    } else {
+      __ j(cc, &label_, hint);
     }
   } else {
     // No code needs to be emitted to merge to the expected frame at the
@@ -116,9 +126,8 @@
     if (!code_generator_->IsActualFunctionReturn(this)) {
       current_frame->MergeTo(expected_frame_);
     }
+      __ j(cc, &label_, hint);
   }
-
-  __ j(cc, &label_, hint);
   // Postcondition: there is both a current frame and an expected frame at
   // the label and they match.
 }