R=bmeurer@chromium.org
BUG=v8:3956
LOG=n

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

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

Replaces the push of the dispatch table on the interpreted stack frame with a
push of the bytecode array. This enables the debugger to replace the bytecode
array with a patched version containing breakpoints.

BUG=v8:4690
LOG=N

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

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

Port 09d84535

Original commit message:
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.

BUG=

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

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

Turn the fast case of ArgumentsAccessStub into a new stub
FastNewSloppyArgumentsStub, which is similar to the existing
FastNewStrictArgumentsStub, although not polished yet, and the slow
case always went to the runtime anyway, so we can just directly emit
a runtime call there.

R=mstarzinger@chromium.org

Committed: https://crrev.com/55b0b4f6d572531eec00ab6ebd8f6feb7c584e04
Cr-Commit-Position: refs/heads/master@{#33973}

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

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

Revert of [runtime] Turn ArgumentAccessStub into FastNewSloppyArgumentsStub. (patchset #2 id:20001 of https://codereview.chromium.org/1695633003/ )

Reason for revert:
[Sheriff] Breaks ASAN with mipsel compile:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20ASAN%20mipsel%20-%20debug%20builder/builds/4558/

Original issue's description:
> [runtime] Turn ArgumentAccessStub into FastNewSloppyArgumentsStub.
>
> Turn the fast case of ArgumentsAccessStub into a new stub
> FastNewSloppyArgumentsStub, which is similar to the existing
> FastNewStrictArgumentsStub, although not polished yet, and the slow
> case always went to the runtime anyway, so we can just directly emit
> a runtime call there.
>
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/55b0b4f6d572531eec00ab6ebd8f6feb7c584e04
> Cr-Commit-Position: refs/heads/master@{#33973}

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

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

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

This is mostly preparation for allowing the function closure to be materialized.

As a drive-by fix, I have added ignition source position support to the frame inspector (this fixed some ignition test failures).

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

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

Turn the fast case of ArgumentsAccessStub into a new stub
FastNewSloppyArgumentsStub, which is similar to the existing
FastNewStrictArgumentsStub, although not polished yet, and the slow
case always went to the runtime anyway, so we can just directly emit
a runtime call there.

R=mstarzinger@chromium.org

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

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

This removes support for the %Arguments and %ArgumentsLength runtime
entries and their intrinsic counterparts. If you need variable arguments
in any builtin, either use (strict) arguments object or rest parameters,
which are both compositional across inlining (in TurboFan), and not that
much slower compared to the %_Arguments hackery.

R=jarin@chromium.org

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

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

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}

BUG=

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

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

Fixes a register-clobbering problem. The Branch() instruction can overwrite the 'at' register, so it can't be used as scratch in Allocate(). Added DCHECK to avoid this in the future.

BUG=

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

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

Saves and restores the dispatch pointer during calls to enable the debugger to
switch the dispatch table used by a function during it's execution.

Also moves the accumulator and context nodes to be Variables so that they will
be properly merged across branches.

BUG=v8:4280,v8:4690
LOG=N

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

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

This removes uses of JSFunction by the (proper) deoptimizer. This will be useful
when we escape analyze JSFunction away. Unfortunately, the debugger still needs
JSFunction, so escape analysis would not work yet.

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

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

Moves InterpreterAssembler out of the compiler directory and into the
interpreter directory. Makes InterpreterAssembler as subclass of
CodeStubAssembler.

As part of this change, the special bytecode dispatch linkage type
is removed and instead we use a InterfaceDispatchDescriptor and
a normal CodeStub linkage type.

Removes a bunch of duplicated logic in InterpreterAssembler and
instead uses the CodeStubAssembler logic. Refactors Interpreter
with these changes.

Modifies CodeStubAssembler to add the extra operations required
by the Interpreter (extra call types, raw memory access and some extra
binary ops). Also adds the ability for subclasses to add extra
prologue and epilogue operations around calls, which is required
for the Interpreter.

BUG=v8:4280
LOG=N

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

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

The break location heavily relies on relocation info. This change
abstracts that away. Currently there is only one implementation for
this interface, for JIT code. Future changes will introduce an
implementation to iterate bytecode arrays.

R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N

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

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

Calls use registers for target, new_target and argument count.
We don't always respect argument count. It didn't bite us in the past
because the code paths where we clobbered it never used it, though
in future it could be an issue.

BUG=
R=mstarzinger@chromium.org

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

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

Mark null and undefined as undetectable, and use it to handle abstract equality comparison in the generic compare ic

Marking as undetectable makes abstract equality of null, undefined, and
other undetectable objects easier. Supporting it in the generic compare
IC significantly speeds up dynamic comparison between those values and
JSReceivers by not falling back to the runtime.

MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>

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

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

Preparing the young generation for (real) non-contiguous backing memory, this
change removes object masks that are used to compute containment in semi and new
space. The masks are replaced by lookups for object tags and page headers, where
possible.

Details:
- Use the fast checks (page header lookups) for containment in regular code.
- Use the slow version that masks out the page start adress and iterates all
  pages of a space for debugging/verification.
- The slow version works for off-heap/unmapped memory.
- Encapsulate all checks for the old->new barrier in Heap::RecordWrite().

BUG=chromium:581412
LOG=N

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

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

BUG=

Committed: https://crrev.com/4d46b510caf534d770ce19a01a11b8796304471b
Cr-Commit-Position: refs/heads/master@{#33812}

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

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

The flag in question is a debug-only flag supported by full-codegen and
Crankshaft only. In it's current form there are some unresolved issues:
- The flag is defeated by inlining in Crankshaft.
- The flag is not supported by TurboFan.
- The flag is not supported by Ignition.

Instead of addressing the above issues and increasing maintenance cost
for all backends and also given the "slim" test coverage, this CL fully
removes the support from all backends.

R=bmeurer@chromium.org,jkummerow@chromium.org

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

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

Generally we only care whether the next object is a hidden prototype.
It's simpler to check whether the current object has a hidden prototype
instead of walking to the next prototype and checking its map.

BUG=

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

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

Revert of Do not eagerly instantiate accessors' JSFunction. (patchset #9 id:180001 of https://codereview.chromium.org/1609233002/ )

Reason for revert:
[Sheriff] Breaks gcmole:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gcmole/builds/6260

Original issue's description:
> Do not eagerly instantiate accessors' JSFunction.
>
> BUG=
>
> Committed: https://crrev.com/4d46b510caf534d770ce19a01a11b8796304471b
> Cr-Commit-Position: refs/heads/master@{#33812}

TBR=verwaest@chromium.org,epertoso@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/1679683004

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

BUG=

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

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

Replace the somewhat awkward RestParamAccessStub, which would always
call into the runtime anyway with a proper FastNewRestParameterStub,
which is basically based on the code that was already there for strict
arguments object materialization. But for rest parameters we could
optimize even further (leading to 8-10x improvements for functions with
rest parameters), by fixing the internal formal parameter count:

Every SharedFunctionInfo has a formal_parameter_count field, which
specifies the number of formal parameters, and is used to decide whether
we need to create an arguments adaptor frame when calling a function
(i.e. if there's a mismatch between the actual and expected parameters).
Previously the formal_parameter_count included the rest parameter, which
was sort of unfortunate, as that meant that calling a function with only
the non-rest parameters still required an arguments adaptor (plus some
other oddities). Now with this CL we fix, so that we do no longer
include the rest parameter in that count. Thereby checking for rest
parameters is very efficient, as we only need to check whether there is
an arguments adaptor frame, and if not create an empty array, otherwise
check whether the arguments adaptor frame has more parameters than
specified by the formal_parameter_count.

The FastNewRestParameterStub is written in a way that it can be directly
used by Ignition as well, and with some tweaks to the TurboFan backends
and the CodeStubAssembler, we should be able to rewrite it as
TurboFanCodeStub in the near future.

Drive-by-fix: Refactor and unify the CreateArgumentsType which was
different in TurboFan and Ignition; now we have a single enum class
which is used in both TurboFan and Ignition.

R=jarin@chromium.org, rmcilroy@chromium.org
TBR=rossberg@chromium.org
BUG=v8:2159
LOG=n

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

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

This replaces the global remembered set with per-page remembered sets.

Each page in the old space, map space, and large object space keeps track of
the set of slots in the page pointing to the new space.

The data structure for storing slot sets is a two-level bitmap, which allows
us to remove the store buffer overflow and SCAN_ON_SCAVENGE logic.

Design doc: https://goo.gl/sMKCf7

BUG=chromium:578883
LOG=NO

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

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

[api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.

Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.

The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.

BUG=chromium:579009
LOG=Y

Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
Cr-Commit-Position: refs/heads/master@{#33674}

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

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

BUG=
TEST=cctest/test-assembler-mips/min_max, cctest/test-assembler-mips/mina_maxa, cctest/test-assembler-mips64/min_max, cctest/test-assembler-mips64/mina_maxa

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

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

This makes the dispatch table similar to the builtins code list and makes
sure that the dispatch table does not move.

R=mstarzinger@chromium.org, rmcilroy@chromium.org

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

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

- remove unused counters
- add "ic" prefix to all ic-counters
- add more counter: maps-created, global deopts (not used yet)

BUG=

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

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

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}

Moves the stack check from the function entry trampoline to instead be
after function activation using an explicit StackCheck bytecode. Also
add stack checks on back edges of loops.

BUG=v8:4280,v8:4678
LOG=N

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

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

BUG=

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

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

BUG=

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

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

Revert of [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a … (patchset #3 id:80001 of https://codereview.chromium.org/1642223003/ )

Reason for revert:
Fails a lot of layout tests and blocks the roll. Can be easily reproduced with a local Chromium checkout.

Reference: https://codereview.chromium.org/1652413003/

Original issue's description:
> [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.
>
> Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
> When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
> ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.
>
> The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.
>
> This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks.
>
> BUG=chromium:579009
> LOG=Y
>
> Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
> Cr-Commit-Position: refs/heads/master@{#33674}

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

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

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

BUG=chromium:561449
LOG=n

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

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

[api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.

Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.

The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.

This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks.

BUG=chromium:579009
LOG=Y

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

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

Port cb9b8010

Original commit message:
The previous versions of Math.max and Math.min made it difficult to
optimize those (that's why we already have custom code in Crankshaft),
and due to lack of ideas what to do about the variable number of
arguments, we will probably need to stick in special code in TurboFan
as well; so inlining those builtins is off the table, hence there's no
real advantage in having them around as "not quite JS" with extra work
necessary in the optimizing compilers to still make those builtins
somewhat fast in cases where we cannot inline them (also there's a
tricky deopt loop in Crankshaft related to Math.min and Math.max, but
that will be dealt with later).

So to sum up: Instead of trying to make Math.max and Math.min semi-fast
in the optimizing compilers with weird work-arounds support %_Arguments
%_ArgumentsLength, we do provide the optimal code as native builtins
instead and call it a day (which gives a nice performance boost on some
benchmarks).

BUG=

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

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

Compilation dependencies for O32 ABI are removed from the code and now
compilation will be done according n64 ABI only.

TEST=
BUG=

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

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

This adds debug code to the interpreter entry trampoline to ensure that
the called bytecode handler will never return, but instead tear down the
frame with a proper exit trampoline eventually.

R=rmcilroy@chromium.org

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

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