Reapply optimization of DeoptimizeIf for ia32 broken in r13633.

Reapply optimization of DeoptimizeIf for ia32 broken in r13633.

R=danno@chromium.org

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

[danno, 2013-02-27 15:14:13]

lgtm

[Michael Starzinger, 2013-02-27 15:17:33]

Committed patchset #1 manually as r13767 (presubmit successful).

[Sven Panne, 2013-02-28 09:31:20]

Looking at the performance numbers, I propose to roll back this CL, because it
is not an optimization, but quite the opposite: On Core2, this change is
performance-neutral, but on i5 it shows some serious degradation, probably
caused by a worse branch prediction. Furthermore, the "optimization" itself
can't really be important, because shaving off a single instruction when we
enter the runtime or deoptimize anyway is irrelevant.

So in a nutshell: Roll it back, i5 is much more important than Core2 nowadays.

[danno, 2013-02-28 09:49:41]

Yes, weird. However, it is indeed an optimization, just not for speed but for
size. Removing the jump tables at the end of compiled code significantly reduces
the sizes of the generated crankshaft code objects. I wonder if forward/backward
jump direction plays a role. There has been no change in the shape of the code
is executed in the non-deopt case, just the target address of the branch.

[Sven Panne, 2013-02-28 10:19:28]

Well, as can be seen from the numbers, it is not a speed optimization at all:
This single CL eats up half of the performance gains on Octane in Q1 on i5 so
far and even regresses other benchmarks by >20%. Saving a single jump (5 or 6
bytes?) here and there doesn't sound like a convincing counter-argument... :-/

Regarding forward/backward jumps: I don't think that's the reason, we have a
regression across the board on i5, and this would have been cancelled out due to
ASLR. It looks like relatively local jumps which are not taken are cheap, while
non-local jumps are always costly. Although I don't know i5 internals enough,
this makes sense, because branch prediction is most useful for loop-like stuff,
which is a local thing. Trying to predict non-local jumps is much less useful,
but of course I'm only guessing here.