Not consider the use representation in unintiliazed ArrayLiteral which always requires SMI

Not consider the use representation in unintiliazed ArrayLiteral which always requires SMI

R=jkummerow@chromium.org

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

[weiliang.lin2, 2013-06-29 10:03:13]

ArrayLiteral is always initialized with FAST_SMI element kind. If the
ArrayLiteral is dead code, it will affect its element variable representation
through use chain.
An example is the builtin StringSplit function as below

function StringSplit(separator, limit) {
  if (IS_NULL_OR_UNDEFINED(this) && !IS_UNDETECTABLE(this)) {
    throw MakeTypeError("called_on_null_or_undefined",
                        ["String.prototype.split"]);
  }
  var subject = TO_STRING_INLINE(this);
  limit = (IS_UNDEFINED(limit)) ? 0xffffffff : TO_UINT32(limit);

  // ECMA-262 says that if separator is undefined, the result should
  // be an array of size 1 containing the entire string.
  if (IS_UNDEFINED(separator)) {
    return [subject];
  }
  ...
}
"return [subject]" is mostly dead code because separator is rarely undefined.
But its side effect is to require subject used here to be SMI. A smi check
instruction will be inserted but always fail because subject mostly is a String
object. You will see split function is optimized and deoptimized many time with
poor performance.

On my X86 PC, this commit improves the StringSplit performance by ~9%. And there
is also small improvement for V8 benchmark (more than 1%)

Thanks for review

[Jakob Kummerow, 2013-07-01 13:42:57]

LGTM with nits.

Adding mvstanton to verify that this way of detecting uninitialized array
literals makes sense.

https://codereview.chromium.org/18263002/diff/2001/src/hydrogen.cc
File src/hydrogen.cc (right):

https://codereview.chromium.org/18263002/diff/2001/src/hydrogen.cc#newcode5771
src/hydrogen.cc:5771: bool uninitialized= false;
nit: spaces around '='

https://codereview.chromium.org/18263002/diff/2001/src/hydrogen.cc#newcode5870
src/hydrogen.cc:5870: {
nit: the opening '{' can go on the line before, resulting in one level less
indentation

[mvstanton, 2013-07-01 14:00:27]

That looks okay to me. If we never initialized the boilerplate by the time we
got to crankshaft, then indeed the code never ran, and this particular code may
be dead/unreachable anyway.

[weiliang.lin2, 2013-07-01 14:03:51]

On 2013/07/01 13:42:57, Jakob wrote:
> LGTM with nits.
> 
> Adding mvstanton to verify that this way of detecting uninitialized array
> literals makes sense.
> 
> https://codereview.chromium.org/18263002/diff/2001/src/hydrogen.cc
> File src/hydrogen.cc (right):
> 
> https://codereview.chromium.org/18263002/diff/2001/src/hydrogen.cc#newcode5771
> src/hydrogen.cc:5771: bool uninitialized= false;
> nit: spaces around '='
> 
> https://codereview.chromium.org/18263002/diff/2001/src/hydrogen.cc#newcode5870
> src/hydrogen.cc:5870: {
> nit: the opening '{' can go on the line before, resulting in one level less
> indentation
Refine code based on comments, thanks

[Jakob Kummerow, 2013-07-01 14:05:04]

LGTM, I'll land. Thanks!

[Jakob Kummerow, 2013-07-02 15:00:18]

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