Fix issue 977, occasional failure of the DeltaBlue benchmark.

Fix issue 977, occasional failure of the DeltaBlue benchmark.

Before, when we deoptimized after a branch we jumped to before the branch
was taken in the unoptimized code with a token value that indicated when
edge to take.  There was a lot of machinery to track this value through the
short-circuit logical operations and logical negation, and to handle it
properly at inline function return sites.  There was also machinery to
prevent incorrectly seeing this environment with the extra value never
actually materialized in the unoptimized code.

Instead, now we deoptimize directly to one of the targets of the branch.
Much but not yet all of the extra machinery has been removed or simplified.
The cost is that branching control structures (the looping statements, if
statements, conditional expressions, and the short-circuit binary logical
operations) need extra AST IDs to identify the branch targets.

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

[Kevin Millikin (Chromium), 2010-12-15 17:52:54]

The failure is not simple to reproduce.  I ran DeltaBlue 564 times and it didn't
recur (it happened about 1 in 10 or 20 before).

There are more things we can now get rid of (forward bailout stack and some
other stuff).  I left that out of this change list but will continue to clean
this part of the code up in the next few days.

[Kasper Lund, 2010-12-16 07:23:00]

I haven't looked at all the details, but from a high-level perspective this STV.
This is much more explicit.

[Kasper Lund, 2010-12-16 08:32:38]

LGTM.

http://codereview.chromium.org/5908001/diff/1/src/full-codegen.cc
File src/full-codegen.cc (right):

http://codereview.chromium.org/5908001/diff/1/src/full-codegen.cc#newcode764
src/full-codegen.cc:764: PrepareForBailoutForId(expr->RightId(), NO_REGISTERS);
I wonder if it would make sense to somehow split the bailout ids into two
distinct categories: Statement level ids where we bailout before the statement
and expression level (side-effect) ids where we bailout out to just after. Not
sure. Maybe we could have two different PrepareForBailout implementations - one
for statements and one for expressions?

http://codereview.chromium.org/5908001/diff/1/src/hydrogen.cc
File src/hydrogen.cc (right):

http://codereview.chromium.org/5908001/diff/1/src/hydrogen.cc#newcode2064
src/hydrogen.cc:2064: HValue* const no_return_value = NULL;
Maybe turn this into static kNoReturnValue to make it very clear that it's a
sentinel value?

http://codereview.chromium.org/5908001/diff/1/src/hydrogen.cc#newcode2794
src/hydrogen.cc:2794: cond_graph = CreateLoopHeaderSubgraph(environment());
This also looks like it's ready for refactoring, but I'm okay with delaying that
a bit.

http://codereview.chromium.org/5908001/diff/1/src/hydrogen.cc#newcode4007
src/hydrogen.cc:4007: HValue* const no_return_value = NULL;
static kNoReturnValue?