[builtins] Don't enforce I+TF for ArraySort helpers.

[builtins] Don't enforce I+TF for ArraySort helpers.

The current Array.prototype.sort implementation is pretty sensitive to
compiler changes, i.e. switching to I+TF completely, so refactor it a
bit so that it can stay with FCG+CS for now.

Middle-term the Array builtins need to be refactored to TurboFan
builtins anyways.

BUG=chromium:670691, v8:5666
R=jarin@chromium.org

Committed: https://crrev.com/704d737dc7be808f6017508c8ac7b5c2a21e0ad5
Cr-Commit-Position: refs/heads/master@{#41471}

[Benedikt Meurer, 2016-12-05 05:59:05]

The CQ bit was checked by bmeurer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-05 05:59:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Benedikt Meurer, 2016-12-05 05:59:58]

Hey Yang,

Simple mitigation for the I+TF fallout.
Please take a look.

Thanks,
Benedikt

[Yang, 2016-12-05 06:04:04]

On 2016/12/05 05:59:58, Benedikt Meurer wrote:
> Hey Yang,
> 
> Simple mitigation for the I+TF fallout.
> Please take a look.
> 
> Thanks,
> Benedikt

lgtm.

[Benedikt Meurer, 2016-12-05 06:08:06]

The CQ bit was unchecked by bmeurer@chromium.org

[Benedikt Meurer, 2016-12-05 06:08:10]

The CQ bit was checked by bmeurer@chromium.org

[commit-bot: I haz the power, 2016-12-05 06:08:17]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-05 06:35:44]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1480918090230820, "parent_rev":
"3c451405f3f78645c164703573d5a90446d41d9d", "commit_rev":
"e185c37dcce30d67afcc116bae4cb10c924037f5"}

[commit-bot: I haz the power, 2016-12-05 06:35:53]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-12-05 06:36:22]

Description was changed from

==========
[builtins] Don't enforce I+TF for ArraySort helpers.

The current Array.prototype.sort implementation is pretty sensitive to
compiler changes, i.e. switching to I+TF completely, so refactor it a
bit so that it can stay with FCG+CS for now.

Middle-term the Array builtins need to be refactored to TurboFan
builtins anyways.

BUG=chromium:670691,v8:5666
R=jarin@chromium.org
==========

to

==========
[builtins] Don't enforce I+TF for ArraySort helpers.

The current Array.prototype.sort implementation is pretty sensitive to
compiler changes, i.e. switching to I+TF completely, so refactor it a
bit so that it can stay with FCG+CS for now.

Middle-term the Array builtins need to be refactored to TurboFan
builtins anyways.

BUG=chromium:670691,v8:5666
R=jarin@chromium.org

Committed: https://crrev.com/704d737dc7be808f6017508c8ac7b5c2a21e0ad5
Cr-Commit-Position: refs/heads/master@{#41471}
==========

[commit-bot: I haz the power, 2016-12-05 06:36:23]

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

[adamk, 2016-12-05 20:33:45]

adamk@chromium.org changed reviewers:
+ adamk@chromium.org

[adamk, 2016-12-05 20:33:45]

I'm surprised that inner functions, declared at the top level of a function, are
enough to trigger the I + TF path. Such functions shouldn't be treated
lexically, and particularly should never be observably hole-initialized.

If that's what's happening, it sounds like there's a bug somewhere else we
should fix instead of changing the way array.js is written.

[adamk, 2016-12-05 20:44:54]

On 2016/12/05 20:33:45, adamk wrote:
> I'm surprised that inner functions, declared at the top level of a function,
are
> enough to trigger the I + TF path. Such functions shouldn't be treated
> lexically, and particularly should never be observably hole-initialized.
> 
> If that's what's happening, it sounds like there's a bug somewhere else we
> should fix instead of changing the way array.js is written.

Looks like it's actually the function names in named function expressions that
are the problem? Those are "lexical", but not in an interesting way. Again, they
are never filled with holes in an observable way. It seems like we should be
able to narrow the bailout in ast-numbering.cc using var->binding_needs_init().