[Interpreter] Move jump processing to bytecode array writer.

[Interpreter] Move jump processing to bytecode array writer.

This moves processing of jumps out of bytecode array builder and into
bytecode array writer. This simplifies the pipeline by avoiding having
to flush for offset and patch up offsets in bytecode array builder based
on what was emitted by the bytecode array writer.

This also enables future refactorings to add dead code elimination back
into the pipeline, and move processing of scalable operand sizes to the
end of the pipeline (in the bytecode array writer) rather than having to
deal with scalable operand types throughout pipeline.

BUG=v8:4280, chromium:616064
Committed: https://crrev.com/de9d1d8bc6a79e9f488c606f302527f1c2a34a69
Cr-Commit-Position: refs/heads/master@{#36716}

[rmcilroy, 2016-06-02 16:37:59]

The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-02 16:38:07]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2035813002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2035813002/1

[rmcilroy, 2016-06-02 16:49:43]

The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-02 16:49:47]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2035813002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2035813002/20001

[rmcilroy, 2016-06-02 17:02:28]

Patchset #1 (id:1) has been deleted

[rmcilroy, 2016-06-02 17:05:20]

rmcilroy@chromium.org changed reviewers:
+ oth@chromium.org

[rmcilroy, 2016-06-02 17:05:20]

I'll run some benchmarks tomorrow but I don't think this should impact perf too
much, and the test bots seem happy.

Please take a look, thanks.

[commit-bot: I haz the power, 2016-06-02 17:15:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-02 17:15:39]

Dry run: This issue passed the CQ dry run.

[oth, 2016-06-03 09:50:21]

LGTM. Not as painful as expected, good job here.

https://codereview.chromium.org/2035813002/diff/20001/test/unittests/interpre...
File test/unittests/interpreter/bytecode-array-builder-unittest.cc (right):

https://codereview.chromium.org/2035813002/diff/20001/test/unittests/interpre...
test/unittests/interpreter/bytecode-array-builder-unittest.cc:356: // Insert
entries for bytecodes only emiited by peephole optimizer.
emitted

https://codereview.chromium.org/2035813002/diff/20001/test/unittests/interpre...
test/unittests/interpreter/bytecode-array-builder-unittest.cc:362: if
(!FLAG_ignition_peephole) {
Comment here explaining why the delta.

[rmcilroy, 2016-06-03 14:12:43]

Description was changed from

==========
[Interpreter] Move jump processing to bytecode array writer.

This moves processing of jumps out of bytecode array builder and into
bytecode array writer. This simplifies the pipeline by avoiding having
to flush for offset and patch up offsets in bytecode array builder based
on what was emitted by the bytecode array writer.

This also enables future refactorings to add dead code elimination back
into the pipeline, and move processing of scalable operand sizes to the
end of the pipeline (in the bytecode array writer) rather than having to
deal with scalable operand types throughout pipeline.

BUG=v8:4280
==========

to

==========
[Interpreter] Move jump processing to bytecode array writer.

This moves processing of jumps out of bytecode array builder and into
bytecode array writer. This simplifies the pipeline by avoiding having
to flush for offset and patch up offsets in bytecode array builder based
on what was emitted by the bytecode array writer.

This also enables future refactorings to add dead code elimination back
into the pipeline, and move processing of scalable operand sizes to the
end of the pipeline (in the bytecode array writer) rather than having to
deal with scalable operand types throughout pipeline.

BUG=v8:4280,chromium:616064
==========

[rmcilroy, 2016-06-03 14:27:15]

https://codereview.chromium.org/2035813002/diff/20001/test/unittests/interpre...
File test/unittests/interpreter/bytecode-array-builder-unittest.cc (right):

https://codereview.chromium.org/2035813002/diff/20001/test/unittests/interpre...
test/unittests/interpreter/bytecode-array-builder-unittest.cc:356: // Insert
entries for bytecodes only emiited by peephole optimizer.
On 2016/06/03 09:50:21, oth wrote:
> emitted

Done.

https://codereview.chromium.org/2035813002/diff/20001/test/unittests/interpre...
test/unittests/interpreter/bytecode-array-builder-unittest.cc:362: if
(!FLAG_ignition_peephole) {
On 2016/06/03 09:50:21, oth wrote:
> Comment here explaining why the delta.

Added writes for the preceding Ldr instructions and moved all setting of the
scorecard into this if (!FLAG_ignition_peephole) with the same comment.

[rmcilroy, 2016-06-03 14:27:20]

The CQ bit was checked by rmcilroy@chromium.org

[rmcilroy, 2016-06-03 14:27:21]

The patchset sent to the CQ was uploaded after l-g-t-m from oth@chromium.org
Link to the patchset: https://codereview.chromium.org/2035813002/#ps40001
(title: "Address comments")

[commit-bot: I haz the power, 2016-06-03 14:27:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2035813002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2035813002/40001

[commit-bot: I haz the power, 2016-06-03 14:53:04]

Description was changed from

==========
[Interpreter] Move jump processing to bytecode array writer.

This moves processing of jumps out of bytecode array builder and into
bytecode array writer. This simplifies the pipeline by avoiding having
to flush for offset and patch up offsets in bytecode array builder based
on what was emitted by the bytecode array writer.

This also enables future refactorings to add dead code elimination back
into the pipeline, and move processing of scalable operand sizes to the
end of the pipeline (in the bytecode array writer) rather than having to
deal with scalable operand types throughout pipeline.

BUG=v8:4280,chromium:616064
==========

to

==========
[Interpreter] Move jump processing to bytecode array writer.

This moves processing of jumps out of bytecode array builder and into
bytecode array writer. This simplifies the pipeline by avoiding having
to flush for offset and patch up offsets in bytecode array builder based
on what was emitted by the bytecode array writer.

This also enables future refactorings to add dead code elimination back
into the pipeline, and move processing of scalable operand sizes to the
end of the pipeline (in the bytecode array writer) rather than having to
deal with scalable operand types throughout pipeline.

BUG=v8:4280,chromium:616064
==========

[commit-bot: I haz the power, 2016-06-03 14:53:05]

Committed patchset #2 (id:40001)

[commit-bot: I haz the power, 2016-06-03 14:53:33]

Description was changed from

==========
[Interpreter] Move jump processing to bytecode array writer.

This moves processing of jumps out of bytecode array builder and into
bytecode array writer. This simplifies the pipeline by avoiding having
to flush for offset and patch up offsets in bytecode array builder based
on what was emitted by the bytecode array writer.

This also enables future refactorings to add dead code elimination back
into the pipeline, and move processing of scalable operand sizes to the
end of the pipeline (in the bytecode array writer) rather than having to
deal with scalable operand types throughout pipeline.

BUG=v8:4280,chromium:616064
==========

to

==========
[Interpreter] Move jump processing to bytecode array writer.

This moves processing of jumps out of bytecode array builder and into
bytecode array writer. This simplifies the pipeline by avoiding having
to flush for offset and patch up offsets in bytecode array builder based
on what was emitted by the bytecode array writer.

This also enables future refactorings to add dead code elimination back
into the pipeline, and move processing of scalable operand sizes to the
end of the pipeline (in the bytecode array writer) rather than having to
deal with scalable operand types throughout pipeline.

BUG=v8:4280,chromium:616064

Committed: https://crrev.com/de9d1d8bc6a79e9f488c606f302527f1c2a34a69
Cr-Commit-Position: refs/heads/master@{#36716}
==========

[commit-bot: I haz the power, 2016-06-03 14:53:34]

Patchset 2 (id:??) landed as
https://crrev.com/de9d1d8bc6a79e9f488c606f302527f1c2a34a69
Cr-Commit-Position: refs/heads/master@{#36716}