Commit Graph

6 Commits

Author SHA1 Message Date
oth
769d332619 [interpreter] Filter expression positions at source.
With this change the bytecode array builder only emits expression
positions for bytecodes that can throw. This allows more peephole
optimization opportunities and results in smaller code.

BUG=v8:4280,chromium:615979
LOG=N

Review-Url: https://codereview.chromium.org/2038323002
Cr-Commit-Position: refs/heads/master@{#36863}
2016-06-09 13:33:29 +00:00
oth
25b3fe7961 [interpreter] Introduce fused bytecodes for common sequences.
This change introduces five fused bytecodes for common bytecode
sequences on popular websites. These are LdrNamedProperty,
LdrKeyedProperty, LdrGlobal, LdrContextSlot, and LdrUndefined. These
load values into a destination register operand instead of the
accumulator. They are emitted by the peephole optimizer.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/1985753002
Cr-Commit-Position: refs/heads/master@{#36507}
2016-05-25 09:56:49 +00:00
mvstanton
a6ddbef064 Collect call counts for constructor calls, too.
The TurboFan inliner makes use of these counts.

BUG=

Review-Url: https://codereview.chromium.org/1969783002
Cr-Commit-Position: refs/heads/master@{#36472}
2016-05-24 11:53:45 +00:00
oth
52600c6b1c [interpreter] Add checks for source position to test-bytecode-generator.
Prints source position information alongside bytecode.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/1963663002
Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:22:17 +00:00
oth
48d082af38 [interpreter] Add support for scalable operands.
This change introduces wide prefix bytecodes to support wide (16-bit)
and extra-wide (32-bit) operands. It retires the previous
wide-bytecodes and reduces the number of operand types.

Operands are now either scalable or fixed size. Scalable operands
increase in width when a bytecode is prefixed with wide or extra-wide.

The bytecode handler table is extended to 256*3 entries. The
first 256 entries are used for bytecodes with 8-bit operands,
the second 256 entries are used for bytecodes with operands that
scale to 16-bits, and the third group of 256 entries are used for
bytecodes with operands that scale to 32-bits.

LOG=N
BUG=v8:4747,v8:4280

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

Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:09:49 +00:00
ssanfilippo
6ae030590d [Interpreter] Refactor bytecode generator test suite.
Bytecode expectations have been moved to external (.golden) files,
one per test. Each test in the suite builds a representation of the
the compiled bytecode using BytecodeExpectationsPrinter. The output is
then compared to the golden file. If the comparision fails, a textual
diff can be used to identify the discrepancies.

Only the test snippets are left in the cc file, which also allows to
make it more compact and meaningful. Leaving the snippets in the cc
file was a deliberate choice to allow keeping the "truth" about the
tests in the cc file, which will rarely change, as opposed to golden
files.

Golden files can be generated and kept up to date using
generate-bytecode-expectations, which also means that the test suite
can be batch updated whenever the bytecode or golden format changes.

The golden format has been slightly amended (no more comments about
`void*`, add size of the bytecode array) following the consideration
made while converting the tests.

There is also a fix: BytecodeExpectationsPrinter::top_level_ was left
uninitialized, leading to undefined behaviour.

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:19 +00:00