Cache String.split not found results as well

Cache String.split not found results as well

Before String.split only cached results if the seperator was found

BUG=v8:4191
LOG=N

Committed: https://crrev.com/a5f710275462f3e1088a97eddf5c712f03a33719
Cr-Commit-Position: refs/heads/master@{#30632}

[skomski, 2015-09-07 09:30:48]

karl@skomski.com changed reviewers:
+ jkummerow@chromium.org

[skomski, 2015-09-07 09:30:48]

Sorry didn't really know who to pick because yangguo is apparently OOO so I
picked you again

[Jakob Kummerow, 2015-09-08 09:50:39]

LGTM.

Yang, is more caching something we want strategically? I wouldn't be surprised
if this cache were a benchmark-specific hack that we'd rather get rid of. If you
don't like this change, feel free to revert it.

[skomski, 2015-09-08 10:00:21]

The CQ bit was checked by karl@skomski.com

[commit-bot: I haz the power, 2015-09-08 10:00:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308373005/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308373005/1

[commit-bot: I haz the power, 2015-09-08 10:07:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-08 10:07:56]

Try jobs failed on following builders:
  v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/5619)

[skomski, 2015-09-08 10:09:43]

The CQ bit was checked by karl@skomski.com

[commit-bot: I haz the power, 2015-09-08 10:09:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308373005/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308373005/1

[commit-bot: I haz the power, 2015-09-08 10:30:12]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-09-08 10:30:31]

Patchset 1 (id:??) landed as
https://crrev.com/a5f710275462f3e1088a97eddf5c712f03a33719
Cr-Commit-Position: refs/heads/master@{#30632}

[Yang, 2015-09-08 21:32:26]

On 2015/09/08 09:50:39, Jakob wrote:
> LGTM.
> 
> Yang, is more caching something we want strategically? I wouldn't be surprised
> if this cache were a benchmark-specific hack that we'd rather get rid of. If
you
> don't like this change, feel free to revert it.

Seems alright to me. We have this cache either way, might as well use it to the
fullest.