Minor cleanup of CompareIC state

Minor cleanup of CompareIC state

Allow transitioning from KNOWN_OBJECT to KNONW_OBJECT or OBJECT.
Also, rename HEAP_NUMBER IC states to NUMBER, since they handle Smis, too.

R=jkummerow@chromium.org
BUG=

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

[Jakob Kummerow, 2013-02-15 09:12:53]

https://codereview.chromium.org/12254036/diff/1/src/ic.cc
File src/ic.cc (right):

https://codereview.chromium.org/12254036/diff/1/src/ic.cc#newcode2438
src/ic.cc:2438: // HEAP_NUMBER stub will do the right thing.
s/HEAP_//

https://codereview.chromium.org/12254036/diff/1/src/ic.cc#newcode2477
src/ic.cc:2477: return KNOWN_OBJECT;
We should not have a KNOWN_OBJECT -> KNOWN_OBJECT transition. It could lead to
endless IC patching cycles. When KNOWN_OBJECT misses, we should go to OBJECT or
GENERIC.

https://codereview.chromium.org/12254036/diff/1/src/ic.h
File src/ic.h (right):

https://codereview.chromium.org/12254036/diff/1/src/ic.h#newcode764
src/ic.h:764: NUMBER,
I don't think this renaming is an improvement, for two reasons:
(1) All ICs call this state HEAP_NUMBER, so renaming it for CompareICs
introduces inconsistency.
(2) The previous name does make sense, as generally a stub's type name indicates
the most generic type it can handle. The "SMI < [HEAP_]NUMBER" inequation above
implies that the HEAP_NUMBER stub can handle Smis.
That said, if you insist on this change, I don't feel strongly enough about it
to argue.

[rossberg, 2013-02-19 11:32:13]

https://codereview.chromium.org/12254036/diff/1/src/ic.cc
File src/ic.cc (right):

https://codereview.chromium.org/12254036/diff/1/src/ic.cc#newcode2438
src/ic.cc:2438: // HEAP_NUMBER stub will do the right thing.
On 2013/02/15 09:12:53, Jakob wrote:
> s/HEAP_//

Done.

https://codereview.chromium.org/12254036/diff/1/src/ic.cc#newcode2477
src/ic.cc:2477: return KNOWN_OBJECT;
On 2013/02/15 09:12:53, Jakob wrote:
> We should not have a KNOWN_OBJECT -> KNOWN_OBJECT transition. It could lead to
> endless IC patching cycles. When KNOWN_OBJECT misses, we should go to OBJECT
or
> GENERIC.

Done.

https://codereview.chromium.org/12254036/diff/1/src/ic.h
File src/ic.h (right):

https://codereview.chromium.org/12254036/diff/1/src/ic.h#newcode764
src/ic.h:764: NUMBER,
On 2013/02/15 09:12:53, Jakob wrote:
> I don't think this renaming is an improvement, for two reasons:
> (1) All ICs call this state HEAP_NUMBER, so renaming it for CompareICs
introduces inconsistency.

Good point, I fixed it for Unary and Binary ops as well. :)

> (2) The previous name does make sense, as generally a stub's type name
indicates
> the most generic type it can handle. The "SMI < [HEAP_]NUMBER" inequation
above
> implies that the HEAP_NUMBER stub can handle Smis.

As discussed offline, your very argument is why I changed it. HEAP_NUMBER names
a specific representation type, but a stub in the respective state can also
handle SMI representations, so NUMBER is the actual type it handles, in
accordance to our type hierarchy.

[Jakob Kummerow, 2013-02-19 14:46:58]

https://codereview.chromium.org/12254036/diff/5001/src/ic.cc
File src/ic.cc (right):

https://codereview.chromium.org/12254036/diff/5001/src/ic.cc#newcode2475
src/ic.cc:2475: return KNOWN_OBJECT;
Y U NO address my previous comment? There shouldn't be any KNOWN_OBJECT ->
KNOWN_OBJECT transition. We must go to OBJECT here.

[rossberg, 2013-02-20 11:00:21]

https://codereview.chromium.org/12254036/diff/5001/src/ic.cc
File src/ic.cc (right):

https://codereview.chromium.org/12254036/diff/5001/src/ic.cc#newcode2475
src/ic.cc:2475: return KNOWN_OBJECT;
On 2013/02/19 14:46:58, Jakob wrote:
> Y U NO address my previous comment? There shouldn't be any KNOWN_OBJECT ->
> KNOWN_OBJECT transition. We must go to OBJECT here.

Oops, sorry, I already fixed that earlier, but apparently on the wrong branch.
8-}

[Jakob Kummerow, 2013-02-20 14:31:09]

lgtm