Reland https://codereview.chromium.org/2373983004/, reverted in
4e5a4d93.

Reason: CL is not responsible for Win32 Debug failures (see https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/5031)

------------------------------------------------------------------------------

Implement the logic for StringIterator.prototype.next in the JSBuiltinReducer in order to allow inlining when the receiver is a JS_STRING_ITERATOR_TYPE map, built ontop of the SimplifiedOperators StringCharCodeAt and the newly added StringFromCodePoint.

Also introduces a new StringFromCodePoint simplified op which may be useful for other String builtins, such as String.fromCodePoint()

BUG=v8:5388
TBR=bmeurer@chromium.org, mstarzinger@chromium.org

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

Revert of [turbofan] inline %StringIteratorPrototype%.next in JSBuiltinReducer. (patchset #12 id:210001 of https://codereview.chromium.org/2373983004/ )

Reason for revert:
[Sheriff] Speculative revert for win dbg: https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/5029

Or we have an infra problem. Manual build before seems fine:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/5030

Original issue's description:
> [turbofan] inline %StringIteratorPrototype%.next in JSBuiltinReducer.
>
> Implement the logic for StringIterator.prototype.next in the JSBuiltinReducer in order to allow inlining when the receiver is a JS_STRING_ITERATOR_TYPE map, built ontop of the SimplifiedOperators StringCharCodeAt and the newly added StringFromCodePoint.
>
> Also introduces a new StringFromCodePoint simplified op which may be useful for other String builtins, such as String.fromCodePoint()
>
> BUG=v8:5388
> R=bmeurer@chromium.org, mstarzinger@chromium.org
>
> Committed: https://crrev.com/aed32e0f22353527993de8bceaf246fc744558f5
> Cr-Commit-Position: refs/heads/master@{#39994}

TBR=bmeurer@chromium.org,mvstanton@chromium.org,caitp@igalia.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5388

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

Implement the logic for StringIterator.prototype.next in the JSBuiltinReducer in order to allow inlining when the receiver is a JS_STRING_ITERATOR_TYPE map, built ontop of the SimplifiedOperators StringCharCodeAt and the newly added StringFromCodePoint.

Also introduces a new StringFromCodePoint simplified op which may be useful for other String builtins, such as String.fromCodePoint()

BUG=v8:5388
R=bmeurer@chromium.org, mstarzinger@chromium.org

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

BUG=

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

This CL "weakens" the typer somewhat, as it was querying aspects of
Type that are within the representation dimension. It's not the right
place to do that.

BUG=

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

And not the Representation dimension of Type*.

BUG=

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

Since the extension field is already used for the catch name, store a
ContextExtension there instead.

In the future, this will allow for chaining ScopeInfos together, so we
no longer need a context chain for lazy parsing / compilation.

BUG=v8:5215
R=bmeurer@chromium.org,neis@chromium.org,marja@chromium.org

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

Happily, we can/should include semantic information such as Internal(), NonInternal() even as we remove representation data.

BUG=

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

We use a signaling NaN to represent the hole in
FAST_HOLEY_DOUBLE_ELEMENTS backing stores, but on Intel processors, the
C++ compiler may decide to (or be forced to due to calling conventions)
use X87 registers for double values. However transfering to X87
registers automatically quietens the NaNs and there's no way to disable
this. Therefore we should just always load the hole NaN from the canonical
place identified by the address_of_hole_nan external reference instead,
which might even be more efficient in some cases.

R=jarin@chromium.org, jkummerow@chromium.org
BUG=v8:5332

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

Increasingly, we avoid using the representation dimension of Type,
  and set it explicitly ourselves.

BUG=

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

Introduced MachineType::TaggedSigned() and TaggedPointer().

The idea is to quit using the representational dimension of Type, and
instead encode this information in the MachineRepresentation (itself
lightly wrapped in MachineType, along with MachineSemantic).

There are three parts to the whole change:

1) Places that set the machine representation - constant nodes, loads nad
   stores, global object and native context specialization.

2) Places that propagate type/representation - this is representation
   inference (aka simplified lowering). At the end of this process we
   expect to have a MachineRepresentation for every node. An interesting
   part of this is phi merging.

3) Places that examine representation - WriteBarrier elimination does this.
   Currently it's looking at the Type representation dimension, but as
   a part of this change (or in a soon-to-follow change) it can simply
   examine the MachineRepresentation.

BUG=

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

Infer exact types for the various Date getter builtins, and also inline
the Date.prototype.getTime() builtin, which just returns the Date value
and thus doesn't need to check the cache stamp.

R=epertoso@chromium.org

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

For asm.js we now have a dedicated AsmTyper, that uses it's own type
system (which is tailored towards asm.js), and so we don't need the
special asm.js types anymore in the TypeCache. This also moves the
TypeCache into the src/compiler directory, because it doesn't make
sense to use outside anyways.

TBR=ahaas@chromium.org
R=jarin@chromium.org
BUG=v8:5267

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

This adds a very first version of inlined Array.prototype.push into
TurboFan optimized code. The current inlined version has a potential
deopt loop, but it's unlikely that we hit it currently (Crankshaft
suffers from an even worse problem). Once we have a way to learn from
deopts we can fix this deopt loops.

It's also probably overly defensive in when it's safe to inline
the call to Array.prototype.push, but we can always extend that
later once we have sufficient trust in the implementation and see
an actual need to extend it.

BUG=v8:2229,v8:3952,v8:5267
R=jarin@chromium.org

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

This adds a very first version of inlined Array.prototype.pop into
TurboFan optimized code. We currently limit the inlining to fast
object or smi elements, until the unclear situation around hole NaNs
is resolved and we have a clear semantics inside the compiler.

It's also probably overly defensive in when it's safe to inline
the call to Array.prototype.pop, but we can always extend that
later once we have sufficient trust in the implementation and see
an actual need to extend it.

BUG=v8:2229,v8:3952,v8:5267
R=epertoso@chromium.org

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

If the intersection of the types of nodes a and b is empty, then there's
no way that a and b could ever refer to the same object, so we can use
that information for alias analysis.

Drive-by-fix: Improve use of types to enable typed alias analysis to
become more effective. Also fix an ASAN issue uncovered by this CL.

R=jarin@chromium.org

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

This adds support for lowering keyed access to JSTypedArray objects to
element loads and stores instead of IC calls. There's still a lot of
room for improvement, but the improvements can be done incrementally
later.

We add a dedicated UnsafePointerAdd operator, which sits in the effect
chain, and does the (GC invisible) computation of addresses that are
potentially inside HeapObjects. Also there's now a dedicated Retain
operator, which ensures that we retain a certain tagged value, which is
necessary to ensure that we keep a JSArrayBuffer alive as long as we
might still potentially access elements in its backing store.

R=epertoso@chromium.org

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

This adds initial support to inline a couple of the ArrayBuffer view
accessors like %TypeArray%.prototype.length and.
DataView.prototype.byteLength.

R=epertoso@chromium.org

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

Introduce an appropriate StringCharCodeAt simplified operator and use
that to optimize the String.prototype.charCodeAt/.charAt builtins.

R=epertoso@chromium.org

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

HashField is a 32-bit field.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com, bjaideep@ca.ibm.com
BUG=

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

This runtime function now also works for Ignition generators. It returns the
source position of the yield at which a suspended generator got suspended.  This
works by storing the current bytecode offset at suspension and using an existing
mechanism to map it back to a source position.

TBR=littledan@chromium.org
BUG=

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

We use StringFromCharCode to optimize calls to String.fromCharCode with
a single Number argument for now. We will use it to also implement the
charAt method on the String prototype.

R=jarin@chromium.org

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

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

BUG=

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

Also use the inlined version of CreateIterResultObject in Ignition's VisitYield.

BUG=v8:4907
TBR=littledan@chromium.org

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

Introduce three new JS operators in Turbofan:
- JSGeneratorStore is used in implementing Ignition's SuspendGenerator bytecode.
- JSGeneratorRestoreContinuation and JSGeneratorRestoreRegister are used in
  implementing Ignition's ResumeGenerator bytecode.

Remove the runtime functions that were used to implement these bytecodes before.

BUG=v8:4907

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

Reland of [turbofan] Restore basic write barrier elimination. (patchset #1 id:1 of https://codereview.chromium.org/1943743003/ )

Reason for revert:
Jakob found the actual issue with the CL and is going to land the fix after relanding the WB elimination.

Original issue's description:
> Revert of [turbofan] Restore basic write barrier elimination. (patchset #2 id:20001 of https://codereview.chromium.org/1938993002/ )
>
> Reason for revert:
> Breaks WBs that should be there ;)
>
> https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/3305
>
> Will open repro bug asap.
>
> Original issue's description:
> > [turbofan] Restore basic write barrier elimination.
> >
> > Restore the basic write barrier elimination that we used to run as part
> > of the simplified lowering phase (in ChangeLowering actually) before, by
> > moving the write barrier computation to SimplifiedLowering where we can
> > still look at types and consider the heap/isolate, and just update the
> > WriteBarrierKind in the FieldAccess/ElementAccess that we later use when
> > lowering to a machine Load/Store.
> >
> > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
> > R=mstarzinger@chromium.org
> > BUG=v8:4969,chromium:608636
> > LOG=n
> >
> > Committed: https://crrev.com/7dcb6ad379fbacbc8bdc8e11a6e50d680ffa3f62
> > Cr-Commit-Position: refs/heads/master@{#35969}
>
> TBR=mstarzinger@chromium.org,bmeurer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4969,chromium:608636
>
> Committed: https://crrev.com/a782e93c617e728cded5ad878de11137a67891b7
> Cr-Commit-Position: refs/heads/master@{#35983}

TBR=mstarzinger@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4969,chromium:608636

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

Revert of [turbofan] Restore basic write barrier elimination. (patchset #2 id:20001 of https://codereview.chromium.org/1938993002/ )

Reason for revert:
Breaks WBs that should be there ;)

https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/3305

Will open repro bug asap.

Original issue's description:
> [turbofan] Restore basic write barrier elimination.
>
> Restore the basic write barrier elimination that we used to run as part
> of the simplified lowering phase (in ChangeLowering actually) before, by
> moving the write barrier computation to SimplifiedLowering where we can
> still look at types and consider the heap/isolate, and just update the
> WriteBarrierKind in the FieldAccess/ElementAccess that we later use when
> lowering to a machine Load/Store.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
> R=mstarzinger@chromium.org
> BUG=v8:4969,chromium:608636
> LOG=n
>
> Committed: https://crrev.com/7dcb6ad379fbacbc8bdc8e11a6e50d680ffa3f62
> Cr-Commit-Position: refs/heads/master@{#35969}

TBR=mstarzinger@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4969,chromium:608636

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

Restore the basic write barrier elimination that we used to run as part
of the simplified lowering phase (in ChangeLowering actually) before, by
moving the write barrier computation to SimplifiedLowering where we can
still look at types and consider the heap/isolate, and just update the
WriteBarrierKind in the FieldAccess/ElementAccess that we later use when
lowering to a machine Load/Store.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
R=mstarzinger@chromium.org
BUG=v8:4969,chromium:608636
LOG=n

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

Review URL: https://codereview.chromium.org/1900043003

Cr-Commit-Position: refs/heads/master@{#35638}

This changes closure creation to lower to inline allocations when
possible instead of going through the FastNewClosureStub. It allows us
to leverage all advantages of inline allocations on closures. Note that
it is only safe to embed the raw entry point of the compile lazy stub
into the code, because that stub is immortal and immovable.

R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/1573153002

Cr-Commit-Position: refs/heads/master@{#35499}

The FastNewStrictArgumentsStub is very similar to the recently added
FastNewRestParameterStub, it's actually almost a copy of it, except that
it doesn't have the fast case we have for the empty rest parameter. This
patch improves strict arguments in TurboFan and fullcodegen by up to 10x
compared to the previous version.

Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject
for the in-object properties instead of having them as constants in the
Heap class.

Drive-by-fix: Use this stub and the FastNewRestParameterStub in the
interpreter to avoid the runtime call overhead for strict arguments
and rest parameter creation.

R=jarin@chromium.org
TBR=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1693513002

Cr-Commit-Position: refs/heads/master@{#33925}

Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )

Reason for revert:
Must revert for now due to chromium api natives issues.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}

TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1670813005

Cr-Commit-Position: refs/heads/master@{#33766}

(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1668103002

Cr-Commit-Position: refs/heads/master@{#33741}

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

TBR=bradnelson@chromium.org

Review URL: https://codereview.chromium.org/1655833002

Cr-Commit-Position: refs/heads/master@{#33656}

Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )

Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1643533003

Cr-Commit-Position: refs/heads/master@{#33556}

(Fixed a bug found by nosnap builds.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1642613002

Cr-Commit-Position: refs/heads/master@{#33548}

Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )

Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}

TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1632993003

Cr-Commit-Position: refs/heads/master@{#33520}

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1563213002

Cr-Commit-Position: refs/heads/master@{#33518}

We can no longer just walk the prototype chain without doing proper access-checks. When installing a proxy as the __proto__ of the global object we might accidentally end up invoking cross-realm code without access-checks (see proxies-cross-realm-ecxeption.js).

Review URL: https://codereview.chromium.org/1521953002

Cr-Commit-Position: refs/heads/master@{#32903}

Introduce JSCreateIterResultObject operator, as a way to optimize the
%_CreateIterResultObject intrinsic, which is used to provide uniform,
non-polymorphic result objects for iterators (and generators).  We
cannot utilize the existing JSCreate operator here, because there's no
constructor function for iterator result objects (as required by the
spec).

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1531753002

Cr-Commit-Position: refs/heads/master@{#32901}