SuspendGenerator needs the accumulator to be live so that it can return
it.

Bug: chromium:806723
Change-Id: Iaa88fce96c36876e3e4256324ca650d475480c10
Reviewed-on: https://chromium-review.googlesource.com/975404Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52147}

This changes the encoding of the {HandlerTable} from an array of Smi
values to a byte array. It allows embedding of said array into the
instruction stream of {Code} objects (similar to how safepoint tables
work). For interpreted bytecode the table is attached as a {ByteArray}
to the bytecode.

The advantage of this approach is a more compact encoding and also the
ability to move such tables easily off the GC'ed heap if needed (as is
done for WebAssembly code for example).

R=jarin@chromium.org

Change-Id: I3320415dff69b3d1053825bda0d667a28232bf6d
Reviewed-on: https://chromium-review.googlesource.com/934642
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51589}

Currently, yields and awaits inside loops compile to bytecode which
switches to the top of the loop header, and switch again once inside the
loop. This is to make loops reducible.

This replaces this switching logic with a single switch bytecode that
directly jumps to the bytecode being resumed. Among other things, this
allows us to no longer maintain the generator state after the switch at
the top of the function, and avoid having to track loop suspend counts.

TurboFan still needs to have reducible loops, so we now insert loop
header switches during bytecode graph building, for suspends that are
discovered to be inside loops during bytecode analysis. We do, however,
do some environment magic across loop headers since we know that we will
continue switching if and only if we reached that loop header via a
generator resume. This allows us to generate fewer phis and tighten
liveness.

Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385
Reviewed-on: https://chromium-review.googlesource.com/866734
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50804}

Suspend points (inside generators and async functions) have slightly
funky semantics when it comes to liveness, as they save and restore a
chunk of the register file as-is. In particular, this means that
granular liveness information is lost, as it is assumed that all
registers in that chunk of the register file are live in a suspend.

Rather than marking that entire chunk of register as live/dead in
suspend/restore, we can instead pattern-match the set of bytecodes in a
suspend point, and propagate liveness across them. This tightens
liveness estimates, and could be used to optimize which values TurboFan
actually saves when suspending.

Bug: chromium:798137
Change-Id: I5840cdbfc2c6edb1d3a48cf025f52615b629cdfc
Reviewed-on: https://chromium-review.googlesource.com/848895
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50757}

AFAICT this doesn't currently change observable behavior, but should
be fixed nonetheless.

Change-Id: I1dce90ae5bcad39d7d54dddd2559bd7f7ccbb095
Reviewed-on: https://chromium-review.googlesource.com/648354Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47835}

R=leszeks@chromium.org

Change-Id: Iae67b6b81459304192c81b1367a11fba076c7512
Reviewed-on: https://chromium-review.googlesource.com/645630Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47741}

For wide bytecodes, save the bytecode offset as the offset of the prefix
bytecode, rather than the bytecode itself. This means that any code that reads
the bytecode can explicitly know the width of the bytecode at the offset
without having to iterate through the complete bytecode array.

Also simplifies some code in the bytecode analysis that had to work around
the previous approach.

BUG=chromium:753705

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

The accumulator should never be alive when jumping back to a loop
header, or jumping out of a loop. This means that as far as far as
TurboFan is concerned, we never need to create Phis or LoopExitValues
for the accumulator, as its value should not escape the loop.

For safety, this also augments the IsLivenessValid DCHECK in the
liveness analysis to check that the accumulator is not live in these
cases, and amends the bytecode analysis tests to kill the accumulator
where necessary to ensure this.

As a drive-by, added some comments to the more complex bytecode analysis
tests, since figuring out what they were for and how to fix them took a
non-trivial amount of time.

Change-Id: Idecf76a36681d724134c59768650c23cc6b0e9ef
Reviewed-on: https://chromium-review.googlesource.com/615168
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47388}

Now that OSR is done during graph building, we no longer have to
special-case OSR loops in the loop assignment analysis, as we no longer
have the restriction that registers are 'assigned' an OSRValue inside
the loop.

Bug: v8:6518
Change-Id: Ib4fa139091d77efa16246ddc6e63a10cbb877ee4
Reviewed-on: https://chromium-review.googlesource.com/615167Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47367}

Bug: chromium:750830
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Icab7b5a1c469d5e77d04df8bfca8319784e92af4
Reviewed-on: https://chromium-review.googlesource.com/595655
Commit-Queue: Julien Brianceau <jbriance@cisco.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47072}

This is a first step towards reducing the number of stores/loads when suspending/resuming a generator.

Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.

Changes:

- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
  * Resume generator reads the state out and marks the generator as
      'executing'.
  * RestoreGeneratorRegisters reloads the registers from
      the generator.
    + this required adding support for output register list.

- Introduced generator_object_ register in the bytecode generator.
  * in subsequent CLs, I will make better use of it, the goal is
      to get rid if the .generator_object local variable.

- Taught register optimizer to flush unassigned registers.

BUG=v8:6379

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

Introduce a new SwitchSmiTable bytecode for generators, which does a
table lookup for the accumulator value in a jump table stored in the
constant array pool. This removes the if-else chains at resumable
function/loop headers.

As a drive-by, add a scoped environment saving struct to the bytecode
graph builder.

Bug: v8:6351
Bug: v8:6366
Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0
Reviewed-on: https://chromium-review.googlesource.com/500271
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45314}

Instead of calculating the OSR entry point both in the bytecode analysis
and in the bytecode graph builder, calculate it once in the analysis and
use that calculation in the graph builder.

Old TODO from https://codereview.chromium.org/2558093005.

Change-Id: I071bc622beb55dc5eddaee25ef28e21fc4b477f0
Reviewed-on: https://chromium-review.googlesource.com/485899
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44888}

This fixes the checks of accumulator usage flags in the computation of
the interpreter register liveness during bytecode analysis. The usage
flags at hand are bit patterns as opposed to flat enum values. Use the
safe accessors instead of plain comparison.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-683581
BUG=chromium:683581

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

Adds assignment tracking to the bytecode analysis pass, and updates
bytecode graph builder to only create LoopExitValues for assigned
values.

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

Wrap the liveness bitvectors from the bytecode liveness analysis with a
helper class, which makes the register/accumulator bits explicit.

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

This allows us to optimise the bytecode liveness analysis to jump
directly to previously seen indices. The analysis is optimised to store
a stack of loop ends (JumpLoop bytecode indices), and iterate through
these indices directly rather than looping through the bytecode array to
find them.

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

This moves the location of the bytecode-offset translation that turns
offsets of back jumps into offsets of loop headers. This translation is
now done by the {BytecodeGraphBuilder} after loop analysis has been
performed. It safes one redudant iteration over the bytecode array. Note
that this changes the semantics of the BailoutId used as an {osr_ast_id}
throughout the compiler pipeline for OSR from Ignition.

R=jarin@chromium.org

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

Since the majority of bytecodes have a next instruction, and we iterate
over the bytecodes backwards, we can keep the previous seen (i.e.
sequentially next) bytecode's liveness on a variable instead of looking
it up again.

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

Replaces the graph-based liveness analyzer in the bytecode graph builder
with an initial bytecode-based liveness analysis pass, which is added to
the existing loop extent analysis.

Now the StateValues in the graph have their inputs initialised to
optimized_out, rather than being modified after the graph is built.

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

Revert of [ignition/turbo] Perform liveness analysis on the bytecodes (patchset #17 id:320001 of https://codereview.chromium.org/2523893003/ )

Reason for revert:
Breaks the build:

https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/14886

Original issue's description:
> [ignition/turbo] Perform liveness analysis on the bytecodes
>
> Replaces the graph-based liveness analyzer in the bytecode graph builder
> with an initial bytecode-based liveness analysis pass, which is added to
> the existing loop extent analysis.
>
> Now the StateValues in the graph have their inputs initialised to
> optimized_out, rather than being modified after the graph is built.
>
> Committed: https://crrev.com/1852300954c216c29cf93444430681d213e87925
> Cr-Commit-Position: refs/heads/master@{#41344}

TBR=jarin@chromium.org,rmcilroy@chromium.org,yangguo@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/2541443002
Cr-Commit-Position: refs/heads/master@{#41346}

Replaces the graph-based liveness analyzer in the bytecode graph builder
with an initial bytecode-based liveness analysis pass, which is added to
the existing loop extent analysis.

Now the StateValues in the graph have their inputs initialised to
optimized_out, rather than being modified after the graph is built.

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

Now that we have a JumpLoop bytecode, we can heavily simplify the
branch/loop analysis by assuming that only JumpLoop bytecodes are
backwards edges, and performing the loop analysis as a single
(backwards) pass.

This allows us to get rid of the branch analysis entirely, and builds a
framework to do liveness analysis in the same pass.

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