Consistently collect CallIC feedback in fullcodegen and Ignition, even
for possibly direct eval calls, that were treated specially so far, for
no apparent reason. With the upcoming SharedFunctionInfo based CallIC
feedback, we might be able to even inline certain direct eval calls, if
they manage to hit the eval cache. More importantly, this patch
simplifies the collection and dealing with CallIC feedback (and as a
side effect fixes an inconsistency with feedback for super constructor
calls).
R=mvstanton@chromium.org, mythria@chromium.org
BUG=v8:2206,v8:4280,v8:5267
Review-Url: https://codereview.chromium.org/2426693002
Cr-Commit-Position: refs/heads/master@{#40397}
There are only a few occasions where we allocate a register in an outer
expression allocation scope, which makes the costly free-list approach
of the BytecodeRegisterAllocator unecessary. This CL replaces all
occurrences with moves to the accumulator and stores to a register
allocated in the correct scope. By doing this, we can simplify the
BytecodeRegisterAllocator to be a simple bump-pointer allocator
with registers released in the same order as allocated.
The following changes are also made:
- Make BytecodeRegisterOptimizer able to use registers which have been
unallocated, but not yet reused
- Remove RegisterExpressionResultScope and rename
AccumulatorExpressionResultScope to ValueExpressionResultScope
- Introduce RegisterList to represent consecutive register
allocations, and use this for operands to call bytecodes.
By avoiding the free-list handling, this gives another couple of
percent on CodeLoad.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2369873002
Cr-Commit-Position: refs/heads/master@{#39905}
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).
Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.
Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).
See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8
BUG=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
Moves the context chain search loop out of generated bytecode, and into
the (Lda|Ldr|Sda)ContextSlot handler, by passing the context depth in as
an additional operand. This should decrease the bytecode size and
increase performance for deep context chain searches, at the cost of
slightly increasing bytecode size for shallow context access.
Review-Url: https://codereview.chromium.org/2336643002
Cr-Commit-Position: refs/heads/master@{#39378}
Lexically declared "arguments" in sloppy mode will throw redeclaration error
currently, this patch fixes it by delaying the declaration of arguments until we
fully parse parameter list and function body.
BUG=v8:4577
LOG=N
Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa
Review-Url: https://codereview.chromium.org/2290753003
Cr-Original-Commit-Position: refs/heads/master@{#39109}
Cr-Commit-Position: refs/heads/master@{#39230}
For historical reasons, the interpreter's bytecode expectations tests
required a type for the constant pool. This had two disadvantages:
1. Strings and numbers were not visible in mixed pools, and
2. Mismatches of pool types (e.g. when rebaselining) would cause parser
errors
This removes the pool types, making everything 'mixed', but appending
the values to string and number valued constants. Specifying a pool type
in the *.golden header now prints a warning (for backwards compatibility).
BUG=v8:5350
Review-Url: https://codereview.chromium.org/2310103002
Cr-Commit-Position: refs/heads/master@{#39216}
Reason for revert:
Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/9470
Original issue's description:
> Allow lexically declared "arguments" in function scope in sloppy mode.
>
> Lexically declared "arguments" in sloppy mode will throw redeclaration error
> currently, this patch fixes it by delaying the declaration of arguments until we
> fully parse parameter list and function body.
>
> BUG=v8:4577
> LOG=N
>
> Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa
> Cr-Commit-Position: refs/heads/master@{#39109}
TBR=adamk@chromium.org,mythria@chromium.org,lpy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4577
Review-Url: https://codereview.chromium.org/2304853002
Cr-Commit-Position: refs/heads/master@{#39115}
Lexically declared "arguments" in sloppy mode will throw redeclaration error
currently, this patch fixes it by delaying the declaration of arguments until we
fully parse parameter list and function body.
BUG=v8:4577
LOG=N
Review-Url: https://codereview.chromium.org/2290753003
Cr-Commit-Position: refs/heads/master@{#39109}
Add a new bytecode to create a function context. The handler inlines
FastNewFunctionContextStub.
BUG=v8:4280
LOG=n
Review-Url: https://codereview.chromium.org/2187523002
Cr-Commit-Position: refs/heads/master@{#38301}
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}
Reason for revert:
performance impact
Original issue's description:
> Correctly annotate eval origin.
>
> There were a couple of issues with it:
> - interpreter is not supported
> - the source position was just accidentally correct for full-codegen
> - the eval origin could have been cached
>
> Also fixes a few other places to use AbstractCode.
>
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d
> Cr-Commit-Position: refs/heads/master@{#35257}
>
> Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16
> Cr-Commit-Position: refs/heads/master@{#35481}
TBR=mstarzinger@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/1888013002
Cr-Commit-Position: refs/heads/master@{#35491}
There were a couple of issues with it:
- interpreter is not supported
- the source position was just accidentally correct for full-codegen
- the eval origin could have been cached
Also fixes a few other places to use AbstractCode.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1854713002
Cr-Commit-Position: refs/heads/master@{#35257}
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}
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}
