tighten invariants of HValue::InferRange

tighten invariants of HValue::InferRange

* src/hydrogen-instructions.cc (HValue::InferRange): Only mark values
  with int32 representation as never being -0.  Always return a non-NULL
  value; callers should check for representation().IsNone() if that's
  their concern.

  In practice these invariants were not violated by callers, but they
  were sometimes two calls away, which seems brittle.

BUG=
TEST=tests pass, modulo http://code.google.com/p/v8/issues/detail?id=1572

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

[fschneider, 2011-07-28 09:09:59]

LGTM.

[wingo, 2011-08-01 14:34:49]

The tests that I have added in this updated patch show the -0 bug.  I had a bit
of trouble getting the optimizer to run, though, as you can see in the patch.

[Kevin Millikin (Chromium), 2011-08-02 10:24:13]

I'll clean up the test a bit and commit.

http://codereview.chromium.org/7514040/diff/8001/test/mjsunit/math-floor.js
File test/mjsunit/math-floor.js (right):

http://codereview.chromium.org/7514040/diff/8001/test/mjsunit/math-floor.js#n...
test/mjsunit/math-floor.js:55: // handled by other ops that take unboxed
doubles.  See cr7514040.
No need to cross reference the code review in the test.  The casual reader
doesn't know what it is, and normally the commit message includes it anyway.

http://codereview.chromium.org/7514040/diff/8001/test/mjsunit/math-floor.js#n...
test/mjsunit/math-floor.js:156: // It seems that %OptimizeFunctionOnNextCall
doesn't always work!  Here
It should always work (or else that's a bug).

I think what's happening here is that (a) the call to Math.floor in the loop is
invariant, so it gets lifted out; (b) the optimized floorsum correctly
deoptimizes on the negative zero; then, (c) the function is optimized a second
time via OSR because it contains a long running loop, but (d) the call to
Math.floor in the loop is prevented from being hoisted out of the loop because
it hasn't been computed at OSR entry, and so (e) there we hit the bug.

You can see that by passing the flags --trace-deopt --trace-osr.

This comment should just say something like 'use a high trip count to get the
loop optimized via OSR'.

http://codereview.chromium.org/7514040/diff/8001/test/mjsunit/math-round.js
File test/mjsunit/math-round.js (right):

http://codereview.chromium.org/7514040/diff/8001/test/mjsunit/math-round.js#n...
test/mjsunit/math-round.js:1: // Copyright 2010, 2011 the V8 project authors.
All rights reserved.
We just update the copyright date to 2011, not a range of dates.

[wingo, 2011-08-02 13:19:27]

Thanks for the review, the pointers on style, and the explanation of the test.

For posterity, a link to the mailing list discussion:

http://thread.gmane.org/gmane.comp.lang.javascript.v8.devel/37791