Modify %AddElement to accept large indices out of array bounds

Modify %AddElement to accept large indices out of array bounds

This patch changes %AddElement to fall back to adding a named property
in case it is given an argument of 2**32 or greater. The change is
needed because %AddElement is called by Array functions in various
places, and ES2015 changes these Array functions to use ToLength
rather than ToUint32, so several callsites of %AddElement which used
to be reliable array indices may be larger numbers. While the proper
long-term solution may be to call out to Object.defineProperty, this
fix should allow the ToLength semantics to be shipped while
preserving correctness and not requiring a rewrite.

BUG=v8:4516
LOG=Y
R=adamk
TEST=Interactively ran Array.prototype.slice on an Array-like which
exceeded array bounds, and found that this did not check-fail at
runtime as it did before.
Interactively used %AddElements with larger number inputs and
observed it to correctly manipulate objects.

[Dan Ehrenberg, 2015-10-27 00:44:45]

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

[commit-bot: I haz the power, 2015-10-27 00:44:54]

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

[commit-bot: I haz the power, 2015-10-27 00:54:45]

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

[commit-bot: I haz the power, 2015-10-27 00:54:46]

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

[Dan Ehrenberg, 2015-10-27 03:55:20]

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

[commit-bot: I haz the power, 2015-10-27 03:55:31]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1425743002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1425743002/20001

[commit-bot: I haz the power, 2015-10-27 04:38:52]

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

[commit-bot: I haz the power, 2015-10-27 04:38:53]

Dry run: This issue passed the CQ dry run.

[Toon Verwaest, 2015-10-27 08:26:44]

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

[Toon Verwaest, 2015-10-27 08:26:45]

The idea of these specific runtime functions is that they do exactly what they
claim, and no more. That's why there are multiple asserts in there that
guarantee their behavior.

If some clients need to call AddDataProperty for non-element keys, they should
manually choose to do so however. We really want clients to use very specific
APIs so we know the intent.

[Dan Ehrenberg, 2015-10-27 13:42:37]

On 2015/10/27 at 08:26:45, verwaest wrote:
> The idea of these specific runtime functions is that they do exactly what they
claim, and no more. That's why there are multiple asserts in there that
guarantee their behavior.
> 
> If some clients need to call AddDataProperty for non-element keys, they should
manually choose to do so however. We really want clients to use very specific
APIs so we know the intent.

It's hard, because most callers will need to be changed. %AddElement tends to be
used by array functions, and these functions used to always only produce array
keys, but with the ToLengt change, they often use higher numbers. I thought this
would be the most reasonable way to make the change without hurting performance.
Adding a redundant conditional at callsites risks slowing the program down. But,
long-term, I was imagining that we might move away from specialized
%AddElement-style operations (which have no equivalent in the spec and therefore
lead to issues like this), and this is just a short-term hack.

[Dan Ehrenberg, 2015-10-27 21:38:52]

Closing this in favor of https://codereview.chromium.org/1420663003/