Removes the register file machine register from the interpreter and
replaces it will loads from the parent frame pointer. As part of this
change the raw operand values for register values changes to enable the
interpreter to keep using the operand value as the offset from the
parent frame pointer.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1894063002
Cr-Commit-Position: refs/heads/master@{#35618}
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}
When seeing a rest pattern, we used to get the remaining elements from the
iterator by calling %concat_iterable_to_array on it. This was wrong because it
caused an observable [[Get]] for @@iterator (which the iterator may not even
provide).
This CL gets rid of the call to %concat_iterable_to_array and does the iteration
manually in a simple while-loop. It also gets rid of %concat_iterable_to_array
itself because there aren't any other uses of it.
BUG=v8:4759
LOG=n
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1852703002
Cr-Commit-Position: refs/heads/master@{#35251}
The parser uses a try-catch in order to record when the client of an iterator
throws. The exception then used to get rethrown via 'throw', which
unfortunately resulted in the original exception message object getting
overwritten.
This CL solves this as follows:
- add a clear_pending_message flag to TryCatchStatement (set to true in normal
cases),
- set clear_pending_message to false for the TryCatchStatement used in iterator
finalization
- change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call
only when the flag is set,
- replace 'throw' with '%ReThrow' in the iterator finalization code, thus
reusing the (not-cleared) pending message
R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4875
LOG=n
Review URL: https://codereview.chromium.org/1842953003
Cr-Commit-Position: refs/heads/master@{#35226}
A bug in error printing meant that we failed to do proper type checks
before calling into C++ code, which could lead to RUNTIME_ASSERT
failures if methods are called on alternative receivers. This patch
adds the right type checks.
BUG=chromium:596718
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1831053003
Cr-Commit-Position: refs/heads/master@{#35069}
This patch implements ES2015 RegExp subclassing semantics, namely the
hardest part where RegExp.prototype.exec and certain flag getters can
be overridden in order to provide different behavior. This change is
hidden behind a new flag, --harmony-regexp-exec. The flag guards the
behavior by installing entirely different implementations of the
methods which follow the new semantics.
Preliminary performance tests show a 3-4x regression in the Octane
RegExp benchmark. The new code doesn't call out into several fast
paths that the old code supported, so this is expected.
The patch is tested mostly by test262, where most RegExp tests are fixed,
with the exception of deliberate spec violations for web compatibility,
and for the 'sticky' flag, which is not dynamically read by this patch
in all cases but rather statically compiled into the RegExp. The latter
will require a follow-on patch to implement. A small additional set of
tests verifies one particular case, mostly to check whether the flag
mechanism works.
R=adamk,yangguo@chromium.org
LOG=Y
BUG=v8:4602
Review URL: https://codereview.chromium.org/1596483005
Cr-Commit-Position: refs/heads/master@{#35068}
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.
In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.
Also gone are any tests which relied on legacy const declarations.
Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.
Review URL: https://codereview.chromium.org/1819123002
Cr-Commit-Position: refs/heads/master@{#35002}
Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call.
BUG=v8:4822
LOG=y
Review URL: https://codereview.chromium.org/1645763003
Cr-Commit-Position: refs/heads/master@{#34983}
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}
We need to pop the context to correct level on return as well. This was incorrectly
removed in this cl: https://codereview.chromium.org/1768123002/. For example
when we have a try-catch-finally block and catch does a return, the return
does not happen immediately. It should execute finally block before it
returns. Return statement should pop the context to the correct level as
expected by finally block.
BUG=594369,v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1796893002
Cr-Commit-Position: refs/heads/master@{#34822}
This part of Scope has existed since V8's initial check in, but from what
I can tell it's not required to implement "with". The only tests that
depend upon it are tests of the debugger and the Scope mirrors, but the
resulting test behavior after removing the bit still seems perfectly
reasonable to me. In fact, with the included fix for scope name collection,
the scope mirror is actually improved with this change.
As a bi-product, this fixes the attached bug, about the contains_with
bit having inconsistent values in some arrow function compilation
scenarios.
BUG=chromium:592353
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1804783002
Cr-Commit-Position: refs/heads/master@{#34802}
We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of.
This is behind --harmony-iterator-close.
R=adamk@chromium.org
BUG=v8:3566
LOG=Y
Review URL: https://codereview.chromium.org/1772793002
Cr-Commit-Position: refs/heads/master@{#34654}
The current implementation does not consider the case when the context of
the control scope and the current context differ. It is possible that they are
different in some cases for example: with statements. This cl fixes this.
BUG=v8:4280,v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1768123002
Cr-Commit-Position: refs/heads/master@{#34609}
This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:
function.prototype = {
method: function() { ... }
}
Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.
This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.
BUG=chromium:593008
LOG=n
Review URL: https://codereview.chromium.org/1772423002
Cr-Commit-Position: refs/heads/master@{#34602}
Similar to fullcodegen, Ignition now also marks a for-in statement as
slow (via the TypeFeedbackVector) when we have to call %ForInFilter,
i.e. we either have no enumeration cache or the receiver map changes
during an iteration of the for-in map.
R=mstarzinger@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1755563002
Cr-Commit-Position: refs/heads/master@{#34391}
We don't need to compare the result of ToObject against null, since
ToObject will always yield a proper receiver (or throw a TypeError).
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1736233002
Cr-Commit-Position: refs/heads/master@{#34318}
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}
