Reason for revert:
Breaks https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug%20builder/builds/3144

Original issue's description:
> Update V8 DEPS.
>
> Rolling v8/base/trace_event/common to 199985e01e17b5a4888f83648b7cc119779e9245
>
> Rolling v8/build to 4803815de7294778a1496c4e7f3e84ee48e243ef
>
> Rolling v8/buildtools to 57649e5e2001ba1f5e5d45f5a838c616ea0e9cb9
>
> Rolling v8/tools/clang to cca919b21f2436ba1585f7e9de2702ba64fbd8bf
>
> TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
>
> Committed: https://crrev.com/0ed1254d8103b40d5880601bf73b6c56e4d5716d
> Cr-Commit-Position: refs/heads/master@{#39570}

TBR=hablich@chromium.org,vogelheim@chromium.org,v8-autoroll@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/2351943005
Cr-Commit-Position: refs/heads/master@{#39578}

R=marja@chromium.org

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

BUG=

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

When we added the new MachineRepresentation::kTaggedSigned and
MachineRepresentation::kTaggedPointer, we didn't extend the logic
for memory operand covering, and so for map checks and other
comparisons with fields we'd always need an additional register.
This fixes that and does reduce register pressure in some cases.

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

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

Runtime.evaluate can return result by value. We need to provide more details why method call was failed.

BUG=chromium:645640
R=dgozman@chromium.org,alph@chromium.org

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

R=hablich@chromium.org, jarin@chromium.org

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

BUG=chromium:635948
R=alph@chromium.org

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

- Add a new container object to store the data required for
PromiseResolveThenableJob.

- Create a new runtime function to enqueue the microtask event with
the required data.

This patches causes a 4% regression in the bluebird benchmark.

BUG=v8:5343

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

Rolling v8/base/trace_event/common to 199985e01e17b5a4888f83648b7cc119779e9245

Rolling v8/build to 4803815de7294778a1496c4e7f3e84ee48e243ef

Rolling v8/buildtools to 57649e5e2001ba1f5e5d45f5a838c616ea0e9cb9

Rolling v8/tools/clang to cca919b21f2436ba1585f7e9de2702ba64fbd8bf

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

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

This patch gives the ability for the embedder to ask for the
module requests of a module, and to pass a ResolveCallback
into Module::Instantiate().

In d8, I've implemented a simple module_map that's used
along with this API to allow loading, compiling, instantiating,
and evaluating a whole tree of modules.

No path resolution is yet implemented, meaning that all
import paths are relative to whatever directory d8 runs
in. And no imports are linked to the exports of the
requested module.

BUG=v8:1569

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

This is in preparation for basic support of import statements.

R=adamk@chromium.org
BUG=v8:1569

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

This patch ensures that variables like .new_target aren't overwritable
using with scopes. It does this by ensuring that scope analysis does
not consider with scopes (or eval scopes) for such 'synthetic variables',
similarly to how the 'this' variable was already handled.
The patch also adds a DCHECK for the dynamic parallel to this case,
replacing a previous unreachable path for a particular instance.

BUG=v8:5405

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

This patch uses temporaries rather than unresolved variables for
.promise and .debug_is_active. For .promise, a new field is added
to the FunctionState, similarly to .generator_object. This change
fixes a bug where .promise was locally shadowable by with, affecting
program semantics.

BUG=v8:5405

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

To improve performance, this patch makes Promise.all and Promise.race not
perform correct catch prediction when the debugger is not open. The case
may come up if Promise.race or Promise.all is called, then DevTools is
open, then a component Promise is rejected. In this case, the user would
falsely get an exception event even if the "pause on caught exceptions"
box is unchecked. There are tests which triggered this case; however, it
seems both unlikely and and acceptable to have an event in this case.
Many analogous events are already produced when DevTools is enabled
during the operation of a program.

BUG=v8:3093

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

This patch knits together Promises returned by async/await such that when
one async function awaits the result of another one, catch prediction works
across the boundaries, whether the exception comes synchronously or
asynchronously. Edges are added in three places:
- When a locally uncaught await happens, if the value passed into await
  is a Promise, from the awaited value to the Promise under construction
  in the broader async function
- From a "throwaway" Promise, which may be found on the Promise debug
  stack, to the Promise under construction in the async function that
  surrounds it
- When a Promise is resolved with another Promise (e.g., when returning a
  Promise from an async function)

In this reland, the caught tests are broken up into four parts to avoid
timeouts.

BUG=v8:5167

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

Also simplify Factory::NewModule to take only the SharedFunctionInfo.

R=neis@chromium.org
BUG=v8:1569

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

The CreateArrayLiteral bytecode handler now directly inlines the FastCloneShallowArrayStub.

BUG=v8:4280

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

    Port 7f3d15aa

    Original commit message:
    In ignition, arguments to function calls and function constructors are
    pushed onto the stack before calling the function. It is required to check
    that stack does not overflow when pushing the arguments.

    R=mythria@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=

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

Fix a typo in TypeFeedbackVector::ComputeCounts, where we would not
skip the interpreter binary/compare op IC slots for fullcodegen, and
thus mess up the heuristics for tearing up.

TBR=mvstanton@chromium.org

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

R=adamk@chromium.org
BUG=

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

This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.

BUG=v8:5409

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

Here we only change the type of the slot set fields to atomic values and use CAS to change the state. There is no change in behavior or semantics of the slot set.

BUG=chromium:648568

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

BUG=chromium:647329
R=titzer@chromium.org
TEST=unittest EncoderTest.Regression_647329

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

Full code uses patching ICs for this feedback, and the interpreter uses
the type feedback vector. It's a good idea to code the vector slots
appropriately as ICs so that the runtime profiler can better gauge if
the function is ready for tiering up from Ignition to TurboFan.

As is, the feedback is stored in "general" slots which can't be
characterized by the runtime profiler into feedback states.

This CL addresses that problem. Note that it's also important to
carefully exclude these slots from the profiler's consideration when
determining if you want to optimize from Full code.

BUG=

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

- Eliminates *all* copies in the process.
- Moves (nearly) all functionality into Scanner::BookmarkScope.
- Significant code reduction.

[Needs to be rebased once crrev.com/2347883002 lands. All changes in *parser* are from that CL.]

R=marja@chromium.org
BUG=v8:4947

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

This makes sure generator functions are marked as optimizable for all
configurations where the BytecodeGraphBuilder is used. Note that as
usual AstNumbering is just a heuristic and the underlying compiler can
still bailout from optimization when the compilation pipeline chooses
another compiler that does not support generator functions.

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

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

Due to a typo, long branches were emitted instead of short branches, and the
code would stop working at all in the situation when long branches must be
emitted. This patche fixes this issue.

TEST=mjsunit/wasm/embenchen/lua_binarytrees
BUG=

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

The implicit assignment to the induction variable in a ForInStatement
has been ignored by the AST loop assignment analysis. This was hidden
for cases where the parser introduced a ".for" temporary, but triggers
when the variable is declared outside the loop.

R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647887
BUG=chromium:647887

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

Refactors CodeStubAssembler::AllocateJSArray to share code.

BUG=chromium:608675

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

This will allow to simplify the miss part of store IC handlers when we decide
to pass value/slot/vector on the stack.

BUG=v8:5407

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

This means we can no longer take the closure's context to parse, but
need to rely on the outer scope info.

Since it's not possible to get that, however, for lazy functions, we
introduce a new field to SharedFunctionInfo that stores the outer scope
info whenever available.

BUG=v8:5215
R=marja@chromium.org,verwaest@chromium.org,jgruber@chromium.org

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

This commit ensures that the d8 shared library build uses the same logic as
the standard static build by exporting relevant functions and classes.

BUG=chromium:646337

Committed: https://crrev.com/2c10ca8086a4d595ecf9aa843d2031b068470d65
Review-Url: https://codereview.chromium.org/2342563002
Cr-Original-Commit-Position: refs/heads/master@{#39503}
Cr-Commit-Position: refs/heads/master@{#39547}

R=verwaest@chromium.org,marja@chromium.org

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

Removes some unnecessary probing in TemplateHashMapImpl, in
particular probing a second time in LookupOrInsert after the
first probe came up with an empty value.

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

BUG=

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

... because the latter automatically respects the desired calling convention.

BUG=v8:5407

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

BUG=

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

BUG=chromium:642111

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

Extract String feedback on Add operation and utilize to lower ConsString
creation in JSTypedLowering when we know that a String addition will
definitely result in the creation of a ConsString.

Note that Crankshaft has to guard the potential length overflow of the
resulting string with an eager deoptimization exit, while we can safely
throw an exception in that case.

Also note that the bytecode pipeline does not currently provide the
String feedback for the addition, which has to be added.

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

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

R=jarin@chromium.org

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