R=caseq@chromium.org

Change-Id: Ie7d8e2eb1452758895f47c749cd7f1ea9b565301
Reviewed-on: https://chromium-review.googlesource.com/654038Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47886}

When setting up an isolate for serialization, we need to disable lazy
deserialization to avoid replacing lazy builtins with DeserializeLazy.

Bug: v8:6624
Change-Id: I3e10e262f6dd856f92fd83e5e475127e8ca3f3bf
Reviewed-on: https://chromium-review.googlesource.com/655161Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47885}

This is a reland of 9b35364c
Original change's description:
> [cleanup] Replace more instances of List with std::vector.
> 
> Bug: v8:6333
> Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2
> Reviewed-on: https://chromium-review.googlesource.com/651413
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47854}

Bug: v8:6333
Change-Id: I5d9482b061f26b57550a421ea4099372dc80767f
Reviewed-on: https://chromium-review.googlesource.com/654898Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47884}

debug::GetBuiltin creates a new JSFunction and constructs a new SFI at
runtime. Ensure that this SFI has the correct builtin_id set.

Bug: v8:6624,v8:6788
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I25da2ad5e69478f81042d3e3bf7e7e2644e7050d
Reviewed-on: https://chromium-review.googlesource.com/654643Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47883}

R=clemensh@chromium.org

Change-Id: If0b4aed4e5770702b36e3e1a34189a1b18a9cf17
Reviewed-on: https://chromium-review.googlesource.com/631837Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47882}

The optimizer produces direct calls to these builtins. Lazy
deserialization depends on the existance of a shared function info, so
these need to be blacklisted for now.

Bug: v8:6624,v8:6786
Change-Id: I69e766d327338d333a9a8e6ba9a394aad5f06f01
Reviewed-on: https://chromium-review.googlesource.com/655160Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47881}

This finally allows to include the factory.h header without having to
also inlcude the object-inl.h inline header. It will in turn enable the
removal of the last inline header inclusion violation.

R=marja@chromium.org

Change-Id: Ice2821e1f74cf428d80c8ebf606a218026f37677
Reviewed-on: https://chromium-review.googlesource.com/654862Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47880}

kNextChunk handling in deserializer.cc relies on the reservation
mechanism, which is not used by builtin deserialization. To avoid
complications, we work around this for now by skipping over these
bytecodes.

This will soon become unnecessary once allocations & reservations have
been refactored.

Bug: v8:6624
Change-Id: I9e861268ee2b3f49fe7f3ed6c1e3501b4b47dc37
Reviewed-on: https://chromium-review.googlesource.com/655158Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47879}

With lazy deserialization, the target code object may have been replaced
by DeserializeLazy. In that case, we can get the target builtin id from
the shared function info, and we need to skip RelocInfo iteration (it
doesn't exist yet).

Bug: v8:6624
Change-Id: I765b74de313e65bfdf0122f13535029994fc0de1
Reviewed-on: https://chromium-review.googlesource.com/655159Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47878}

What happened:
- When rewriting in DoParseFunction, the relevant function scope is no longer in
the scope stack.
- The correct scope is given to the PatternRewriter.
- PatternRewriter called to Parser::BuildIteratorCloseForCompletion.
- BuildIteratorCloseForCompletion would just call NewTemporary (which creates
a new temporary in Parser's current scope) instead of using the scope passed to
it and calling NewTemporary on it.
- Normally this went unnoticed, since it doesn't matter that much where the
temporary is.
- But in the lazy arrow func case, the Parser's scope at that point was the
already-resolved outer scope, and a DCHECK detected this problem.

Kudos & thanks to verwaest@ for a debugging session :)

BUG=chromium:761831

Change-Id: I1e8474ce927be0330f4ba4efc0fc08fdcc328809
Reviewed-on: https://chromium-review.googlesource.com/650297
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47877}

There are two main reasons to move DeserializeLazy to ASM:

1. We avoid complications around the distinction between Call/Construct
   cases by making sure relevant registers (e.g. new_target) remain
   unclobbered.

2. We can avoid the tail-call through CodeFactory::Call/Construct by
   jumping directly to the deserialized code object.

Bug: v8:6624
Change-Id: Idef8fa73d804e16d510f62766c735d1891729b81
Reviewed-on: https://chromium-review.googlesource.com/652472Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47876}

Given that we no longer need to iterate over lists of optimized JS functions 
(c.f. https://chromium-review.googlesource.com/c/v8/v8/+/647596), we can 
remove this field. Thus saving the size of one pointer per function.

Bug: v8:6637
Change-Id: If77951f2eddba33ba350fa9ddf03a4edb3f7c7d8
Reviewed-on: https://chromium-review.googlesource.com/652373Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#47875}

The wasm-async fuzzer uses the bytes provided by the fuzzer engine
directly as wasm module bytes, compiles them with async compilation, and
then tries to execute the "main" function of the module. This "main"
can have an infinite loop which causes a timeout in the fuzzer. With
this CL the "main" function is first executed with the interpreter. If
the execution in the interpreter finishes within 16k steps, which means
that there is no infinite loop, also the compiled code is executed.

I added the raw fuzzer input as a test case because in this case I
really want to test the fuzzer and not V8.

R=clemensh@chromium.org

Bug: chromium:761784
Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162
Reviewed-on: https://chromium-review.googlesource.com/651046
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47874}

R=rmcilroy@chromium.org
BUG=v8:6409

Change-Id: Ib8bb85674f63fed47aa55a775eaade6b14d60f2e
Reviewed-on: https://chromium-review.googlesource.com/654040Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47873}

Change-Id: If7db250e242350f83b368b33b60399afd5312b36
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/654658Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47872}

The help output prints the first line of the doc string.

Change-Id: I76817d5138b7bb7ba8034c6a5d803b5aaf1201f7
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/654603Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47871}

JS runtime calls are always created with undefined recievers, so make the
bytecode behave similarly to CallUndefinedReciever such that we don't need
to push an explicit undefined register for the receiver for such calls.

Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls
to pass the generator in the first argument rather than the reciever since
these runtime calls were desugered in the bytecode generator and explicitly
passed the generator in the receiver.

Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269
Reviewed-on: https://chromium-review.googlesource.com/654257Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47870}

Introduce NodeProperties::NoObservableSideEffectBetween to check if
there's any observable side effect between two nodes in the effect
chain. Use this to guard the insertion of potentially redundant map
checks in the lowering of Object.prototype.hasOwnProperty and keyed
accesses within a for..in loop. This gives another boost on the for..in
performance front.

Bug: v8:6702
Change-Id: I68133f14ad388a1a7422714319c9b323d5cf8bc4
Reviewed-on: https://chromium-review.googlesource.com/654640Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47869}

Bug: 
Change-Id: I3a97b303bcb4cbb4835fb5de8c55a21eaaa93504
Reviewed-on: https://chromium-review.googlesource.com/649615Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47868}

The lazy deserialization builtin id is usually set when the shared
function info is created in Factory::NewSharedFunctionInfo, which looks
at the given code object to grab the builtin id.

However, this doesn't work when the shared function info is created
after deserialization, as is the case for harmony features that can be
toggled with runtime flags. At this point, lazy builtins have already
been replaced by DeserializeLazy in the builtins table.

To ensure that the lazy deserialization id is correct in this case,
explicitly set it in bootstrapper functions.

Bug: v8:6624, v8:6788
Change-Id: Ia6ac3a4842d2659d5de6d92f378ea221b5508040
Reviewed-on: https://chromium-review.googlesource.com/652477
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47867}

Followup after https://chromium-review.googlesource.com/c/v8/v8/+/652427
which triggered FORWARD_DECLARE macro redefinition warnings/errors.  Let's
make sure to undef this macro at the end of source files that create it.

Bug: chromium:746958
Change-Id: Ie70743c836db45eb51f412a0d6359f0f667319d3
Reviewed-on: https://chromium-review.googlesource.com/654657
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47866}

This extends the list by two cases that we currently cannot handle:

FunctionPrototypeHasInstance is called directly without going through
Call (https://crbug.com/v8/6786).

The Proxy constructor uses a custom construct stub
(https://crbug.com/v8/6787).

Bug: v8:6624,v8:6786,v8:6787
Change-Id: I21b883bf94bfa170d1da7aa812d09f813d881133
Reviewed-on: https://chromium-review.googlesource.com/651424Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47865}

This came up in the context of a Twitter discussion, see this particular
tweet https://twitter.com/hashseed/status/905684048382754817 and the
relevant thread.

Change-Id: If2447169df999b64ce701a44321d48ba1bff2a06
Reviewed-on: https://chromium-review.googlesource.com/654598Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47864}

This reduces the arm32 binary by around 20kB.

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

Bug: v8:6055
Change-Id: If9098e49793b29dceb8292aff6f668ca28a07728
Reviewed-on: https://chromium-review.googlesource.com/652427Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47863}

As Blink needs a way to define a property without running a script,
make Object::DefineOwnProperty use ENTER_V8_NO_SCRIPT if the
receiver object is not a JSProxy.  Quite similar to
https://crrev.com/c/v8/v8/+/608348

Bug: chromium:728583, chromedriver:1978, chromium:762385
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: If358bf0d156139c456de369ac04da2be6e626143
Reviewed-on: https://chromium-review.googlesource.com/651949
Commit-Queue: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47862}

This reduces the number of times this string is copied from two to one.

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I8680cfc1ef1d6c2cfd3bc4970fe698bb904ce328
Reviewed-on: https://chromium-review.googlesource.com/652591Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47861}

R=joransiu@ca.ibm.com, jyan@ca.ibm.com
BUG=
LOG=N

Change-Id: I353f953b6b2d9c20ebd9d141b33da47761f3e43b
Reviewed-on: https://chromium-review.googlesource.com/653808Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47860}

This macro is defined all over the place, and often causes macro
redefinition errors in jumbo builds.  Let's make sure all such
instances created in source files are #undef'ed.

Candidate files found with:
  grep -wL '#undef TRACE' $(git grep -wl '#define TRACE' -- '*.cc')

While we're at it, let's undef all macros defined in these files.

Bug: chromium:746958
Change-Id: I639ca2b141f908457d1b2601cd6d5827dee0ead0
Reviewed-on: https://chromium-review.googlesource.com/652476Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#47859}

Port 30f08f39

  Always return to the InterpreterEntryTrampoline rather than calling the
  InterpreterExitTrampoline from the Return bytecode handler. This fixes a
  regression which occured if we upset the call/return stack by skipping the
  return to the InterpreterEntryTrampoline from the return bytecode handler.

R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: Id2bae444e72cd7ddfb74f4861fc2c4f7b5e9bda5
Reviewed-on: https://chromium-review.googlesource.com/653618Reviewed-by: Jaideep Bajwa <bjaideep@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47858}

R=adamk@chromium.org

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie59cc231e130fad391508e5c47e01d32d0a78806
Reviewed-on: https://chromium-review.googlesource.com/651357Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47857}

This is the second attempt at removing this.
Earlier (https://chromium-review.googlesource.com/579194) there were
regressions on some of the functions related to maps and sets. Now that
all of them are ported to CSA, we can remove the remaining uses of
SetForceInlineFlag.

Bug: v8:6682
Change-Id: Iebf296038aa24b65181b0d10531b0569d313e7fc
Reviewed-on: https://chromium-review.googlesource.com/647452Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47856}

This reverts commit 9b35364c.

Reason for revert: Failing tests on Win64 Debug

Original change's description:
> [cleanup] Replace more instances of List with std::vector.
> 
> Bug: v8:6333
> Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2
> Reviewed-on: https://chromium-review.googlesource.com/651413
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47854}

TBR=neis@chromium.org,jgruber@chromium.org,petermarshall@chromium.org

Change-Id: Ifa2cd98edd9ec5e1d67c81501f0d9e8aae69536c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6333
Reviewed-on: https://chromium-review.googlesource.com/653117Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47855}

Bug: v8:6333
Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2
Reviewed-on: https://chromium-review.googlesource.com/651413Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47854}

- Convert S.p.{trim, trimLeft, trimRight} to TFJ
  - Fast paths for one/two byte strings
  - Added StringTrimAssembler
- Added helper kStringTrim runtime to handle slow paths

Quick measurements show >2.7x improvement:
https://github.com/peterwmwong/v8-perf/tree/master/string-trim

Bug: v8:6680
Change-Id: I79929129aa3d5dea20f094d648afe46adbf61a49
Reviewed-on: https://chromium-review.googlesource.com/647647Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47853}

R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-762472
BUG=chromium:762472

Change-Id: I8977fb9c9330f03641291b08cf803d0117b7a96a
Reviewed-on: https://chromium-review.googlesource.com/652478Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47852}

Bug: v8:6702
Change-Id: I6e2fc1a56035b9841ad5c71504b74a89d7259ad1
Reviewed-on: https://chromium-review.googlesource.com/651366Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47851}

JSTests.json had some poor/wrong settings.

Bug: 
Change-Id: Id30589ba2392d2561037fd55d9e77a31ca6c7ad9
Reviewed-on: https://chromium-review.googlesource.com/649534Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47850}

The stack value is unused and does not need to be pushed or popped on
return from JSEntryTrampoline

Bug: 
Change-Id: I0e1920fc48b63cb0eea66454e5b74d9b3c2d5956
Reviewed-on: https://chromium-review.googlesource.com/650810
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47849}

Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I1a9561adc44ee1d8a6b68c36604992261c490043
Reviewed-on: https://chromium-review.googlesource.com/651414Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47848}

Up to now, each architecture defined all Register types as structs,
with lots of redundancy. An often found comment noted that they cannot
be classes due to initialization order problems. As these problems are
gone with C++11 constexpr constants, I now tried making Registers
classes again.
All register types now inherit from RegisterBase, which provides a
default set of methods and named constructors (like ::from_code,
code(), bit(), is_valid(), ...).
This design allows to guarantee an interesting property: Each register
is either valid, or it's the no_reg register. There are no other
invalid registers. This is guaranteed statically by the constexpr
constructor, and dynamically by ::from_code.

I decided to disallow the default constructor completely, so instead of
"Register reg;" you now need "Register reg = no_reg;". This makes
explicit how the Register is initialized.

I did this change to the x64, ia32, arm, arm64, mips and mips64 ports.
Overall, code got much more compact and more safe. In theory, it should
also increase performance (since the is_valid() check is simpler), but
this is probably not measurable.

R=mstarzinger@chromium.org

Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a
Reviewed-on: https://chromium-review.googlesource.com/650927Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47847}