Revert of [complier] Enable parallel eager inner function compilation with compiler dispatcher. (patchset #11 id:260001 of https://codereview.chromium.org/2611313002/ )

Reason for revert:
Some crashes on mac:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20-%20debug/builds/11982/steps/Ignition%20-%20turbofan/logs/regress-crbug-429159
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/10966

Original issue's description:
> [complier] Enable parallel eager inner function compilation with compiler dispatcher.
>
> Enable enqueueing of eager inner function compilation onto the compiler
> dispatcher. This enables these tasks to be performed in parallel to
> compilation of the outer functio (only for Ignition functions).
> We currently synchronize to ensure all inner function compilations
>  are complete before executing the outer function - future work will
> allow outer function execution to happenin parallel to inner function
> compilation.
>
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2611313002
> Cr-Commit-Position: refs/heads/master@{#42413}
> Committed: https://chromium.googlesource.com/v8/v8/+/f12661a1ece4e9c9cb8df5c2d349db960356e604

TBR=jochen@chromium.org,marja@chromium.org,mstarzinger@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215

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

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

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

Port 95f210d5

Original commit message:
Improve CheckedLoad and Store bounds checking for arrays with power of two
length.

BUG=

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

Enable enqueueing of eager inner function compilation onto the compiler
dispatcher. This enables these tasks to be performed in parallel to
compilation of the outer functio (only for Ignition functions).
We currently synchronize to ensure all inner function compilations
 are complete before executing the outer function - future work will
allow outer function execution to happenin parallel to inner function
compilation.

BUG=v8:5203,v8:5215

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

Reduce duplication of the inner function declaration + now we get the
test for inner arrow functions for free (if we later implement lazy
inner arrow functions).

BUG=v8:5501, v8:5516

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

Background: the first page of each space is implicitly immovable.
Recently, our builtin code objects have reached a size at which we
fill up the first page of code space during initialization. Once
that occurs, newly requested allocations of immovable code are
allocated in a large object space page of 512K.

This CL mitigates these effects by simply marking pages as immovable
during snapshot creation instead of going into LO space.

On snapshot builds, this should just work: deserialized pages are
trimmed and marked immovable when deserialization finishes.

However, non-snapshot builds and allocations of immovable CEntryStub
code at runtime are still affected.

BUG=v8:5831

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

BUG=chromium:681806
NOTRY=true
TBR=titzer@chromium.org,bradnelson@chromium.org

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

This is just a bug. CompileLazy knows how to look in the
SharedFunctionInfo for code (or bytecode, essentially) if it
finds nothing in the OptimizedCodeMap. Ensure that behavior.

BUG=681543
R=leszeks@chromium.org

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

When a function is declared in global scope, the closure is created
by the DeclareGlobals runtime service. It needs a pointer to the
literals array, already allocated in the feedback vector. This
fixes a bug where it's behavior wasn't in sync with CreateClosure,
which accepts the literals from the vector.

This enables a follow-on performance improvement in the CompileLazy
builtin.

BUG=680637

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

The resume trampolin used to call the generator function with the context of the
last suspension rather than the closure's context.  While that was fine for
Ignition, Turbofan got utterly confused.  With this CL, the resume trampolin
always passes in the closure's context (like in the very first call of the
generator function).  The generator function itself then restores its previously
current context by reading it from the generator object and doing a
PushContext.

BUG=chromium:681171

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

Fixes failure on spec test globals.wast.

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

BUG=v8:5402

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

Instead, it is supposed to just return an empty context if it failed.
Also don't invoke interceptors (we don't for the parts that deserialize
from the snapshot anyways).

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

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

This internalization was not necessary, since the rewriting does not use
the .result name string.

The subsequent internalization is still needed, so to simplify later
refactoring, this CL also adds "releasing" of the disallow scopes and
uses them here immediately before the second internalize. Notably, this
means that the rewriting is now also in the disallow scopes.

Driveby: Remove isolate from the rewriter's processor constructor.

BUG=v8:5832

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

BUG=chromium:681088,chromium:681236
NOTRY=true
TBR=bradnelson@chromium.org, titzer@chromium.org

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

BUG=v8:5495

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

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

This makes sure all call sites allocating and installing the feedback
vector metadata are within the compilation pipeline and avoids spreading
them accross components.

R=leszeks@chromium.org

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

We have to pessimistically assume that top-level variables will be assigned.
This is because there may be lazily parsed top-level functions, which, for
efficiency, we preparse without variable tracking.

R=adamk@chromium.org, marja@chromium.org
CC=jarin@chromium.org
BUG=v8:5636

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

BUG=651354

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

BUG=chromium:681326
NOTRY=true
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org

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

This makes it clearer which places are creating variables which are
something else than NORMAL_VARIABLE + kCreatedInitialized.

BUG=

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

Creates an AstStringConstants container which pre-initializes the
string constants used by AstValueFactory. This ensures that all
AstValueFactories will produce the same AstValue objects for constants,
and so they can be used by the BytecodeGenerator without having to pass
the AstValueFactory to it, enabling construction off-thread.

BUG=v8:5203

Review-Url: https://codereview.chromium.org/2630343002
Cr-Original-Commit-Position: refs/heads/master@{#42381}
Committed: https://chromium.googlesource.com/v8/v8/+/d611496b8ed30af787d8668f96b400617c858508
Review-Url: https://codereview.chromium.org/2630343002
Cr-Commit-Position: refs/heads/master@{#42394}

A GC could happen when creating the Module string, which would cause the
JSModuleNamespace to be seen in an incomplete state. Instead make this
string a root object so that we don't need to allocate it during
NewJSModuleNamespace construction.

BUG=v8:1569

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

BUG=chromium:667678
NOTRY=true
TBR=titzer@chromium.org,bradnelson@chromium.org

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

R=jochen@chromium.org
BUG=

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

In V8, we always want the pointer alignment to be left, i.e. "Foo* foo"
instead of "Foo *foo".

R=jochen@chromium.org
NOTRY=true

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9a3fba5..f55127d

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/95b3e83..143ba4d

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

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

KillFields of an object should remove its cache from all the fields.
Currently, the cache in the front field is kept which is not expected.
This patch fixes it.

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

RotleftAndMask32 is not efficient on s390

R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com
BUG=

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

BUG=chromium:673246
NOTRY=true

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

- Adds vmin, vmax for FP and integer vectors, both signed and unsigned.
- Regularizes switching logic in disasm and simulator for special codes
4 and 6.
- Factors vrecpe, vrsqrte, vrecps, vrsqrts into helper fns.

LOG=N
BUG=v8:4124

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

R=titzer@chromium.org
BUG=v8:5840

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

BUG=v8:5829

patch from issue 2634493004 at patchset 20001 (http://crrev.com/2634493004#ps20001)

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

Revert of [Parser] Introduce AstStringConstants to share constants across AstValueFactory (patchset #4 id:80001 of https://codereview.chromium.org/2630343002/ )

Reason for revert:
Seems to break modules-namespace2 on gcstress.

Original issue's description:
> [Parser] Introduce AstStringConstants to share constants across AstValueFactory
>
> Creates an AstStringConstants container which pre-initializes the
> string constants used by AstValueFactory. This ensures that all
> AstValueFactories will produce the same AstValue objects for constants,
> and so they can be used by the BytecodeGenerator without having to pass
> the AstValueFactory to it, enabling construction off-thread.
>
> BUG=v8:5203
>
> Review-Url: https://codereview.chromium.org/2630343002
> Cr-Commit-Position: refs/heads/master@{#42381}
> Committed: https://chromium.googlesource.com/v8/v8/+/d611496b8ed30af787d8668f96b400617c858508

TBR=ahaas@chromium.org,marja@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203

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

Creates an AstStringConstants container which pre-initializes the
string constants used by AstValueFactory. This ensures that all
AstValueFactories will produce the same AstValue objects for constants,
and so they can be used by the BytecodeGenerator without having to pass
the AstValueFactory to it, enabling construction off-thread.

BUG=v8:5203

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

Our .clang-format is derived on the Google style, which sets
PointerAlignment to left (e.g. "Type* name"), but sets
DerivePointerAlignment to true. Once we started with the wrong style,
this made all new code in wasm-debug.cc use PointerAlignment=right,
resulting in lots of code using the wrong style.

For this CL, I ran
clang-format -style="{DerivePointerAlignment: false, BasedOnStyle: \
  Google}" -i src/wasm/wasm-debug.cc

R=titzer@chromium.org

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

R=titzer@chromium.org
BUG=

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

BUG=

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

BUG=v8:5832

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