Use worklist to find out Phis that could not be truncated to int32

Use worklist to find out Phis that could not be truncated to int32

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

[haitao.feng, 2013-04-23 09:10:38]

PTAL.

[Jakob Kummerow, 2013-04-25 16:32:36]

https://codereview.chromium.org/13950013/diff/3001/src/hydrogen.cc
File src/hydrogen.cc (right):

https://codereview.chromium.org/13950013/diff/3001/src/hydrogen.cc#newcode3745
src/hydrogen.cc:3745: worklist.Add(phi, zone());
I think you may want to prevent duplicate entries in the worklist by guarding
this with a BitVector (look at other worklist algorithms in this file for
examples). The computed result is correct either way, but the list could grow
excessively for pathological inputs, as there can easily be cycles in Phi
def-use chains.

[haitao.feng, 2013-04-26 04:38:13]

https://codereview.chromium.org/13950013/diff/3001/src/hydrogen.cc
File src/hydrogen.cc (right):

https://codereview.chromium.org/13950013/diff/3001/src/hydrogen.cc#newcode3745
src/hydrogen.cc:3745: worklist.Add(phi, zone());
Thanks for the review.

It seems that we do not need BitVector for this special case as the 
worklist only contains PHIs which might be truncated to int32 (the assumption in
the beginning) but could not be truncated as there is a non-truncating int32 or
a double usage in the first iteration, and a non-truncating PHI usage in the
following worklist iterations. So there is only one state change for the PHI and
a PHI will never be added to the worklist twice.

[Jakob Kummerow, 2013-05-02 16:58:43]

On 2013/04/26 04:38:13, haitao.feng wrote:
> https://codereview.chromium.org/13950013/diff/3001/src/hydrogen.cc
> File src/hydrogen.cc (right):
> 
> https://codereview.chromium.org/13950013/diff/3001/src/hydrogen.cc#newcode3745
> src/hydrogen.cc:3745: worklist.Add(phi, zone());
> Thanks for the review.
> 
> It seems that we do not need BitVector for this special case as the 
> worklist only contains PHIs which might be truncated to int32 (the assumption
in
> the beginning) but could not be truncated as there is a non-truncating int32
or
> a double usage in the first iteration, and a non-truncating PHI usage in the
> following worklist iterations. So there is only one state change for the PHI
and
> a PHI will never be added to the worklist twice.

Makes sense. LGTM. I'll land.

[Jakob Kummerow, 2013-05-02 17:01:00]

Committed patchset #2 manually as r14528 (presubmit successful).