We already have an optimization to constant-fold access to an object's
prototype via the special __proto__ accessor (specified in appendix B).
We can use the same optimization to also constant-fold accesses to an
object's prototype via the official Object.getPrototypeOf function.

Also add the optimization for Reflect.getPrototypeOf, which is
equivalent for object inputs.

This is commonly used by Babel to implement various new language
features, for example subclassing and certain property lookups.

R=yangguo@chromium.org
BUG=v8:6292

Review-Url: https://codereview.chromium.org/2841463002
Cr-Commit-Position: refs/heads/master@{#44788}

The immediate passed to cmpw can be either a signed 16-bit or an
unsigned 16-bit integer, but the DCHECK was testing for signed 16-bit
values only.

R=mstarzinger@chromium.org
BUG=v8:6063

Review-Url: https://codereview.chromium.org/2735363002
Cr-Commit-Position: refs/heads/master@{#43671}

The StringIndexOf operation is pure on the JS level, but the actual stub
call must be in the effect chain later so that the Scheduler doesn't
place it inside some allocation region (The %StringIndexOf runtime
function may trigger a GC for string flattening).

BUG=chromium:685580
R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2657243002
Cr-Commit-Position: refs/heads/master@{#42736}

BUG=chromium:679378
R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2634953002
Cr-Commit-Position: refs/heads/master@{#42365}

When Crankshaft compiles a keyed load to arguments, it disabled
optimization unless the KEYED_LOAD_IC for the access was monomorphic.
But that's too restrictive, since it will also disable optimization
for this function when the access is on a path that was never executed
so far.

This was spotted in the Node.js core function EventEmitter.prototype.emit,
which was no longer optimizable with Crankshaft using latest V8.

R=jarin@chromium.org
BUG=v8:5790

Review-Url: https://codereview.chromium.org/2607303002
Cr-Commit-Position: refs/heads/master@{#42005}