The existing implementation assumes that return nodes have exactly one
real value input. This assumption does not hold for WebAssembly. To
avoid incorrect behavior, this CL turns of the reduction of returns
with a value input count != 1.

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

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

Downside: this adds all kinds of weird includes in the .cc files.

(See design doc linked in the bug.)

BUG=v8:5402

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

Add a more efficient encoding for state values that have a large number of
optimized-out inputs.

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

Some instructions in WebAssembly trap for some inputs, which means that the
execution is terminated and (at least at the moment) a JavaScript exception is
thrown. Examples for traps are out-of-bounds memory accesses, or integer
divisions by zero.

Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
constant), in addition to the trap condition itself. Additionally, each
WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
number of inputs is linear to the number of trap checks in the function.
Especially for functions with high numbers of trap checks we observe a
significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
a TrapIf common operator only a single node is necessary per trap check, in
addition to the trap condition. Also the nodes which are shared between trap
checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
speedup of 30-50% on average.

This CL only implements TrapIf and TrapUnless on x64. The implementation is also
hidden behind the --wasm-trap-if flag.

Please take a special look at how the source position is transfered from the
instruction selector to the code generator, and at the context that is used for
the runtime call.

R=titzer@chromium.org

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

R=bbudge@chromium.org, titzer@chromium.org

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

This adds a new ExternalPointer type, which is an Internal type that is
used for ExternalReferences and other pointer values, like the pointers
into the asm.js heap. It also adds a PointerConstant operator, which we
use to represents these raw constants (we can probably remove that
particular operator again once WebAssembly ships with the validator).

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

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

This adds a new TypedObjectState operator, which is a version of
ObjectState that carries along MachineTypes for the inputs, so we
can tell the deoptimizer how to interpret the inputs, instead of
having to force everything to Tagged.

Drive-by-fix: Remove the unused id parameter from ObjectState.

R=tebbi@chromium.org
BUG=v8:5609

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

This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.

The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
  slots to pop upon return in addition to those specified by the Linkage of the
  compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
  handles all tail-call cases except where the return value type differs, this fallback
  was not really useful and in fact caused unexpected behavior with variable
  sized argument popping, since it wasn't possible to materialize a Return node
  with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
  pop argument since the variable pop functionality

LOG=N

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

Revert of [turbofan] Support variable size argument popping in TF-generated functions (patchset #13 id:240001 of https://codereview.chromium.org/2446543002/ )

Reason for revert:
Seems to break arm64 sim debug and blocks roll:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294

Original issue's description:
> [turbofan] Support variable size argument removal in TF-generated functions
>
> This is preparation for using TF to create builtins that handle variable number of
> arguments and have to remove these arguments dynamically from the stack upon
> return.
>
> The gist of the changes:
> - Added a second argument to the Return node which specifies the number of stack
>   slots to pop upon return in addition to those specified by the Linkage of the
>   compiled function.
> - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
>   handles all tail-call cases except where the return value type differs, this fallback
>   was not really useful and in fact caused unexpected behavior with variable
>   sized argument popping, since it wasn't possible to materialize a Return node
>   with the right pop count from the TailCall without additional context.
> - Modified existing Return generation to pass a constant zero as the additional
>   pop argument since the variable pop functionality
>
> LOG=N

TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
NOPRESUBMIT=true

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

This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.

The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
  slots to pop upon return in addition to those specified by the Linkage of the
  compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
  handles all tail-call cases except where the return value type differs, this fallback
  was not really useful and in fact caused unexpected behavior with variable
  sized argument popping, since it wasn't possible to materialize a Return node
  with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
  pop argument since the variable pop functionality

LOG=N

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

For inputs to truncating binary operations like <<, | or >>>, support
all Oddballs not just undefined, true and false. This unifies treatment
of these truncations in Crankshaft and TurboFan, and is very easy
nowadays, since the memory layout of Oddball and HeapNumber is
compatible.

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

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

Reland of "[turbofan] Osr value typing + dynamic type checks on entry. (patchset #5 id:80001 of https://codereview.chromium.org/2384113002/ )"

Fixes:

- Remove OsrGuards on frame specialization (for asm.js).
- Handle the rename in the walk for native context.
- Fix LoadContext effect wiring for Osr context chains.

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

Revert of [turbofan] Osr value typing + dynamic type checks on entry. (patchset #5 id:80001 of https://codereview.chromium.org/2384113002/ )

Reason for revert:
Tanks the world.

Original issue's description:
> [turbofan] Osr value typing + dynamic type checks on entry.
>
> This introduces a new OsrGuard node that is inserted during graph building
> to guard the inferred type of the OSR value.
>
> The type of the OSR value is inferred by running the typer before OSR
> deconstruction, and then taking the type from the phi that takes the
> OSR value. After the deconstruction, we throw the types away.
>
> At the moment we only support the SignedSmall OSR type and we always
> pick the tagged representation. Later, we might want to support more
> types (such as Number) and pick better representations (int32/float64).
>
> This CL also removes the OSR deconstruction tests because they build
> unrealistic graph (no effect chain, no loop termination). I considered
> adding the effect chains to the tests, but this would make the tests
> even more brittle.
>
> Committed: https://crrev.com/1f5dc90a900d222da44bee3eff171a2ba1e3c076
> Cr-Commit-Position: refs/heads/master@{#39971}

TBR=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/2395783002
Cr-Commit-Position: refs/heads/master@{#39985}

This introduces a new OsrGuard node that is inserted during graph building
to guard the inferred type of the OSR value.

The type of the OSR value is inferred by running the typer before OSR
deconstruction, and then taking the type from the phi that takes the
OSR value. After the deconstruction, we throw the types away.

At the moment we only support the SignedSmall OSR type and we always
pick the tagged representation. Later, we might want to support more
types (such as Number) and pick better representations (int32/float64).

This CL also removes the OSR deconstruction tests because they build
unrealistic graph (no effect chain, no loop termination). I considered
adding the effect chains to the tests, but this would make the tests
even more brittle.

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

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}

This adds cached versions of the DeoptimizeIf, DeoptimizeUnless and
Deoptimize operators that occur most often in various benchmarks.

R=jarin@chromium.org

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

BUG=

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

If we infer loop variable bounds, we need to insert a type rename node
(sigma) to make sure that simplified lowering can choose representations
consistently.

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

This completely removes translation of exception handler predictions
from the graph IR. We now rely on the runtime using deoptimization
infomation via {FrameSummary} for predictions in optimized code.

R=bmeurer@chromium.org

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

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}

The new phase will detect loop variable, infer bounds and bake them into
the type.

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

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.

BUG=v8:5167

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

We can actually eliminate certain effectful operations like loads and
speculative number operations during representation selection if we
discover that their value outputs are unused (we also propagate this
information through pure operations as well, so that we remove the
maximum number of effectful nodes possible).

R=jarin@chromium.org

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

So far TurboFan wasn't adding the deoptimization reasons for eager/soft
deoptimization exits that can be used by either the DevTools profiler or
the --trace-deopt flag. This adds basic support for deopt reasons on
Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
the reasons to the code generation.

Also moves the DeoptReason to it's own file (to resolve include cycles)
and drops unused reasons.

R=jarin@chromium.org

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

With this patch, every node in turbo-*.json has an opcode, a title, and
a label. The label field is new; the opcode and title were already
there. The title is for the mouseover text. The label is what will be
displayed in the graph view, unless it's too long, in which case only
the opcode will be displayed. (This is similar to the preexisting
behaviour of putting titles in labels, except that the titles were
rarely short enough to fit in a label.)

With this patch, the labels generated are in practice the same as the
titles we had before, except for LoadField and StoreField, which will be
rendered as LoadField[[+432]] and StoreField[[+432]] (if 432 was the
offset).

This diff adds an overloadable method

    virtual void Operator1<T>::PrintParameter(ostream&, PrintVerbosity)

for each type T to Operator1. Its default implementation just uses
operator<<(ostream&, T const&) and adds square brackets around it, but
it is overridden for FieldAccess to print "[+432]" in the example case.

BUG=
R=jarin,danno

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

This CL introduces explicit LoopExit control nodes at loop exits.
We also attach explicit value renames (LoopExitMarker) and effect
rename (LoopExitEffect) to each loop exit. This is in preparation
to loop peeling, which will replace LoopExit, LoopExitMarker and
LoopExitEffect with Merge, Phi and EffectPhi respectively.

At the moment, we insert loop exit at every return, break,
continue and locally caught throw. We do not yet handle
uncaught throws (including error throws, such as ReferenceError).

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

Add control dependencies to Projection and Int32Add/SubWithOverflow
operators, to prevent the scheduler from moving the Projection nodes
into the wrong place. This way the instruction selection can combine
the Int32Add/SubWithOverflow operations with the DeoptimizeIf and/or
DeoptimizeUnless nodes. This needs new operators CheckedInt32Add and
CheckedInt32Sub so that we can delay the actual lowering until the
effect/control linearizer.

This also makes CheckIf operator obsolete, so we can drop it.

R=jarin@chromium.org

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

These are used to check for Smi or HeapObject, and we use them
appropriately in JSNativeContextSpecialization, so we don't need
to introduce dependencies on concrete control flow and/or concrete
frame states.

They will be optimized by a proper check elimination reducer,
which will be added in a separate CL.

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

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

Previously, ZoneVector<MachineType>* printed just as a pointer; now we
print each MachineType in it, separated by commas.

BUG=

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

This is a first step towards explicit checkpoints in the graph. For now
we still use the explicit eager bailout points in the AstGraphBuilder
that are marked by the FrameStateBeforeAndAfter helper. Eventually these
will be implicitly emitted by expression visits having a side-effect.

R=bmeurer@chromium.org
BUG=v8:5021

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

R=bmeurer@chromium.org
BUG=v8:5021

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

The DeoptimizeIf and DeoptimizeUnless operators should actually produce
an effect in addition to the control output.

R=jarin@chromium.org

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

The type guard should never be used after the effect/control
linearization pass, so making it a simplified operator better
expresses the intended use. Also this way none of the common
operators actually has any dependency on the type system.

Drive-by-fix: Properly print the type parameter to a TypeGuard operator.

BUG=chromium:612142
R=jarin@chromium.org

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

This operator will be used to carry eager frame states, and is hooked up
to the effect chain with a control dependency to avoid hosting out of
control structures.

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

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

This operator was initially designed to handle arbitrary effect merging
for effect relaxation, but we don't do that (at least currently). So no
need to keep the dead operator around.

R=jarin@chromium.org

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

Add new relocation type WASM_MEMORY_SIZE_REFERENCE, use relocatable pointers to update wasm memory size references in generated code.
 - Add new RelocInfo mode WASM_MEMORY_SIZE_REFERENCE in the assembler and add relocation information to immediates in compare instructions.
 - Use relocatable constants for MemSize/BoundsCheck in the wasm compiler

R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org

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

This introduces a dedicated getter to extract call descriptors from
operators of call nodes (i.e. call and tail-call) to ensure that all
accesses are const-correct. An implicit cast of constness is undefined
behavior and hard to spot without sanitization.

R=jarin@chromium.org

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

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

The default NaN mode was originally used to identify holes in double
arrays. With (https://codereview.chromium.org/863633002/) signalling
NaNs are used for that, and the default NaN mode is not needed anymore.
Without the default NaN mode it is easier to satisfy the WebAssembly
spec which requires that quiet NaNs are preserved.

R=titzer@chromium.org, rodolph.perfetta@arm.com, bmeurer@chromium.org

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

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

Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates.

R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org

Committed: https://crrev.com/eb5fe0df64ec0add423b2a1f6fb62d5a33dce2a5
Cr-Commit-Position: refs/heads/master@{#35182}

Committed: https://crrev.com/297932a302ce0b73c3618ef9e4eba9d9d241f2b3
Cr-Commit-Position: refs/heads/master@{#35400}

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

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

Revert of [compiler] Add relocatable pointer constants for wasm memory references. (patchset #15 id:320001 of https://codereview.chromium.org/1759383003/ )

Reason for revert:
[Sheriff] Breaks msan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/7842

Original issue's description:
> [compiler] Add relocatable pointer constants for wasm memory references.
>
> Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates.
>
> R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org
>
> Committed: https://crrev.com/eb5fe0df64ec0add423b2a1f6fb62d5a33dce2a5
> Cr-Commit-Position: refs/heads/master@{#35182}
>
> Committed: https://crrev.com/297932a302ce0b73c3618ef9e4eba9d9d241f2b3
> Cr-Commit-Position: refs/heads/master@{#35400}

TBR=bradnelson@chromium.org,titzer@chromium.org,bmeurer@chromium.org,bradnelson@google.com,gdeepti@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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