Currently, V8 uses the same counter to collect decoding time for both asm.js and
WASM. This separates the function decoding counter into two separate counters,
and then uses the appropriate counter when decoding a module.
BUG=chromium:704922
R=bbudge@chromium.org,bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2772363002
Cr-Commit-Position: refs/heads/master@{#44197}
A step towards removing isolate from ParseInfo.
Removing isolate from ParseInfo will make it easier to create and
execute parse tasks on background threads.
BUG=v8:6093
Change-Id: I0a3546618d01b9232014da94cf8d0f72427a0d1d
Reviewed-on: https://chromium-review.googlesource.com/458006
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44176}
A step towards removing isolate from ParseInfo.
Removing isolate from ParseInfo will make it easier to create and
execute parse tasks on background threads.
BUG=v8:6093
Change-Id: Ief4eb3c9873026a93338d5556985f31c9abe17e6
Reviewed-on: https://chromium-review.googlesource.com/458005
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44173}
A std::deque interacts badly with zone memory in that it allocates chunks
of memory for the back of the queue and frees memory from the front of the
queue. As such we never reuse zone memory for the queue. Implement a very
simple RecyclingZoneAllocator which keeps a single block of memory from
deallocation that can be reused on allocation.
Also clean up zone-allocator a bit and make it use proper Chromium coding
style.
BUG=chromium:700364
Change-Id: I19330a8a9ec6d75fe18d8168d41f1a12030a6c4d
Reviewed-on: https://chromium-review.googlesource.com/458916
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44154}
A step towards removing isolate from ParseInfo.
Removing isolate from ParseInfo will make it easier to create and
execute parse tasks on background threads.
BUG=v8:6093
Change-Id: I25b23b3bf64502f84c28ce688ad2997c9665a069
Reviewed-on: https://chromium-review.googlesource.com/458003
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#44140}
Besides adding accessors get_origin() and set_origin(), it creates easier test
accessors is_wasm() and is_asm_js().
This allows the possibility of caching boolean flags for is_wasm() and
is_asm_js() without having to change any code except for the files containing
the class definition for WasmModule.
BUG= v8:6152
R=bbudge@chromium.org,mtrofin@chromium.org
Review-Url: https://codereview.chromium.org/2771803005
Cr-Commit-Position: refs/heads/master@{#44130}
Some of the StrictEquality comparisons do not require feedback (for ex: in
try-finally, generators). This cl introduces StrictEqualityNoFeedback bytecode
to be used in such cases. With this change, we no longer have to check if the
type feedback slot is valid in compare bytecode handlers.
This is the first step in reworking the compare bytecode handler to avoid
duplicate checks when collecting feedback and when performing the operation.
BUG=v8:4280
Change-Id: Ia650fd43c0466b8625d3ce98c39ed1073ba42a6b
Reviewed-on: https://chromium-review.googlesource.com/455778
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44020}
Reason for revert:
Temporarily disabled tests on chromium side (https://codereview.chromium.org/2764933002)
Original issue's description:
> Revert of [wasm] Transferrable modules (patchset #13 id:280001 of https://codereview.chromium.org/2748473004/ )
>
> Reason for revert:
> Breaks layout tests:
> https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14312
>
> See https://github.com/v8/v8/wiki/Blink-layout-tests
>
> Original issue's description:
> > [wasm] Transferrable modules
> >
> > We want to restrict structured cloning in Chrome to:
> > - postMessage senders and receivers that are co-located
> > in the same process
> > - indexedDB (just https).
> >
> > For context, on the Chrome side, we will achieve the postMessage part
> > by using a mechanism similar to transferrables: the
> > SerializedScriptValue will have a list of wasm modules, separate from
> > the serialized data stream; and this list won't be copied cross
> > process boundaries. The IDB part is achieved by explicitly opting in
> > reading/writing to the serialization stream. To block attack vectors
> > in IPC cases, the default for deserialization will be to expect data
> > in the wasm transfers list.
> >
> > This change is the V8 side necessary to enabling this design. We
> > introduce TransferrableModule, an opaque datatype exposed to the
> > embedder. Internally, TransferrableModules are just serialized data,
> > because we don't have a better mechanism, at the moment, for
> > de-contextualizing/re-contextualizing wasm modules (wrt Isolate and
> > Context).
> >
> > The chrome defaults will be implemented in the
> > serialization/deserialization delegates on that side. For the v8 side
> > of things, in the absence of a serialization delegate, the V8
> > serializer will write to serialization stream. In the absence of a
> > deserialization delegate, the deserializer won't work. This asymmetry
> > is intentional - it communicates to the embedder the need to make a
> > policy decision, otherwise wasm serialization/deserialization won't
> > work "out of the box".
> >
> > BUG=v8:6079
> >
> > Review-Url: https://codereview.chromium.org/2748473004
> > Cr-Commit-Position: refs/heads/master@{#43955}
> > Committed: 99743ad460
>
> TBR=jbroman@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:6079
>
> Review-Url: https://codereview.chromium.org/2762163002
> Cr-Commit-Position: refs/heads/master@{#43981}
> Committed: e538b70e1aTBR=jbroman@chromium.org,bradnelson@chromium.org,machenbach@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6079
Review-Url: https://codereview.chromium.org/2762273002
Cr-Commit-Position: refs/heads/master@{#43994}
Reason for revert:
Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14312
See https://github.com/v8/v8/wiki/Blink-layout-tests
Original issue's description:
> [wasm] Transferrable modules
>
> We want to restrict structured cloning in Chrome to:
> - postMessage senders and receivers that are co-located
> in the same process
> - indexedDB (just https).
>
> For context, on the Chrome side, we will achieve the postMessage part
> by using a mechanism similar to transferrables: the
> SerializedScriptValue will have a list of wasm modules, separate from
> the serialized data stream; and this list won't be copied cross
> process boundaries. The IDB part is achieved by explicitly opting in
> reading/writing to the serialization stream. To block attack vectors
> in IPC cases, the default for deserialization will be to expect data
> in the wasm transfers list.
>
> This change is the V8 side necessary to enabling this design. We
> introduce TransferrableModule, an opaque datatype exposed to the
> embedder. Internally, TransferrableModules are just serialized data,
> because we don't have a better mechanism, at the moment, for
> de-contextualizing/re-contextualizing wasm modules (wrt Isolate and
> Context).
>
> The chrome defaults will be implemented in the
> serialization/deserialization delegates on that side. For the v8 side
> of things, in the absence of a serialization delegate, the V8
> serializer will write to serialization stream. In the absence of a
> deserialization delegate, the deserializer won't work. This asymmetry
> is intentional - it communicates to the embedder the need to make a
> policy decision, otherwise wasm serialization/deserialization won't
> work "out of the box".
>
> BUG=v8:6079
>
> Review-Url: https://codereview.chromium.org/2748473004
> Cr-Commit-Position: refs/heads/master@{#43955}
> Committed: 99743ad460TBR=jbroman@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6079
Review-Url: https://codereview.chromium.org/2762163002
Cr-Commit-Position: refs/heads/master@{#43981}
We want to restrict structured cloning in Chrome to:
- postMessage senders and receivers that are co-located
in the same process
- indexedDB (just https).
For context, on the Chrome side, we will achieve the postMessage part
by using a mechanism similar to transferrables: the
SerializedScriptValue will have a list of wasm modules, separate from
the serialized data stream; and this list won't be copied cross
process boundaries. The IDB part is achieved by explicitly opting in
reading/writing to the serialization stream. To block attack vectors
in IPC cases, the default for deserialization will be to expect data
in the wasm transfers list.
This change is the V8 side necessary to enabling this design. We
introduce TransferrableModule, an opaque datatype exposed to the
embedder. Internally, TransferrableModules are just serialized data,
because we don't have a better mechanism, at the moment, for
de-contextualizing/re-contextualizing wasm modules (wrt Isolate and
Context).
The chrome defaults will be implemented in the
serialization/deserialization delegates on that side. For the v8 side
of things, in the absence of a serialization delegate, the V8
serializer will write to serialization stream. In the absence of a
deserialization delegate, the deserializer won't work. This asymmetry
is intentional - it communicates to the embedder the need to make a
policy decision, otherwise wasm serialization/deserialization won't
work "out of the box".
BUG=v8:6079
Review-Url: https://codereview.chromium.org/2748473004
Cr-Commit-Position: refs/heads/master@{#43955}
Just ensure that all background and foreground tasks finished, then we
should be in a defined state
BUG=v8:6069
R=rmcilroy@chromium.org
Change-Id: Ie5bd11c61402dccb2c65cb8fe57fd1c0f550e9a7
Reviewed-on: https://chromium-review.googlesource.com/456418
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43926}
Default to the chromium-internal build config (instead of the more
permissive no_chromium_code config).
BUG=v8:5878
Review-Url: https://codereview.chromium.org/2758563002
Cr-Commit-Position: refs/heads/master@{#43909}
Adding a custom lexer for asm.js parsing.
It takes advantage of a number of asm.js properties to simply things:
* Assumes 'use asm' is the only string.
* Does not handle unicode for now (tools don't emit it).
* Combines global + local string table with lexer.
R=marja@chromium.org,vogelheim@chromium.org,kschimpf@chromium.org
BUG=v8:4203
BUG=v8:6090
Review-Url: https://codereview.chromium.org/2751693002
Cr-Commit-Position: refs/heads/master@{#43874}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
For now, has a test that compares the stdout of --type-profile in test/message. We
will remove this test when --type-profile is fully integrated in
the debugger protocol. Adding
the test in test/inspector does not work, because the inspector
test itself consists of JavaScript code that would convolute the
output and be non-deterministic under stress.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43866}
Reason for revert:
Still flaky
Original issue's description:
> Collect type profile for DevTools
>
> Collect type information for JavaScript variables and display it
> in Chrome DevTools.
> Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
>
> When debugging JavaScript, it’s helpful to know the type of
> a variable, parameter, and return values. JavaScript is
> dynamically typed, and for complex
> source code it’s often hard to infer types. With type profiling, we
> can provide type information to JavaScript developers.
>
> This CL is a proof of concept. It collects type profile for
> assignments and simply prints the types to stdout.
>
> The output looks something like this:
>
> #my_var1
> #Object
> #number
> #string
> #number
> #undefined
> #string
> #Object
> #Object
>
>
> We use an extra slot in the feedback vector of assignments to
> carry the list of types for that assignment. The extra slot is
> only added when the flag --type-profile is given.
>
>
> Missing work:
> * Collect data for parameters and return values (currently only assignments).
> * Remove duplicates from the list of collected types and use a common base class.
> * Add line numbers or source position instead of the variable name.
>
>
>
> BUG=v8:5935
>
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#43791}
> Committed: 0332bebde9
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Original-Commit-Position: refs/heads/master@{#43804}
> Committed: 6cf880f4b8
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Commit-Position: refs/heads/master@{#43846}
> Committed: 5c32287390
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Commit-Position: refs/heads/master@{#43849}
> Committed: 18c35e4958TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2745413006
Cr-Commit-Position: refs/heads/master@{#43852}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#43791}
Committed: 0332bebde9
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Original-Commit-Position: refs/heads/master@{#43804}
Committed: 6cf880f4b8
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Commit-Position: refs/heads/master@{#43846}
Committed: 5c32287390
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43849}
Reason for revert:
Flaky under stress. Fix first.
Original issue's description:
> Collect type profile for DevTools
>
> Collect type information for JavaScript variables and display it
> in Chrome DevTools.
> Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
>
> When debugging JavaScript, it’s helpful to know the type of
> a variable, parameter, and return values. JavaScript is
> dynamically typed, and for complex
> source code it’s often hard to infer types. With type profiling, we
> can provide type information to JavaScript developers.
>
> This CL is a proof of concept. It collects type profile for
> assignments and simply prints the types to stdout.
>
> The output looks something like this:
>
> #my_var1
> #Object
> #number
> #string
> #number
> #undefined
> #string
> #Object
> #Object
>
>
> We use an extra slot in the feedback vector of assignments to
> carry the list of types for that assignment. The extra slot is
> only added when the flag --type-profile is given.
>
>
> Missing work:
> * Collect data for parameters and return values (currently only assignments).
> * Remove duplicates from the list of collected types and use a common base class.
> * Add line numbers or source position instead of the variable name.
>
>
>
> BUG=v8:5935
>
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Original-Commit-Position: refs/heads/master@{#43791}
> Committed: 0332bebde9
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Commit-Position: refs/heads/master@{#43804}
> Committed: 6cf880f4b8
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Commit-Position: refs/heads/master@{#43846}
> Committed: 5c32287390TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2747383004
Cr-Commit-Position: refs/heads/master@{#43847}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Original-Commit-Position: refs/heads/master@{#43791}
Committed: 0332bebde9
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Commit-Position: refs/heads/master@{#43804}
Committed: 6cf880f4b8
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43846}
That way, we don't need to create a context-less constructor function.
Instead, we use the constructor_or_backpointer (or null) field, and
rename it to constructor_or_fti_or_backpointer so nobody is confused.
Note that technically, we still have JSFunctions without contexts, as
they're temporarily created in the deoptimizer.
BUG=v8:6084
R=dcheng@chromium.org,bmeurer@chromium.org,verwaest@chromium.org
Change-Id: I084f052533c317f2cbfb9c35e1acf40263c6257b
Reviewed-on: https://chromium-review.googlesource.com/454636
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43834}
Adds a TestTypeof bytecode to deal with comparisons of the form:
typeof(object) === 'string';
Also adds support to Turbofan to perform these comparisons without
inserting checkpoints.
BUG=v8:4280,v8:5267
Change-Id: Ib5cc1c6816dfe70a4120838d8eada2fc0267750f
Reviewed-on: https://chromium-review.googlesource.com/454837
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43832}
This handles non-strict equality comparison operations having number
feedback during the early type-hint lowering (i.e. during graph
construction).
R=jarin@chromium.org
Change-Id: I1db67e78312934bbb20aee775979797420ff2581
Reviewed-on: https://chromium-review.googlesource.com/455796
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43824}
This changes the IR to no longer require single {IfSuccess} projection
nodes unless there is a corresponding {IfException} node that links the
potentially throwing call to an exception handler. This reduces graph
size as well as compilation time when exception handlers aren't present.
The new invariant for potentially throwing nodes is: Nodes that can
potentially throw either have both IfSuccess/IfException projections as
the only control uses and no direct control uses, or no projections at
all and solely direct control uses.
R=jarin@chromium.org
Change-Id: I3d9cd816d74ad5af13e0673da7ec7a98f1ecdc7e
Reviewed-on: https://chromium-review.googlesource.com/449715
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43814}
Reason for revert:
gcc bot is now flaky https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/11863
Original issue's description:
> Collect type profile for DevTools
>
> Collect type information for JavaScript variables and display it
> in Chrome DevTools.
> Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
>
> When debugging JavaScript, it’s helpful to know the type of
> a variable, parameter, and return values. JavaScript is
> dynamically typed, and for complex
> source code it’s often hard to infer types. With type profiling, we
> can provide type information to JavaScript developers.
>
> This CL is a proof of concept. It collects type profile for
> assignments and simply prints the types to stdout.
>
> The output looks something like this:
>
> #my_var1
> #Object
> #number
> #string
> #number
> #undefined
> #string
> #Object
> #Object
>
>
> We use an extra slot in the feedback vector of assignments to
> carry the list of types for that assignment. The extra slot is
> only added when the flag --type-profile is given.
>
>
> Missing work:
> * Collect data for parameters and return values (currently only assignments).
> * Remove duplicates from the list of collected types and use a common base class.
> * Add line numbers or source position instead of the variable name.
>
>
>
> BUG=v8:5935
>
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Commit-Position: refs/heads/master@{#43791}
> Committed: 0332bebde9
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Commit-Position: refs/heads/master@{#43804}
> Committed: 6cf880f4b8TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2754573002
Cr-Commit-Position: refs/heads/master@{#43805}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Commit-Position: refs/heads/master@{#43791}
Committed: 0332bebde9
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43804}
Reason for revert:
gcc bot has problems with this: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/11858
Original issue's description:
> Collect type profile for DevTools
>
> Collect type information for JavaScript variables and display it
> in Chrome DevTools.
> Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
>
> When debugging JavaScript, it’s helpful to know the type of
> a variable, parameter, and return values. JavaScript is
> dynamically typed, and for complex
> source code it’s often hard to infer types. With type profiling, we
> can provide type information to JavaScript developers.
>
> This CL is a proof of concept. It collects type profile for
> assignments and simply prints the types to stdout.
>
> The output looks something like this:
>
> #my_var1
> #Object
> #number
> #string
> #number
> #undefined
> #string
> #Object
> #Object
>
>
> We use an extra slot in the feedback vector of assignments to
> carry the list of types for that assignment. The extra slot is
> only added when the flag --type-profile is given.
>
>
> Missing work:
> * Collect data for parameters and return values (currently only assignments).
> * Remove duplicates from the list of collected types and use a common base class.
> * Add line numbers or source position instead of the variable name.
>
>
>
> BUG=v8:5935
>
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Commit-Position: refs/heads/master@{#43791}
> Committed: 0332bebde9TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org,franzih@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2749673003
Cr-Commit-Position: refs/heads/master@{#43798}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43791}
With this change, on ia32 and x64, a load from memory into a register can be replaced by a memory operand for integer binops if it makes sense.
BUG=
Review-Url: https://codereview.chromium.org/2728533003
Cr-Commit-Position: refs/heads/master@{#43739}
Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
and CallProperty2. Also share the bytecode handler code between between
equivalent CallX and CallPropertyX handlers.
Review-Url: https://codereview.chromium.org/2684993002
Cr-Original-Commit-Position: refs/heads/master@{#43290}
Committed: 00d6f1f80a
Review-Url: https://codereview.chromium.org/2684993002
Cr-Commit-Position: refs/heads/master@{#43700}
Fix two issues in the interpreter entry for 64 bit return values on
32 bit platforms. First, the effect chain was slightly incorrect, second
the order of the returned values was wrong.
Also add a test case for this.
Tested on x64, ia32 and s390.
Plus drive-by fix in Int64Lowering to reuse global constants for
big-endian/little-endian disambiguation.
R=titzer@chromium.org
BUG=v8:5822
Review-Url: https://codereview.chromium.org/2731713002
Cr-Commit-Position: refs/heads/master@{#43654}
So far we only recognize the special
NumberFloor(NumberDivide(lhs, rhs))
subgraph when both lhs and rhs are in the Unsigned32 range, and the
result is a PlainNumber. Extend this pattern matching to also cover
NumberFloor(SpeculativeNumberDivide(lhs, rhs))
and to replace the NumberFloor with NumberToInt32 truncation if the
lhs value is in Signed32 range and the rhs is in Unsigned32 range.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2739573004
Cr-Commit-Position: refs/heads/master@{#43642}
The parser already changes all negative equality comparison operations
to their positive pendants in {ParserBase::ParseBinaryExpression}. No
other source of the Token::NE exists in the system. We can remove all
handling from the compiler and interpreter backends.
R=bmeurer@chromium.org
Change-Id: I58722c08dd8e498f20c65886fce86b8172737b10
Reviewed-on: https://chromium-review.googlesource.com/449716
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43627}
We don't need the JSStrictNotEqual operator in the compiler, because
this is never generated by the BytecodeGraphBuilder, and the code in
the AstGraphBuilder was dead code. Also remove the backing builtin
StrictNotEqual.
R=mstarzinger@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2727003006
Cr-Commit-Position: refs/heads/master@{#43594}
Spinning up a new background task is expensive, and many times an existing
task will finish it's work before a new task starts work on a job, so enable
the existing tasks to do more than one background job.
BUG=v8:5203
Change-Id: Ibbef317c8bb3921c36a096fed88d244716be9c42
Reviewed-on: https://chromium-review.googlesource.com/441706
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43593}
We can compile a !== a and Number.isNaN(a) to ObjectIsNaN. The former is
commonly used to check for NaN, i.e. in case of equals in AngularJS.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2722483003
Cr-Commit-Position: refs/heads/master@{#43572}
This CL fixes unused lambda captures for big endian targets when Clang
is used for build V8.
TEST=
BUG=
Review-Url: https://codereview.chromium.org/2725613002
Cr-Commit-Position: refs/heads/master@{#43511}
Unibrow is currently at Unicode version 7.0.0, which does not
include mongolian vowel separator (\u180E) as white space. In
order to appease test262 at the time however we kept it as a
whitespace.
Test262 has since then been updated. And while this is not an
update of unibrow, we are removing \u180E as white space here.
R=jshin@chromium.org, littledan@chromium.org
BUG=v8:5155
Review-Url: https://codereview.chromium.org/2720953003
Cr-Commit-Position: refs/heads/master@{#43485}
The x64 side is included in https://chromium-review.googlesource.com/c/444226/
BUG=v8:5294
Change-Id: Ie255604c5e38c72e3c2b76e1ca3557a5fde108ee
Reviewed-on: https://chromium-review.googlesource.com/446394
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43481}
This makes it no longer necessary to ensure that V8 and Blink have non-colliding
tags, which makes it easier for them to evolve independently, and also makes
the wire format more suitable for other V8 embedders, who would not
necessarily be surveyed before V8 introduced a new tag that might collide
with theirs.
BUG=chromium:686159
Review-Url: https://codereview.chromium.org/2709023003
Cr-Commit-Position: refs/heads/master@{#43466}
This extends the existing typer for JS-level comparisons to also be
applied on simplified-level number comparisons. Now that nodes having
such operators are introduced early during graph construction, precise
type information has become more important.
R=jarin@chromium.org
TEST=unittests/TyperTest
Change-Id: Ibcfda36cadf72381b3c63138dd8ad2f6b1f7fbba
Reviewed-on: https://chromium-review.googlesource.com/445879
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43447}
Nodes having the {Throw} operator are just used as terminators for
control-flow leaving the function body with an exception completion,
they turn into basic-block terminators within the schedule. Actually
raising an exception is done solely via runtime calls. Hence {Throw}
nodes no longer need any value input.
R=bmeurer@chromium.org
Change-Id: Id6d8e46b12c4b84f4e7a8ac96623c8efb1f27b26
Reviewed-on: https://chromium-review.googlesource.com/446501
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43445}
Marking it as callable makes typeof return 'function' instead of
'object' when invoked on a remote context or object.
BUG=chromium:527190
Review-Url: https://codereview.chromium.org/2715593002
Cr-Commit-Position: refs/heads/master@{#43416}
Enable using BaseWithIndexAndDisplacement addressing mode for an address
used by multiple load/stores. It can reduce one instruction to calculate
the address and one register to store the address.
BUG=
Review-Url: https://codereview.chromium.org/2620293004
Cr-Commit-Position: refs/heads/master@{#43402}
This reverts commit 087e95ba63.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [Compiler] Use IdentityMap to store jobs in CompilerDispatcher.
>
> Stores jobs in an IdentityMap keyed by their SharedFunctionInfo to enable
> fast checking of whether a job is enqueued.
>
> BUG=v8:5203
>
> Change-Id: I6c37972093515a27077f79594cad27e32e1a4e7c
> Reviewed-on: https://chromium-review.googlesource.com/444768
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43370}
TBR=rmcilroy@chromium.org,jochen@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Change-Id: I5d1101bdae6939378dad595b26698fe2aaaad35e
Reviewed-on: https://chromium-review.googlesource.com/446357
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43372}
Stores jobs in an IdentityMap keyed by their SharedFunctionInfo to enable
fast checking of whether a job is enqueued.
BUG=v8:5203
Change-Id: I6c37972093515a27077f79594cad27e32e1a4e7c
Reviewed-on: https://chromium-review.googlesource.com/444768
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43370}
v8 allows the embedder to specify a global template to use when
creating a new context. However, v8 does not use the supplied
template directly when creating the global proxy: it creates a
unique template for each global proxy. However, this is problematic
for remote contexts: functions cannot use strict receiver checks
with the remote context, as the global template will never match
the global proxy.
To fix this, remote contexts now also include a remote global
object in the prototype chain that is instantiated with the global
template. This mirrors the way the global proxy is configured for a
full v8 context, and allows strict receiver checks to work.
BUG=527190
Review-Url: https://codereview.chromium.org/2677653002
Cr-Commit-Position: refs/heads/master@{#43361}
Reason for revert:
Due to arm64 failures
Original issue's description:
> [interpreter] Create custom call opcodes for specific argument counts
>
> Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
> and CallProperty2. Also share the bytecode handler code between between
> equivalent CallX and CallPropertyX handlers.
>
> Review-Url: https://codereview.chromium.org/2684993002
> Cr-Commit-Position: refs/heads/master@{#43290}
> Committed: 00d6f1f80aTBR=rmcilroy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2709533002
Cr-Commit-Position: refs/heads/master@{#43308}
Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
and CallProperty2. Also share the bytecode handler code between between
equivalent CallX and CallPropertyX handlers.
Review-Url: https://codereview.chromium.org/2684993002
Cr-Commit-Position: refs/heads/master@{#43290}
... which is used for initializing properties with non compile time values.
Currently we use StoreOwnIC only for storing properties that already exist
in the boilerplate therefore we can reuse StoreIC dispatcher.
The proper StoreOwnIC dispatcher will be implemented in a separate CL.
BUG=v8:5495, v8:4414
Change-Id: I9c33fdb8499ec5be2c7fce1ecb6ce7aa285e5844
Reviewed-on: https://chromium-review.googlesource.com/443588
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43285}
Add `ValueSerializer::SetTreatArrayBufferViewsAsHostObjects()` which
instructs the `ValueSerializer` to treat ArrayBufferView objects as
host objects.
BUG=v8:5926
Review-Url: https://codereview.chromium.org/2696133007
Cr-Commit-Position: refs/heads/master@{#43281}
https://crrev.com/2500363002 updated FunctionTemplate::HasInstance to
follow the hidden prototype chain of a global proxy to the global
object. However, remote contexts don't have a global object to check;
instead, teach the instance check knows about the conventions of
global proxy setup and have it also check the constructor's prototype.
Similarly, also teach Object::FindInstanceInPrototypeChain about the
unusual conventions for remote contexts.
BUG=527190
Review-Url: https://codereview.chromium.org/2698683003
Cr-Commit-Position: refs/heads/master@{#43263}
Before this patch, the registers needed for bytecode dispatch in interpreter
handlers were inconsistently stored in the interpreter frame and/or kept in
values that remained live across calls.
After this patch, these registers are explicitly reloaded after calls, making it
possible to elide the spills of those registers before the call in many cases.
Some highlights from the CL:
* Added methods to the CSA and InterpreterAssembler to efficiently store and
load Smis values and Smi interpreter registers on x64 without explicit
tagging/untagging.
* Created Variables for all of the interpreter-internal values that need to be
reloaded before bytecode dispatch at the end of an interpreter handler.
* The bytecode offset can be written out early in a handler by marking it
has having a call along it's critical path. By moving this early in a
handler, it becomes possible to use memory operands for pushes used to
marshall parameters when making calls.
Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577
Reviewed-on: https://chromium-review.googlesource.com/442566
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43260}
The serializer won't ever write a more complex object. Not validating this
allows other things to be used as keys, and converted to string when the
property set actually occurs. It turns out this gives an opportunity to trigger
OOM by giving an object a key which is a very large sparse array (whose string
representation is very large).
This case is now rejected by the deserializer.
BUG=chromium:686511
Review-Url: https://codereview.chromium.org/2697023002
Cr-Commit-Position: refs/heads/master@{#43249}
This handles arithmetic addition operations during the early type-hint
lowering (i.e. during graph construction). The string addition case is
still handled by {JSTypedLowering} as it needs static type information.
R=bmeurer@chromium.org
Change-Id: I9df47dfc5bf7613c51f6d803ab43d5d3f6c21be8
Reviewed-on: https://chromium-review.googlesource.com/443185
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43235}
This handles all arithmetic binary operations except addition during the
early type-hint lowering (i.e. during graph construction). We still use
static type information to potentially further reduce the speculative
operations down to pure operations during the typed lowering phase.
R=bmeurer@chromium.org
Change-Id: I8b93fd7c46ec8e5b81234a49624d503520c3d082
Reviewed-on: https://chromium-review.googlesource.com/443105
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43218}
This allows part of typed lowering that is solely based on type-hints to
run as part of the graph construction. The lowering in question does not
inspect types and hence doesn't require the typer to have run before. We
insert the speculative simplied-level operations in favor of the generic
JavaScript-level variants.
R=bmeurer@chromium.org
Change-Id: I5f0549fc1e4ff607622ee9059e6232a32f77db2e
Reviewed-on: https://chromium-review.googlesource.com/442584
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43208}
If a job was already enqueued, EnqueueAndStep would still step the job one
more step. However, since it didn't take the job out of the
pending_background_jobs pool, the job could get picked up by a background
thread which would try to step it, but it the job is now at a step which
can't be run on the background.
BUG=v8:5203,chromium:685515
Change-Id: I2cee2a33625ba455aca49a8037601be9ff8bb73f
Reviewed-on: https://chromium-review.googlesource.com/441084
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43121}
Don't block on inner function compilation before competing outer function
compilation. Instead wait for the compilation to complete when the function
is called.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2686673002
Cr-Commit-Position: refs/heads/master@{#43116}
Removes handles from bytecode generation, instead storing
un-internalized AstValues (and other, similar values such as Scopes and
AstRawStrings) in the constant array builder.
This will allow us in the future to generate the bytecode before
internalizing the AST.
BUG=v8:5832
Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da
Reviewed-on: https://chromium-review.googlesource.com/439326
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43115}
When running main-thread compiler-dispatcher jobs, ensure that we enter the
correct Context. Also adds a test for compiling an extension in the compiler
dispatcher to ensure that idle tasks enter the correct context before
finalizing the compilation.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2679193004
Cr-Commit-Position: refs/heads/master@{#43111}
This introduces new maps to track whether we have created at most one
closure. If we have created just one closure, Turbofan will
specialize the code to its context.
Review-Url: https://codereview.chromium.org/2680313002
Cr-Commit-Position: refs/heads/master@{#43108}
In order to compile eager inner functions on a background thread we need to
keep the handles created during parsing and scope analysis alive until the
background compilation is complete. In order to do that, we allocate the
handles in a deferred handle scope and keep the deferred handles alive with
a shared_ptr in the ParseInfo and CompileInfo respectively.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2650883002
Cr-Commit-Position: refs/heads/master@{#43107}
Reason for revert:
Issue on arm64:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim/builds/5752
Original issue's description:
> [Compiler] Enable handles created during parsing and scope analysis to be deferred.
>
> In order to compile eager inner functions on a background thread we need to
> keep the handles created during parsing and scope analysis alive until the
> background compilation is complete. In order to do that, we allocate the
> handles in a deferred handle scope and keep the deferred handles alive with
> a shared_ptr in the ParseInfo and CompileInfo respectively.
>
> BUG=v8:5203
>
> Review-Url: https://codereview.chromium.org/2650883002
> Cr-Commit-Position: refs/heads/master@{#43091}
> Committed: 9346cd9b4cTBR=marja@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2687973003
Cr-Commit-Position: refs/heads/master@{#43093}
In order to compile eager inner functions on a background thread we need to
keep the handles created during parsing and scope analysis alive until the
background compilation is complete. In order to do that, we allocate the
handles in a deferred handle scope and keep the deferred handles alive with
a shared_ptr in the ParseInfo and CompileInfo respectively.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2650883002
Cr-Commit-Position: refs/heads/master@{#43091}
In order to allow parallel compilation of eager inner functions, we need to
seperate the zone used for parsing (which will be shared between all the
parallel compile jobs) and the zone used for compilation. This CL changes
CompilationInfo to require a zone (which can be different from the zone in
ParseInfo). We then seal the ParseInfo zone after parsing and analysis is done
to prevent any further allocation in that zone, so that it can be shared
(read-only) with the parallel compile jobs.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2645403002
Cr-Commit-Position: refs/heads/master@{#43089}
arguments.h is one of the headers including objects-inl.h. Files needing
objects-inl.h used to innocently pull in debug.h, so that needs to be fixed now
too.
BUG=v8:5294
R=mstarzinger@chromium.org
Change-Id: I8ce671c533ed757103ef9a3b0bf0a0509230fdd8
Reviewed-on: https://chromium-review.googlesource.com/439287
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43054}
Since the empty string is canonical HeapObject now, we can use
this fact to optimize
- strict equality comparisons with the empty string to a
simple ReferenceEqual operation, and
- optimize ToBoolean to avoid instance type checks completely.
Drive-by-fix: Allow InternalizedString for Type::HeapConstant
in the type system. This is safe, since InternalizedStrings
can be compared to other heap constants by reference (except
for non-InternalizedStrings, which are excluded from the
HeapConstant type).
BUG=v8:5267
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2681273002
Cr-Commit-Position: refs/heads/master@{#43050}
Without doing this, a JSMessageObject can be kept alive by the isolate, which
in turn keeps the context alive, until the message is cleared.
BUG=v8:5941
Review-Url: https://codereview.chromium.org/2675203005
Cr-Commit-Position: refs/heads/master@{#43043}
Arm64 compiles "x +_64 (y >> shift)" into a single instruction if
"shift" is a constant. The code generator expects that "shift" is a
32 bit constant. however, TurboFan can also pass in a 64 bit constant,
which caused a crash in the code generator.
With this CL we cast the constant of TurboFan to an int in the
instruction selector and thereby satisfy the assumption of the code
generator. This should be correct since the code generator anyways cast
the "shift" to an int5 or int6 eventually.
R=v8-arm-ports@googlegroups.com
BUG=v8:5923
Review-Url: https://codereview.chromium.org/2669203005
Cr-Commit-Position: refs/heads/master@{#43036}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of Reland: [Parse] ParseInfo owns the parsing Zone. (patchset #7 id:140001 of https://codereview.chromium.org/2632123006/ )
>
> Reason for revert:
> Speculative revert because of revert needed for https://codereview.chromium.org/2632123006
>
> Original issue's description:
> > Reland: [Parse] ParseInfo owns the parsing Zone.
> >
> > Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> > in preperation for enabling background compilation jobs for inner functions
> > share the AST in the outer-function's parse zone memory (read-only), with the
> > and zone being released when all compilation jobs have completed.
> >
> > BUG=v8:5203,v8:5215
> >
> > Review-Url: https://codereview.chromium.org/2632123006
> > Cr-Original-Commit-Position: refs/heads/master@{#42993}
> > Committed: 14fb337200
> > Review-Url: https://codereview.chromium.org/2632123006
> > Cr-Commit-Position: refs/heads/master@{#42996}
> > Committed: 9e7d5a6065
>
> TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2683733002
> Cr-Commit-Position: refs/heads/master@{#43008}
> Committed: 9fe08ec067TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2679303003
Cr-Commit-Position: refs/heads/master@{#43015}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ )
>
> Reason for revert:
> needed for properly reverting f3ae5ccf57
>
> Original issue's description:
> > Thread maybe-assigned through the bytecodes.
> >
> > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> > bytecodes, which are emitted when reading from never-assigned context slot.
> >
> > There is a subtlety here: the slot are not immutable, the meaning is
> > actually undefined-or-hole-or-immutable.
> >
> > Review-Url: https://codereview.chromium.org/2655733003
> > Cr-Commit-Position: refs/heads/master@{#43000}
> > Committed: 17c2dd3886
>
> TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@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/2680923003
> Cr-Commit-Position: refs/heads/master@{#43011}
> Committed: ece4e54a31TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@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/2679953003
Cr-Commit-Position: refs/heads/master@{#43012}
Reason for revert:
needed for properly reverting f3ae5ccf57
Original issue's description:
> Thread maybe-assigned through the bytecodes.
>
> This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> bytecodes, which are emitted when reading from never-assigned context slot.
>
> There is a subtlety here: the slot are not immutable, the meaning is
> actually undefined-or-hole-or-immutable.
>
> Review-Url: https://codereview.chromium.org/2655733003
> Cr-Commit-Position: refs/heads/master@{#43000}
> Committed: 17c2dd3886TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@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/2680923003
Cr-Commit-Position: refs/heads/master@{#43011}
Reason for revert:
Speculative revert because of revert needed for https://codereview.chromium.org/2632123006
Original issue's description:
> Reland: [Parse] ParseInfo owns the parsing Zone.
>
> Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> in preperation for enabling background compilation jobs for inner functions
> share the AST in the outer-function's parse zone memory (read-only), with the
> and zone being released when all compilation jobs have completed.
>
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Original-Commit-Position: refs/heads/master@{#42993}
> Committed: 14fb337200
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Commit-Position: refs/heads/master@{#42996}
> Committed: 9e7d5a6065TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2683733002
Cr-Commit-Position: refs/heads/master@{#43008}
This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
bytecodes, which are emitted when reading from never-assigned context slot.
There is a subtlety here: the slot are not immutable, the meaning is
actually undefined-or-hole-or-immutable.
Review-Url: https://codereview.chromium.org/2655733003
Cr-Commit-Position: refs/heads/master@{#43000}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
in preperation for enabling background compilation jobs for inner functions
share the AST in the outer-function's parse zone memory (read-only), with the
and zone being released when all compilation jobs have completed.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2632123006
Cr-Original-Commit-Position: refs/heads/master@{#42993}
Committed: 14fb337200
Review-Url: https://codereview.chromium.org/2632123006
Cr-Commit-Position: refs/heads/master@{#42996}
Reason for revert:
doesn't compile on ToT
Original issue's description:
> Reland: [Parse] ParseInfo owns the parsing Zone.
>
> Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> in preperation for enabling background compilation jobs for inner functions
> share the AST in the outer-function's parse zone memory (read-only), with the
> and zone being released when all compilation jobs have completed.
>
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Commit-Position: refs/heads/master@{#42993}
> Committed: 14fb337200TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2685543003
Cr-Commit-Position: refs/heads/master@{#42994}
Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
in preperation for enabling background compilation jobs for inner functions
share the AST in the outer-function's parse zone memory (read-only), with the
and zone being released when all compilation jobs have completed.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2632123006
Cr-Commit-Position: refs/heads/master@{#42993}
This correctly marks the {JSCreate} operator as potentially throwing,
since it might trigger a property access of the 'prototype' property
during instantiation. This is observable, can throw (not kNoThrow),
might have side-effects (not kNoWrite), or even trigger a lazy deopt
event (not kNoDeopt). The inlining logic has been adapted to wire up
control projections accordingly.
Note that this does not yet take care of the "after" frame-state which
is associated with the {JSCreate} node introduced by the inliner. We
still might re-evaluate the property access upon lazy deoptimization.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-5638
BUG=v8:5638
Review-Url: https://codereview.chromium.org/2671203003
Cr-Commit-Position: refs/heads/master@{#42981}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
First discovery by the names section fuzzer I think. During the decoding
of the names of locals only ok() of the outer decoder was checked, not
the ok() of the actual names section decoder.
R=tizer@chromium.org
BUG=chromium:684855
Review-Url: https://codereview.chromium.org/2648383007
Cr-Commit-Position: refs/heads/master@{#42880}
This avoids the need to pull in the UTF-8 encoding code from the public API,
and allows it to take advantage of any supported way that i::String can be
encoded (one- or two-byte).
Backward compatibility is maintained, but this is the behavior beginning
with this version.
BUG=chromium:686159
Review-Url: https://codereview.chromium.org/2665653004
Cr-Commit-Position: refs/heads/master@{#42872}
The int64-lowering only lowered store instructions with a word64 store
representation. For all other stores the default lowering applied. The
default lowering replaces all input nodes with both their replacement
nodes, which can change the number of input nodes of the lowered node.
In WebAssembly there exist stores which take an I64 input and store it
with a different representation, e.g. I32. In TurboFan this translates
to a store node with word32 store representation and a word64 value
input. The default lowering replaces the word64 value input to become
two word32 value inputs, which makes the number of inputs of the store
node invalid. This CL discards the high word replacement of the value
input so that the number of input nodes of a store node does not change
in the default lowering.
R=titzer@chromium.orgCC=rossberg@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2668023004
Cr-Commit-Position: refs/heads/master@{#42860}
Rename to Construct and ConstructWithSpread, to match the names of
the JSOperators used.
Unfortunately, I can't find a way for auto-formatting to stay happy unless we
change the indentation for the whole BYTECODE_LIST macro.
Review-Url: https://codereview.chromium.org/2663963003
Cr-Commit-Position: refs/heads/master@{#42840}
Dealing with this case requires a wire format change. It is possible that an
element can be absent even in an array where the dense format was chosen
(because the array initially had no holes), if the elements are modified while
they are being serialized. In this case, a new tag for the "hole" is emitted.
The logic to treat undefined in dense arrays as an absent property is restricted
to versions of the wire format that this tag did not exist.
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2660093002
Cr-Original-Commit-Position: refs/heads/master@{#42784}
Committed: dc85f4c833
Review-Url: https://codereview.chromium.org/2660093002
Cr-Commit-Position: refs/heads/master@{#42800}
Reason for revert:
Seems to break layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/13146https://github.com/v8/v8/wiki/Blink-layout-tests
Original issue's description:
> ValueSerializer: Distinguish between 'undefined' and an absent property.
>
> Dealing with this case requires a wire format change. It is possible that an
> element can be absent even in an array where the dense format was chosen
> (because the array initially had no holes), if the elements are modified while
> they are being serialized. In this case, a new tag for the "hole" is emitted.
>
> The logic to treat undefined in dense arrays as an absent property is restricted
> to versions of the wire format that this tag did not exist.
>
> BUG=chromium:686159,chromium:665820
>
> Review-Url: https://codereview.chromium.org/2660093002
> Cr-Commit-Position: refs/heads/master@{#42784}
> Committed: dc85f4c833TBR=jkummerow@chromium.org,jbroman@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2667553003
Cr-Commit-Position: refs/heads/master@{#42788}
Dealing with this case requires a wire format change. It is possible that an
element can be absent even in an array where the dense format was chosen
(because the array initially had no holes), if the elements are modified while
they are being serialized. In this case, a new tag for the "hole" is emitted.
The logic to treat undefined in dense arrays as an absent property is restricted
to versions of the wire format that this tag did not exist.
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2660093002
Cr-Commit-Position: refs/heads/master@{#42784}
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
memcpy is faster than UTF-8 encoding/decoding. This yields 10-20% wins on
serializing and deserializing long ASCII strings, according to
blink_perf.bindings -- and these are already in a fast path where the entire
string is known to be ASCII (but this has to be checked). The win may be
larger for strings in Latin-1 but not ASCII (though I suspect this is an
uncommon case).
A change is also made to make ValueSerializerTest.EncodeTwoByteStringUsesPadding
survive wire format version number changes.
This is the first of a series of wire format changes from the previous Blink
format. The deserializer continues to be able to read the old format, but
Chromium M56 will no longer be able to read the messages written by this, in M58.
BUG=chromium:686159
Review-Url: https://codereview.chromium.org/2658793004
Cr-Commit-Position: refs/heads/master@{#42753}
Enable enqueueing of eager inner function compilation onto the compiler
dispatcher. This enables these tasks to be performed in parallel to
compilation of the outer functio (only for Ignition functions).
We currently synchronize to ensure all inner function compilations
are complete before executing the outer function - future work will
allow outer function execution to happenin parallel to inner function
compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2611313002
Cr-Commit-Position: refs/heads/master@{#42667}
Since JumpLoop is always backwards, and other jumps are always forwards,
we can store the jump offset as an always positive integer and decide on
the jump direction based on the bytecode. This will save a small amount
of space for large-ish for loops (>128 bytecodes).
Review-Url: https://codereview.chromium.org/2641443002
Cr-Commit-Position: refs/heads/master@{#42638}
We can share almost all of the architecture-specific builtin code with super-call-with-spread.
Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2649143002
Cr-Commit-Position: refs/heads/master@{#42632}
In this particular case, we just did a (lhs)op(rhs), ignoring the case
that lhs and rhs might have different signedness.
This CL changes that to use the proper Cmp##op##Impl implementation,
which does two comparisions for signed-vs-unsigned checks, avoiding
compiler errors.
R=ishell@chromium.org
Review-Url: https://codereview.chromium.org/2642383002
Cr-Commit-Position: refs/heads/master@{#42566}
This patch adds destructor to ValueSerializerTest test fixture class
which reset unhandled scheduled exceptions thrown from the current test.
In some cases unhandled scheduled exceptions from current test (eg.
from one test from ValueSerializerTestWithWasm test case) produce that
Context::New(isolate()) from next test's constructor returns NULL.
This error is easily reproduced when unittest file (compiled for ARM or
MIPS simulator) is directly executed (not by tools/run_tests.py script),
so all tests are executed together. When the script is used, each test
from ValueSerializerTestWithWasm test case is separately executed and
unhandled exception from one test doesn't efect to another test from
the same test case.
BUG=
Review-Url: https://codereview.chromium.org/2644083002
Cr-Commit-Position: refs/heads/master@{#42547}
Clang just got more strict about unused lambda captures,
and that requires us to clean all places with this issue
across all the Chromium code base. This CL fixes all such
cases in V8.
BUG=chromium:681136
Review-Url: https://codereview.chromium.org/2646553002
Cr-Commit-Position: refs/heads/master@{#42523}
Reason for revert:
Causes a few bugs caught by clusterfuzz.
Original issue's description:
> [Ignition/turbo] Add a CallWithSpread bytecode.
>
> Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser.
>
> BUG=v8:5511
>
> Review-Url: https://codereview.chromium.org/2629363002
> Cr-Commit-Position: refs/heads/master@{#42455}
> Committed: 4bae43471dTBR=bmeurer@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2642843002
Cr-Commit-Position: refs/heads/master@{#42470}
Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2629363002
Cr-Commit-Position: refs/heads/master@{#42455}
The existing implementation assumes that return nodes have exactly one
real value input. This assumption does not hold for WebAssembly. To
avoid incorrect behavior, this CL turns of the reduction of returns
with a value input count != 1.
R=titzer@chromium.org, mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2638053002
Cr-Commit-Position: refs/heads/master@{#42425}
Enable enqueueing of eager inner function compilation onto the compiler
dispatcher. This enables these tasks to be performed in parallel to
compilation of the outer functio (only for Ignition functions).
We currently synchronize to ensure all inner function compilations
are complete before executing the outer function - future work will
allow outer function execution to happenin parallel to inner function
compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2611313002
Cr-Commit-Position: refs/heads/master@{#42413}
KillFields of an object should remove its cache from all the fields.
Currently, the cache in the front field is kept which is not expected.
This patch fixes it.
Review-Url: https://codereview.chromium.org/2618273002
Cr-Commit-Position: refs/heads/master@{#42388}
Moves constant element/property array building to be deferred for
igition and on-demand for the other compilers, and splits off the
object/array literal depth/flag initialisation from the array building.
BUG=v8:5832
Review-Url: https://codereview.chromium.org/2625873009
Cr-Commit-Position: refs/heads/master@{#42362}
This puts lowering of {JSCreateClosure} operations behind a flag. For
now the benefit of inline allocating such closures is negligible, it
does increase code size, and breaks in combination with inlining based
on {SharedFunctionInfo}.
R=jarin@chromium.org
BUG=v8:2206
Review-Url: https://codereview.chromium.org/2636493002
Cr-Commit-Position: refs/heads/master@{#42331}
Reason for revert:
OK, the failure really does seem to be due to this patch: It triggers Clang to crash
FAILED: obj/test/unittests/unittests/function-body-decoder-unittest.obj
E:\b\build\slave\cache\cipd\goma/gomacc.exe ../../third_party/llvm-build/Release+Asserts/bin/clang-cl.exe /nologo /showIncludes /FC @obj/test/unittests/unittests/function-body-decoder-unittest.obj.rsp /c ../../test/unittests/wasm/function-body-decoder-unittest.cc /Foobj/test/unittests/unittests/function-body-decoder-unittest.obj /Fd"obj/test/unittests/unittests_cc.pdb"
Assertion failed: (NumGaps == 0 || Bias < MaxDefRange) && "large ranges should not have gaps", file E:\b\build\slave\win_upload_clang\build\src\third_party\llvm\lib\MC\MCCodeView.cpp, line 531
Wrote crash dump file "C:\Users\CHROME~2\AppData\Local\Temp\goma_temp.5068\clang-cl.exe-563144.dmp"
Let's leave it out for now.
Original issue's description:
> Reland of [wasm] Enforce that function bodies end with the \"end\" opcode. (patchset #1 id:1 of https://codereview.chromium.org/2628883006/ )
>
> Reason for revert:
> Try a reland; this might not have been the source of tree-closing.
>
> Original issue's description:
> > Revert of [wasm] Enforce that function bodies end with the \"end\" opcode. (patchset #3 id:40001 of https://codereview.chromium.org/2630553002/ )
> >
> > Reason for revert:
> > Caused tree to close by failing compilation:
> >
> > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/4451
> >
> > Original issue's description:
> > > [wasm] Enforce that function bodies end with the \"end\" opcode.
> > >
> > > R=rossberg@chromium.org
> > > BUG=chromium:575167
> > >
> > > Review-Url: https://codereview.chromium.org/2630553002
> > > Cr-Commit-Position: refs/heads/master@{#42286}
> > > Committed: fcc6e85ec6
> >
> > TBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,titzer@chromium.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=chromium:575167
> >
> > Review-Url: https://codereview.chromium.org/2628883006
> > Cr-Commit-Position: refs/heads/master@{#42287}
> > Committed: 1d32a3989b
>
> TBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,titzer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:575167
>
> Review-Url: https://codereview.chromium.org/2628203003
> Cr-Commit-Position: refs/heads/master@{#42296}
> Committed: e539bd8e0eTBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:575167
Review-Url: https://codereview.chromium.org/2633583002
Cr-Commit-Position: refs/heads/master@{#42298}
Reason for revert:
Try a reland; this might not have been the source of tree-closing.
Original issue's description:
> Revert of [wasm] Enforce that function bodies end with the \"end\" opcode. (patchset #3 id:40001 of https://codereview.chromium.org/2630553002/ )
>
> Reason for revert:
> Caused tree to close by failing compilation:
>
> https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/4451
>
> Original issue's description:
> > [wasm] Enforce that function bodies end with the \"end\" opcode.
> >
> > R=rossberg@chromium.org
> > BUG=chromium:575167
> >
> > Review-Url: https://codereview.chromium.org/2630553002
> > Cr-Commit-Position: refs/heads/master@{#42286}
> > Committed: fcc6e85ec6
>
> TBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,titzer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:575167
>
> Review-Url: https://codereview.chromium.org/2628883006
> Cr-Commit-Position: refs/heads/master@{#42287}
> Committed: 1d32a3989bTBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:575167
Review-Url: https://codereview.chromium.org/2628203003
Cr-Commit-Position: refs/heads/master@{#42296}
This CL modifies the ast-numbering phase to collect function literals which
should be compiled eagerly. This is then used to eagerly compile the inner
functions before compiling the outer function. This will be used to queue
compilation jobs on the CompilerDispatcher in a later CL.
This CL moves the compilation of eager inner functions out of the
GetSharedFunctionInfo function and instead compiles them explicitly. This
simplifies GetSharedFunctionInfo and also means there is no need to pass a
LazyCompilationMode to the function, so this concept has been removed.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2618553004
Cr-Commit-Position: refs/heads/master@{#42221}
This changes the NewClosure interface descriptor, but ignores
the additional vector/slot arguments for now. The feedback vector
gets larger, as it holds a space for each literal array. A follow-on
CL will constructively use this space.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2614373002
Cr-Commit-Position: refs/heads/master@{#42146}
GCC4.8.5 on s390 emits warning "array subscript is above array bounds"
for line "code[pos + 1] = kLocalVoid;". The warning seems to be
correct because code[sizeof(code)] should be out of bounds.
I'm suggesting to run the loop till "sizeof(code) - 1" which GCC(4.8.5)
agrees with. Although this means the last byte is missed, but it should
be safe to do since the last few bytes are "0xb" (kExprEnd) and the
offending statement is only run when byte=kExprBlock.
R=titzer@chromium.org, mstarzinger@chromium.org, bradnelson@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2619063002
Cr-Commit-Position: refs/heads/master@{#42145}
Downside: this adds all kinds of weird includes in the .cc files.
(See design doc linked in the bug.)
BUG=v8:5402
Review-Url: https://codereview.chromium.org/2622503002
Cr-Commit-Position: refs/heads/master@{#42140}
Separated:
- decoding of locals
- loop assignment analysis
- determination of opcode length
as statics that work on a Decoder. Neither need the context of a
Module, and were used in scenarios where one wasn't available either.
Changed BodyLocalDecls to match the usecases for the type. In all but
one (a printer), we want the list (in order of declaration, with
repetitions) of types of locals.
Removed a now-unnecessary constructor for the WasmFullDecoder.
BUG=
Review-Url: https://codereview.chromium.org/2610813009
Cr-Commit-Position: refs/heads/master@{#42115}
Add a more efficient encoding for state values that have a large number of
optimized-out inputs.
Review-Url: https://codereview.chromium.org/2509623002
Cr-Commit-Position: refs/heads/master@{#42088}
Add a feedback vector slot for computed property names in object
and class literals. Introduce new slot kind for storing
computed property names.
Change StaDataPropertyInLiteral to use the accumulator (again), so
we don't exceed Bytecodes::kMaxOperands.
We assume that most computed property names are
symbols. Therefore we should see performance
improvements, even if we deal with monomorphic ICs only.
This CL only collects feedback but does not use
it in Reduce() yet.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2587393006
Cr-Commit-Position: refs/heads/master@{#42082}
This CL simplifies the relation between the wasm graph builder, the
wasm decoder, and the wasm module they work on.
BUG=
Review-Url: https://codereview.chromium.org/2612643002
Cr-Commit-Position: refs/heads/master@{#42056}
Hook up TurboFan with the existing field type tracking machinery to
eliminate redundant map checks on the results of LoadField operators.
The store side is already implemented in TurboFan for quite some time,
this just adds the load part.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2604393002
Cr-Commit-Position: refs/heads/master@{#42015}
We need to report cached wrappers within v8 to the embedder after each atomic
phase of v8 marking because the embedder can invalidate the wrappers in-between
v8 marking steps.
E.g., in Chrome, a conservative GC might need to wipe dead wrappables from
the wrapper tracing marking deque.
BUG=chromium:676700, chromium:468240
Review-Url: https://codereview.chromium.org/2610563002
Cr-Commit-Position: refs/heads/master@{#42011}
... and add explicit CallPrologue/CallEpilogue callbacks to CodeAssemblerState instead.
This will allow IntepreterAssembler to use any other helper assembler.
TBR=rmcilroy@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2600183004
Cr-Commit-Position: refs/heads/master@{#41973}
Reland 0cf5623220
The original patch got reverted because testing RegisterConfiguration was
overwritten by turbofan RegisterConfiguration. This caused some test cases not being
properly tested. The new patch uses correct RegisterConfiguration.
Original commit message:
Test InstructionSequenceTest has been initialized with a testing RegisterConfiguration
instance defined in instruction-sequence-unittest.h, whereas class ExplicitOperand which
is being tested used RegisterConfiguration from instruction.cc. In case these two
instances are different, the tests would fail. The issue is fixed by using the same
instance of RegisterConfiguration both for test code and code under test.
Additionally, the tests in register-allocator-unittest.cc use hardcoded values
for register and begin failing is the hardcoded register is not available for
allocation. Fix by forcing the use of allocatable registers only.
TEST=unittests.MoveOptimizerTest.RemovesRedundantExplicit,unittests.RegisterAllocatorTest.SpillPhi
BUG=
Review-Url: https://codereview.chromium.org/2595293002
Cr-Commit-Position: refs/heads/master@{#41938}
Reason for revert:
Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/
Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2504153002
> Cr-Commit-Position: refs/heads/master@{#41893}
> Committed: 93df094081TBR=bmeurer@chromium.org,mlippautz@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2597163002
Cr-Commit-Position: refs/heads/master@{#41917}
Reason for revert:
speculative revert: https://codereview.chromium.org/2596013002/
Original issue's description:
> [regexp] Remove IsRegExp intrinsic
>
> The two remaining uses of this intrinsic in debug.js and mirrors.js now
> simply rely on the runtime function.
>
> BUG=v8:5339
>
> Review-Url: https://codereview.chromium.org/2591923003
> Cr-Commit-Position: refs/heads/master@{#41892}
> Committed: c9cb94a06fTBR=bmeurer@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2592383002
Cr-Commit-Position: refs/heads/master@{#41915}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2504153002
Cr-Commit-Position: refs/heads/master@{#41893}
The two remaining uses of this intrinsic in debug.js and mirrors.js now
simply rely on the runtime function.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2591923003
Cr-Commit-Position: refs/heads/master@{#41892}
This is more renaming work to comply with the naming in the public
design repository. E.g. types are called "value types" and we no longer
refer to ASTs.
R=clemensh@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2594993002
Cr-Commit-Position: refs/heads/master@{#41891}
eval() may introduce a scope which needs to be represented as a context at
runtime, e.g.,
eval('var x; let y; ()=>y')
introduces a variable y which needs to have a context allocated for it. However,
when traversing upwards to find the declaration context for a variable which leaks,
as the declaration of x does above, this context has to be understood to not be
a declaration context in sloppy mode.
This patch makes that distinction by introducing a different map for eval-introduced
contexts. A dynamic search for the appropriate context will continue past an eval
context to find the appropriate context. Marking contexts as eval contexts rather
than function contexts required updates in each compiler backend.
BUG=v8:5295, chromium:648719
Review-Url: https://codereview.chromium.org/2435023002
Cr-Commit-Position: refs/heads/master@{#41869}
We have the BytecodeIterator with next() and has_next() methods, and
pc_offset() and current() accessors.
This CL adds an interface to iterate over the opcodes or offsets in a
C++ foreach loop.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2587143002
Cr-Commit-Position: refs/heads/master@{#41851}
Encode the PropertyAttribute and whether the function
names must be set as a flag instead of setting two registers.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2586463002
Cr-Commit-Position: refs/heads/master@{#41812}
STRUCT_LIST and INSTANCE_TYPE_LIST are now forced to have the same order
as the InstanceType enum.
Drive-by-fix 1: Move type check and cast functions closer together in objects-inl.h
Drive-by-fix 2: Remove unused instance types SIGNATURE_INFO_TYPE and TYPE_SWITCH_INFO_TYPE.
BUG=
Review-Url: https://codereview.chromium.org/2578573002
Cr-Commit-Position: refs/heads/master@{#41804}
This is so that a NotSuperConstructor error is thrown before evaluating the
arguments to the super constructor. Besides updating the runtime function, a
new bytecode GetSuperConstructor is introduced.
BUG=v8:5336
Review-Url: https://codereview.chromium.org/2504553003
Cr-Commit-Position: refs/heads/master@{#41788}
There are subtle test expectations/nuances that are easy to break.
BUG=
Review-Url: https://codereview.chromium.org/2585583006
Cr-Commit-Position: refs/heads/master@{#41778}
Reason for revert:
This change rendered InstructionSequenceTest::SetNumRegs ineffectual, thus
loosening the tests that were using that API to ensure correct register
allocation under intentionally constrained setups.
For the problem stated in this CL, a solution needs to continue supporting the
intentionally set-up test configuration.
Original issue's description:
> MIPS: Fix bad RegisterConfiguration usage in InstructionSequence unit tests.
>
> Test InstructionSequenceTest has been initialized with a testing RegisterConfiguration
> instance defined in instruction-sequence-unittest.h, whereas class ExplicitOperand which
> is being tested used RegisterConfiguration from instruction.cc. In case these two
> instances are different, the tests would fail. The issue is fixed by using the same
> instance of RegisterConfiguration both for test code and code under test.
>
> Additionally, the tests in register-allocator-unittest.cc use hardcoded values
> for register and begin failing is the hardcoded register is not available for
> allocation. Fix by forcing the use of allocatable registers only.
>
> TEST=unittests.MoveOptimizerTest.RemovesRedundantExplicit,unittests.RegisterAllocatorTest.SpillPhi
> BUG=
>
> Committed: https://crrev.com/0cf56232209d4c9c669b8426680de18806f6c29a
> Cr-Commit-Position: refs/heads/master@{#40862}
TBR=dcarney@chromium.org,bmeurer@chromium.org,mstarzinger@chromium.org,vogelheim@chromium.org,titzer@chromium.org,ivica.bogosavljevic@imgtec.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.chromium.org/2587593002
Cr-Commit-Position: refs/heads/master@{#41777}
Transform LdaNull/LdaUndefined followed by StrictEquality to TestNull/TestUndefined.
This would avoid a call to the compare IC. In the bytecode-graph builder these are
mapped to StrictEqual javascript operator. When reducing this operator, we already
optimize the cases for null/undefined.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2554723004
Cr-Commit-Position: refs/heads/master@{#41768}
This introduces an explicit struct for the communication channel between
the {ArrayLiteral} AST node and the corresponding runtime methods. Those
methods take a pair of {ElementsKind} as well as an array (can either be
a FixedArray or a FixedDoubleArray) of constant values.
For bonus points it also reduces the size of the involved heap object by
one word (i.e. length field of FixedArray not needed anymore).
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2581683003
Cr-Commit-Position: refs/heads/master@{#41752}
This behavior changed recently. SharedArrayBuffers should not be put in the
transfer list, because they are not detached, and that is the meaning of being
in the transfer list.
This is the V8 side of the change, the Blink side will come next.
Review-Url: https://codereview.chromium.org/2570433005
Cr-Commit-Position: refs/heads/master@{#41740}
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}
MIPS[64]R6 supports only fusion multiply-accumulate instructions, and using
these causes failures of several tests that expect exact floating-point
results. Therefore we disable fusion multiply-accumulate in both emitted and
compiled code on R6.
TEST=cctest/test-run-machops/RunFloat64MulAndFloat64Add1,mjsunit/es6/math-expm1.js
mjsunit/es6/math-fround.js,mjsunit/compiler/multiply-add.js
BUG=
Review-Url: https://codereview.chromium.org/2569683002
Cr-Commit-Position: refs/heads/master@{#41717}
Allocate the registers used as arguments to a call on-demand after visiting the
argument (or reciever). This means that the visited expression can use registers
that would otherwise have been allocated for arguments which haven't been
visited yet.
The reason for doing this is to avoid keeping things live in registers
unecessarily for chained function calls, which avoids a memory leak for
functions which chain a large number of calls with large temporary arguments /
recievers.
BUG=chromium:672027
Review-Url: https://codereview.chromium.org/2557173004
Cr-Commit-Position: refs/heads/master@{#41714}
Templatizes the AccumulatorUsage and OperandType for BytecodeNode creation and
BytecodeRegisterOptimizer::PrepareForBytecode. This allows the compiler to
statically know whether the bytecode being created accesses the accumulator
and what operand types need scaling, avoiding runtime checks in the code.
Also removes BytecodeNode::set_bytecode methods.
Review-Url: https://codereview.chromium.org/2542903003
Cr-Commit-Position: refs/heads/master@{#41706}
Reason for revert:
LiveEdit is broken in some cases.
Original issue's description:
> Store SharedFunctionInfos of a Script in a FixedArray indexed by their ID
>
> Now that SharedFunctionInfos have a unique ID (and the IDs are dense),
> we can use them as an index into an array, instead of using a
> WeakFixedArray where we have to do a linear scan.
>
> Hooking up liveedit is a bit more involved, see
> https://docs.google.com/presentation/d/1FtNa3U7WsF5bPhY9uGoJG5Y9hnz5VBDabfOWpb4unWI/edit
> for an overview
>
> BUG=v8:5589
> R=verwaest@chromium.org,jgruber@chromium.org
>
> Committed: https://crrev.com/6595e7405769dc9d49e9568d61485efc6d468baf
> Cr-Commit-Position: refs/heads/master@{#41600}
TBR=jgruber@chromium.org,verwaest@chromium.org,yangguo@chromium.org,jochen@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5589,chromium:673950
NOPRESUBMIT=true
Review-Url: https://codereview.chromium.org/2578433002
Cr-Commit-Position: refs/heads/master@{#41684}
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}
Introduces:
- a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions.
- a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan.
The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST.
This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value.
BUG=v8:4280
R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.orgTBR=rossberg@chromium.org
Review-Url: https://codereview.chromium.org/2557593004
Cr-Commit-Position: refs/heads/master@{#41555}
This just calls into a runtime function for implementation currently.
Intermediate step in speeding up constructor calls containing a spread.
The NewWithSpread bytecode will probably end up having different arguments with future CLs - the constructor and the new.target should have their own regs. For now we are calling into the runtime function, so we need the regs together.
BUG=v8:5659
Review-Url: https://codereview.chromium.org/2541113004
Cr-Commit-Position: refs/heads/master@{#41542}
Equality with null/undefined is equivalent to a check on the undetectable bit
on the map of the object. This would be more efficient than performing the entire
comparison operation.
This cl introduces:
1. A new bytecode called TestUndetectable that checks if the object is null/undefined.
2. Updates peeophole optimizer to emit TestUndetectable when a LdaNull/Undefined
precedes equality check.
4. TestUndetectable is transformed to ObjectIsUndetectable operator when building
turbofan graph.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2547043002
Cr-Commit-Position: refs/heads/master@{#41514}
Reorders the jump bytecodes so that the majority of jump checks can be
implemented as range checks (rather than a list of comparisons that get
compiled to a bunch of jumps).
Review-Url: https://codereview.chromium.org/2537123002
Cr-Commit-Position: refs/heads/master@{#41498}
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}
The current CHECK/DCHECK implementation fails statically if a signed
value is compared against an unsigned value. The common solution is to
cast on each caller, which is tedious and error-prone (might hide bugs).
This CL implements signed vs. unsigned comparisons by executing up to
two comparisons. For example, if i is int32_t and u is uint_32_t, a
DCHECK_LE(i, u) would create the check
i <= 0 || static_cast<uint32_t>(i) <= u.
For checks against constants, at least one of the checks can be removed
by compiler optimizations.
The tradeoff we have to make is to sometimes silently execute an
additional comparison. And we increase code complexity of course, even
though the usage is just as easy (or even easier) as before.
The compile time impact seems to be minimal:
I ran 3 full compilations for Optdebug on my local machine, one time on
the current ToT, one time with this CL plus http://crrev.com/2524093002.
Before: 143.72 +- 1.21 seconds
Now: 144.18 +- 0.67 seconds
In order to check that the new comparisons are working, I refactored
some DCHECKs in wasm to use the new magic, and added unit test cases.
R=ishell@chromium.org, titzer@chromium.orgCC=ahaas@chromium.org, bmeurer@chromium.org
Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
Review-Url: https://codereview.chromium.org/2526783002
Cr-Original-Commit-Position: refs/heads/master@{#41275}
Cr-Commit-Position: refs/heads/master@{#41411}
JS operators always have an implicit context input, so just use that instead.
BUG=
Review-Url: https://codereview.chromium.org/2541813002
Cr-Commit-Position: refs/heads/master@{#41392}
These byte pointers (module_start and module_end) were only valid
during decoding. During instantiation or execution, they can get
invalidated by garbage collection.
This CL removes them from the WasmModule struct, and introduces a new
ModuleStorage struct as interface to the wasm wire bytes.
Since the storage is often needed together with the ModuleEnv, a new
ModuleStorageEnv struct holds both a ModuleEnv and a ModuleStorage.
The pointers in the ModuleStorage should never escape the live range of
this struct, as they might point into a SeqOneByteString or ArrayBuffer.
Therefore, the WasmInterpreter needs to create its own copy of the
whole module.
Runtime functions that previously used the raw pointers in WasmModule
(leading to memory errors) now have to use the SeqOneByteString in the
WasmCompiledModule.
R=titzer@chromium.org
BUG=chromium:669518
Review-Url: https://codereview.chromium.org/2540133002
Cr-Commit-Position: refs/heads/master@{#41388}
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}
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}
They're supposed to be stable across several parse passes, so we'll also
store them in the associated SharedFunctionInfos
To achieve this, the PreParser and Parser need to generated the same number of
FunctionLiterals. To achieve this, we teach the PreParser about desuggaring of
class literals.
For regular functions, the function IDs are assigned in the order they occur in
the source. For arrow functions, however, we only know that it's an arrow function
after parsing the parameter list, and so the ID assigned to the arrow function is
larger than the IDs assigned to functions defined in the parameter list. This
implies that we have to reset the function ID counter to before the parameter list
when re-parsing an arrow function. To be able to do this, we store the number of
function literals found in the parameter list of arrow functions as well.
BUG=v8:5589
Review-Url: https://codereview.chromium.org/2481163002
Cr-Commit-Position: refs/heads/master@{#41309}
Reason for revert:
Seems to cause compile errors on Android. Will investigate on Monday.
Original issue's description:
> [base] Pass scalar arguments by value in CHECK/DCHECK
>
> This not only potentially improves performance, but also avoids weird
> linker errors, like the one below, where I used Smi::kMinValue in a
> DCHECK_EQ.
>
> > [421/649] LINK ./mksnapshot
> > FAILED: mksnapshot
> > src/base/logging.h|178| error: undefined reference to
> 'v8::internal::Smi::kMinValue'
>
> R=bmeurer@chromium.org, ishell@chromium.org
>
> Committed: https://crrev.com/76723502528c5af003fdffc3520632ea2a13fef3
> Cr-Commit-Position: refs/heads/master@{#41273}
TBR=bmeurer@chromium.org,ishell@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/2527883004
Cr-Commit-Position: refs/heads/master@{#41278}
This not only potentially improves performance, but also avoids weird
linker errors, like the one below, where I used Smi::kMinValue in a
DCHECK_EQ.
> [421/649] LINK ./mksnapshot
> FAILED: mksnapshot
> src/base/logging.h|178| error: undefined reference to
'v8::internal::Smi::kMinValue'
R=bmeurer@chromium.org, ishell@chromium.org
Review-Url: https://codereview.chromium.org/2524093002
Cr-Commit-Position: refs/heads/master@{#41273}
RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.
BUG=
Review-Url: https://codereview.chromium.org/2511093002
Cr-Commit-Position: refs/heads/master@{#41254}
Also lower JSToBoolean(x) where x is either some detectable receiver or
null, or any kind of receiver, null or undefined. Also fix a couple of
minor issues with the JSToBoolean lowering and tests.
R=yangguo@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2530773002
Cr-Commit-Position: refs/heads/master@{#41241}
Reason for revert:
The test is very flaky on the bots, e.g.:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/17031https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/14776
Original issue's description:
> [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters
>
> RuntimeTimerScopes always subtract their own time from the parent timer's
> counter to properly account for the own time. Once a scope is destructed it
> adds it own timer to the current active counter. However, if the current
> counter is changed with CorrectCurrentCounterId we will attribute all the
> subtimers to the previous counter, and add the own time to the new counter.
> This way it is possible to end up with negative times in certain counters but
> the overall would still be correct.
>
> BUG=
>
> Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
> Committed: https://crrev.com/491651792d7818aed04eaeffb9890b5a309b543e
> Cr-Original-Commit-Position: refs/heads/master@{#41142}
> Cr-Commit-Position: refs/heads/master@{#41214}
TBR=ishell@chromium.org,fmeawad@chromium.org,lpy@chromium.org,cbruni@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.chromium.org/2526843002
Cr-Commit-Position: refs/heads/master@{#41229}
Since we are specializing on the native context, we don't have to load
the vector from the closure. For one thing, this reduces the machinery for
nodes that use a vector in their generic incarnation.
BUG=
R=mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2529463002
Cr-Commit-Position: refs/heads/master@{#41221}
RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.
BUG=
Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
Review-Url: https://codereview.chromium.org/2511093002
Cr-Original-Commit-Position: refs/heads/master@{#41142}
Cr-Commit-Position: refs/heads/master@{#41214}
This code should not access bytes out of the permitted range in order to check
the range of a possible UTF-8 value. Instead, the length check should occur
before such checks.
BUG=chromium:667260, chromium:662822
Review-Url: https://codereview.chromium.org/2520053003
Cr-Commit-Position: refs/heads/master@{#41165}
This pre-calculates and stores a vector of bytecode offsets, and then allows
one to iterate over it backwards. This could probably be adapted to a
bidirectional/random access iterator if we wanted to, but for now reverse
is all we need.
Review-Url: https://codereview.chromium.org/2518003002
Cr-Commit-Position: refs/heads/master@{#41153}
Reason for revert:
Wronged it even more.
Original issue's description:
> [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters
>
> RuntimeTimerScopes always subtract their own time from the parent timer's
> counter to properly account for the own time. Once a scope is destructed it
> adds it own timer to the current active counter. However, if the current
> counter is changed with CorrectCurrentCounterId we will attribute all the
> subtimers to the previous counter, and add the own time to the new counter.
> This way it is possible to end up with negative times in certain counters but
> the overall would still be correct.
>
> BUG=
>
> Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
> Cr-Commit-Position: refs/heads/master@{#41142}
TBR=ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.chromium.org/2519073002
Cr-Commit-Position: refs/heads/master@{#41150}
RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.
BUG=
Review-Url: https://codereview.chromium.org/2511093002
Cr-Commit-Position: refs/heads/master@{#41142}
The reason:
The CL #40862 (https://codereview.chromium.org/2433093002 ) caused 2 test cases failed for X87.
Because Both 2 test cases (MoveOptimizerTest.RemovesRedundantExplicit and RegisterAllocatorTest.CanAllocateFPRegisters)
needs 2 allocatable Float/Double registers.
But there's only 1 allocatable Float/Double register in x87 turbofan compiler, i.e.: register index 0.
This CL disables MoveOptimizerTest.RemovesRedundantExplicit and RegisterAllocatorTest.CanAllocateFPRegisters test cases for x87.
BUG=
Review-Url: https://codereview.chromium.org/2520623005
Cr-Commit-Position: refs/heads/master@{#41131}
This reverts commit 3c96c5e232.
The CL was reverted to see its impact on UMA memory counters.
There was no impact, so we can safely reland the CL.
BUG=
Review-Url: https://codereview.chromium.org/2507293004
Cr-Commit-Position: refs/heads/master@{#41109}
Adds the marking logic to mark the young generation.
BUG=chromium:651354
Review-Url: https://codereview.chromium.org/2498583002
Cr-Commit-Position: refs/heads/master@{#41104}
Add bytecode for defining data properties, which initially just calls the runtime function.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2510743002
Cr-Commit-Position: refs/heads/master@{#41101}
This is the TurboFan counterpart of http://crrev.com/2504263004, but it
is a bit more involved, since in TurboFan we always inline the appropriate
call to the @@hasInstance handler, and by that we can optimize a lot more
patterns of instanceof than Crankshaft, and even yield fast instanceof
for custom @@hasInstance handlers (which we can now properly inline as
well).
Also we now properly optimize Function.prototype[@@hasInstance], even if
the right hand side of an instanceof doesn't have the Function.prototype
as its direct prototype.
For the baseline case, we still rely on the global protector cell, but
we can address that in a follow-up as well, and make it more robust in
general.
TEST=mjsunit/compiler/instanceof
BUG=v8:5640
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2511223003
Cr-Commit-Position: refs/heads/master@{#41092}
With this change, WebAssembly.Memory objects have backing stores allocated as an
8GB region where everything beyond the size of the Wasm heap is inaccessible.
GrowMemory is now implemented by changing the protection on the guard regions to
make the new portions of the heap accessible.
Guard pages are not enabled by default, but this change adds a flag and a test
variant to make sure we get test coverage on them.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2396433008
Cr-Commit-Position: refs/heads/master@{#41089}
The control edges in a TurboFan graph can form a cycle. To break this cycle in the int64-lowering we add special handling for loop nodes. Similar handling already exists for phi nodes and effectphi nodes, which breaks cycles formed by value edges and effect edges, respectively.
Review-Url: https://codereview.chromium.org/2511503002
Cr-Commit-Position: refs/heads/master@{#41071}
The reasons are:
1) The names dictionaries in the feedback metadata seems to consume a lot of memory
and the idea didn't payoff.
2) The absence of a name parameter blocks data handlers support in LoadGlobalIC.
This CL reverts a part of r37278 (https://codereview.chromium.org/2096653003/).
BUG=chromium:576312, v8:5561
Review-Url: https://codereview.chromium.org/2510653002
Cr-Commit-Position: refs/heads/master@{#41046}
This is in preparation for introducing more specialized
CodeStubAssembler subclasses. The state object can be handed
around, while the Assembler instances are temporary-scoped.
BUG=v8:5628
Original review: https://codereview.chromium.org/2498073002/
Review-Url: https://codereview.chromium.org/2502293002
Cr-Commit-Position: refs/heads/master@{#41028}
Adds a bytecode to set and retrieve the pending message. This avoids a
runtime call in finally blocks, and also ensures that TurboFan builds a
graph using the SetMessage / LoadMessage nodes instead of inserting a
runtime call.
BUG=chromium:662334
Review-Url: https://codereview.chromium.org/2501503005
Cr-Commit-Position: refs/heads/master@{#41023}
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared doesn't want to compile. Missing export annotation?
Original issue's description:
> [refactoring] Split CodeAssemblerState out of CodeAssembler
>
> This is in preparation for introducing more specialized
> CodeStubAssembler subclasses. The state object can be handed
> around, while the Assembler instances are temporary-scoped.
>
> BUG=v8:5628
TBR=ishell@chromium.org,mstarzinger@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5628
Review-Url: https://codereview.chromium.org/2504913002
Cr-Commit-Position: refs/heads/master@{#41018}
This is in preparation for introducing more specialized
CodeStubAssembler subclasses. The state object can be handed
around, while the Assembler instances are temporary-scoped.
BUG=v8:5628
Review-Url: https://codereview.chromium.org/2498073002
Cr-Commit-Position: refs/heads/master@{#41015}
Currently, we are using the following sequence for load/store
with large offset (offset > 16b):
lui at, 0x1234
ori at, at, 0x5678
add at, s0, at
lw a0, 0(at)
This sequence can be optimized in the following way:
lui at, 0x1234
add at, s0, at
lw a0, 0x5678(at)
BUG=
Review-Url: https://codereview.chromium.org/2503493002
Cr-Commit-Position: refs/heads/master@{#40988}
Port 0322c20d17
Original commit message:
When storing an immediate integer or floating point zero, use the zero register
as the source value. This avoids the need to sometimes allocate a new register.
BUG=
Review-Url: https://codereview.chromium.org/2470133005
Cr-Commit-Position: refs/heads/master@{#40987}
SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
- The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
- The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
The following additional changes were necessary:
- The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
- The class HPositionInfo was effectively dead code and is now removed.
- SourcePosition has new printing and information facilities, including computing a full inlining stack.
- I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
- I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
- I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
- Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
BUG=v8:5432
Review-Url: https://codereview.chromium.org/2451853002
Cr-Commit-Position: refs/heads/master@{#40975}
Reason for revert:
Breaks CQ trybots now, i.e. https://build.chromium.org/p/tryserver.v8/builders/v8_linux_mipsel_compile_rel/builds/24703/steps/compile%20with%20ninja/logs/stdio
Original issue's description:
> MIPS: Optimize load/store with large offset
>
> Currently, we are using the following sequence for load/store with large offset (offset > 16b):
>
> lui at, 0x1234
> ori at, at, 0x5678
> add at, s0, at
> lw a0, 0(at)
>
> This sequence can be optimized in the following way:
>
> lui at, 0x1234
> add at, s0, at
> lw a0, 0x5678(at)
>
> BUG=
TBR=ivica.bogosavljevic@imgtec.com,miran.karic@imgtec.com,v8-mips-ports@googlegroups.com,dusan.simicic@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.chromium.org/2500863003
Cr-Commit-Position: refs/heads/master@{#40959}
In component build, unittests did not link with icu libraries, which
caused errors. By adding icu libraries to dependencies unittests links
correctly.
BUG=
TEST=unittests/*
Review-Url: https://codereview.chromium.org/2479863002
Cr-Commit-Position: refs/heads/master@{#40955}
Currently, we are using the following sequence for load/store with large offset (offset > 16b):
lui at, 0x1234
ori at, at, 0x5678
add at, s0, at
lw a0, 0(at)
This sequence can be optimized in the following way:
lui at, 0x1234
add at, s0, at
lw a0, 0x5678(at)
BUG=
Review-Url: https://codereview.chromium.org/2486283003
Cr-Commit-Position: refs/heads/master@{#40953}
ToName conversion, i.e., ToPropertykey() is the
identify for strings and symbols.
BUG=v8:5623
Review-Url: https://codereview.chromium.org/2494073002
Cr-Commit-Position: refs/heads/master@{#40924}
This adds a new ExternalPointer type, which is an Internal type that is
used for ExternalReferences and other pointer values, like the pointers
into the asm.js heap. It also adds a PointerConstant operator, which we
use to represents these raw constants (we can probably remove that
particular operator again once WebAssembly ships with the validator).
R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2494753003
Cr-Commit-Position: refs/heads/master@{#40923}
We seem to get some small wins from avoiding the Ldr bytecodes, probably due
to reduced icache pressure since there are less bytecode handlers. Replace
the Ldr bytecodes with Star lookahead inlined into the Lda versions.
Also fixes IsAccumulatorLoadWithoutEffects to include LdaContextSlot and
LdaCurrentContextSlot
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2489513005
Cr-Commit-Position: refs/heads/master@{#40883}
Test InstructionSequenceTest has been initialized with a testing RegisterConfiguration
instance defined in instruction-sequence-unittest.h, whereas class ExplicitOperand which
is being tested used RegisterConfiguration from instruction.cc. In case these two
instances are different, the tests would fail. The issue is fixed by using the same
instance of RegisterConfiguration both for test code and code under test.
Additionally, the tests in register-allocator-unittest.cc use hardcoded values
for register and begin failing is the hardcoded register is not available for
allocation. Fix by forcing the use of allocatable registers only.
TEST=unittests.MoveOptimizerTest.RemovesRedundantExplicit,unittests.RegisterAllocatorTest.SpillPhi
BUG=
Review-Url: https://codereview.chromium.org/2433093002
Cr-Commit-Position: refs/heads/master@{#40862}
The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when
inlining accessors in TurboFan. Remove them and replace with a Star lookahead
in the bytecode handlers for Lda[Named/Keyed]Property.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2485383002
Cr-Commit-Position: refs/heads/master@{#40860}
The spec defines that indirect calls in WebAssembly code should cause a
validation error if no function table exists.
The CL contains the following changes:
1) Throw a validation error for indirect calls if the function table
not exist.
2) Do not create TF nodes to throw a runtime error for indirect calls
if the function table does not exist.
3) Fix existing unit tests by creating a dummy function table.
4) Add new a new test which tests that indirect calls without function
table cause a validation error.
R=rossberg@chromium.orgCC=titzer@chromium.org
TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash
Review-Url: https://codereview.chromium.org/2484623002
Cr-Commit-Position: refs/heads/master@{#40852}
This introduces two new bytecodes LdaModuleVariable and StaModuleVariable,
replacing the corresponding runtime calls.
Support in the bytecode graph builder exists only in the form of runtime calls.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2471033004
Cr-Commit-Position: refs/heads/master@{#40825}
Reason for revert:
Speculative revert for blocking roll:
https://codereview.chromium.org/2479233002/
Original issue's description:
> [wasm] Indirect calls without function table cause validation errors.
>
> The spec defines that indirect calls in WebAssembly code should cause a
> validation error if no function table exists.
>
> The CL contains the following changes:
> 1) Throw a validation error for indirect calls if the function table
> not exist.
> 2) Do not create TF nodes to throw a runtime error for indirect calls
> if the function table does not exist.
> 3) Fix existing unit tests by creating a dummy function table.
> 4) Add new a new test which tests that indirect calls without function
> table cause a validation error.
>
> R=rossberg@chromium.org
> CC=titzer@chromium.org
>
> TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash
TBR=rossberg@chromium.org,titzer@chromium.org,ahaas@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/2479283002
Cr-Commit-Position: refs/heads/master@{#40811}
The existing Load/StoreContextElement operations take the index as an int. This
CL adds versions that take the index as a Node. These already existed in the
interpreter-assembler, from which they are now removed.
R=mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2473003004
Cr-Commit-Position: refs/heads/master@{#40810}
The spec defines that indirect calls in WebAssembly code should cause a
validation error if no function table exists.
The CL contains the following changes:
1) Throw a validation error for indirect calls if the function table
not exist.
2) Do not create TF nodes to throw a runtime error for indirect calls
if the function table does not exist.
3) Fix existing unit tests by creating a dummy function table.
4) Add new a new test which tests that indirect calls without function
table cause a validation error.
R=rossberg@chromium.orgCC=titzer@chromium.org
TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash
Review-Url: https://codereview.chromium.org/2484623002
Cr-Commit-Position: refs/heads/master@{#40802}
The maximum memory size is a user-defined upper limit for the size of
the memory of a WebAssembly instance. The actual limit is the minimum of
the user-defined limit and the V8 limit. With this CL we allow the
user-defined limit to be greater than the V8 limit, which is required by
the spec.
R=titzer@chromium.orgCC=gdeepti@chromium.org
TEST=unittests/WasmModuleVerifyTest.MaxMaximumMemorySize
Review-Url: https://codereview.chromium.org/2484643002
Cr-Commit-Position: refs/heads/master@{#40801}
Compatible with the current (unshipped) Blink implementation.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2471923002
Cr-Commit-Position: refs/heads/master@{#40775}
Reason for the failure is that the test enumeration is 32-bit wide, whereas
AtomicWord is 64-bit wide on 64-bit machines. On 64-big endian, this loads the random four bytes located after the 32-bit value that is tested.
BUG=
TEST=unittests/NoBarrierAtomicValue.Construction
Review-Url: https://codereview.chromium.org/2464703003
Cr-Commit-Position: refs/heads/master@{#40767}
Port f07d2cdd6a
Original commit message:
A load instruction will implicitely clear the top 32 bits when writing to a W
register. This patch avoids generating a `mov` instruction to zero-extend the
result in this case.
For example, this occurs in the generated code for dispatching to the next
bytecode in the interpreter:
kind = BYTECODE_HANDLER
name = LdaZero
compiler = turbofan
Instructions (size = 36)
0x32e64c60 0 add x19, x19, #0x1 (1)
0x32e64c64 4 ldrb w0, [x20, x19]
0x32e64c68 8 mov w0, w0
^^^^^^^^^^
0x32e64c6c 12 lsl x0, x0, #3
0x32e64c70 16 ldr x1, [x21, x0]
0x32e64c74 20 movz x0, #0x0
0x32e64c78 24 br x1
Review-Url: https://codereview.chromium.org/2469253002
Cr-Commit-Position: refs/heads/master@{#40758}
Use HeapConstant for string_iterator_map rather than loading it
manually. This avoids unnecessary map checks.
BUG= v8:3822,v8:5267
Review-Url: https://codereview.chromium.org/2479563003
Cr-Commit-Position: refs/heads/master@{#40741}
Reason for revert:
Speculative revert to see impact on crbug.com/659531
Original issue's description:
> [heap] Add a guard for restarting the memory reducer after mark-compact.
>
> Currently it is possible to get into a cycle of
> mark-compact -> memory reducer -> mark-compact -> memory reducer ...
> where the memory reducer does not free memory.
>
> This patch ensures that the memory reducer restarts only if the
> committed memory increased by sufficient amount after the last run.
>
> BUG=
TBR=hpayer@chromium.org,davidroutier17@gmail.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.chromium.org/2472053003
Cr-Commit-Position: refs/heads/master@{#40737}
Exchanged the ZoneList for a ZoneChunkList to avoid
unnecessary growing.
Review-Url: https://codereview.chromium.org/2468183004
Cr-Commit-Position: refs/heads/master@{#40736}
This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.
The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
slots to pop upon return in addition to those specified by the Linkage of the
compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
handles all tail-call cases except where the return value type differs, this fallback
was not really useful and in fact caused unexpected behavior with variable
sized argument popping, since it wasn't possible to materialize a Return node
with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
pop argument since the variable pop functionality
LOG=N
Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40699}
Reason for revert:
Seems to break arm64 sim debug and blocks roll:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294
Original issue's description:
> [turbofan] Support variable size argument removal in TF-generated functions
>
> This is preparation for using TF to create builtins that handle variable number of
> arguments and have to remove these arguments dynamically from the stack upon
> return.
>
> The gist of the changes:
> - Added a second argument to the Return node which specifies the number of stack
> slots to pop upon return in addition to those specified by the Linkage of the
> compiled function.
> - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
> handles all tail-call cases except where the return value type differs, this fallback
> was not really useful and in fact caused unexpected behavior with variable
> sized argument popping, since it wasn't possible to materialize a Return node
> with the right pop count from the TailCall without additional context.
> - Modified existing Return generation to pass a constant zero as the additional
> pop argument since the variable pop functionality
>
> LOG=N
TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
NOPRESUBMIT=true
Review-Url: https://codereview.chromium.org/2473643002
Cr-Commit-Position: refs/heads/master@{#40691}
This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.
The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
slots to pop upon return in addition to those specified by the Linkage of the
compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
handles all tail-call cases except where the return value type differs, this fallback
was not really useful and in fact caused unexpected behavior with variable
sized argument popping, since it wasn't possible to materialize a Return node
with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
pop argument since the variable pop functionality
LOG=N
Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40678}
While this seems like it should be true, the array buffer is not actually
neutered until the end of cloning. This is so that, if an exception is thrown
during serialization, the original array buffer is not left neutered. As a
result, Blink will not have neutered the buffer.
This fixes some DCHECK failures during layout tests.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2466563002
Cr-Commit-Position: refs/heads/master@{#40675}
The majority of context slot accesses are to the local context (current context
register and depth 0), so this adds bytecodes to optimise for that case.
This cuts down bytecode size by roughly 1% (measured on Octane and Top25).
Review-Url: https://codereview.chromium.org/2459513002
Cr-Commit-Position: refs/heads/master@{#40641}
This is a new bytecode which behaves (for now) exactly like Call,
except that in turbofan graph building we can set the
ConvertReceiverMode to NotNullOrUndefined.
I observe a 1% improvement on Box2D, I'd expect a similar improvement on
other OOP heavy code.
Review-Url: https://codereview.chromium.org/2450243002
Cr-Commit-Position: refs/heads/master@{#40610}
Since ZoneLists are essentially non-standard ZoneVectors and have a bad
growing behaviour (ZoneList-allocations make up ~50% of website parse
zone memory) we should stop using them. The zone-containers are merely
a clean-up, with none of them actually better suited to be used with
zones. This new datastructure allows most operations of a LinkedList (
except pop_first and insertAt/removeAt) but uses about the same memory
as a well-initialized ZoneVector/ZoneList (<3% overhead with reasonably
large lists). It also never attempts to free memory again (which would
not work in zones anyway).
The ZoneChunkList is essentially a doubly-linked-list of arrays of
variable size.
Some test-results where I tried storing 16k pointers in different list
types (lists themselves also zone-allocated):
List type Zone memory used Time taken
-----------------------------------------------------------------------
Zone array (for comparison) 131072 B
Ideally initialized ZoneList 131088 B 0.062ms
ChunkZoneList 134744 B 0.052ms <--new thing
ZoneDeque 141744 B
ZoneLinkedList 393264 B
Initially empty ZoneList 524168 B 0.171ms <--right now
ChunkZoneList only push_front 524320 B
Review-Url: https://codereview.chromium.org/2449383002
Cr-Commit-Position: refs/heads/master@{#40602}
- Modifies RegisterConfiguration to specify complex aliasing on ARM 32.
- Modifies RegisterAllocator to consider aliasing.
- Modifies ParallelMove::PrepareInsertAfter to handle aliasing.
- Modifies GapResolver to split wider register moves when interference
with smaller moves is detected.
- Modifies MoveOptimizer to handle aliasing.
- Adds ARM 32 macro-assembler pseudo move instructions to handle cases where
split moves don't correspond to actual s-registers.
- Modifies CodeGenerator::AssembleMove and AssembleSwap to handle moves of
different widths, and moves involving pseudo-s-registers.
- Adds unit tests for FP operand interference checking and PrepareInsertAfter.
- Adds more tests of FP for the move optimizer and register allocator.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2410673002
Cr-Commit-Position: refs/heads/master@{#40597}
Modify the Bytecode Register Optimizer to be an independent component
rather than part of the BytecodePipeline. This means the BytecodeArrayBuilder
can explicitly call it with register operands when outputting a bytecode
and the Bytecode Register Optimizer doesn't need to work out which operands
are register operands. This also means we don't need to build BytecodeNodes
for Ldar / Star / Mov bytecodes unless they are actually emitted by the
optimizer.
This change also modifies the way the BytecodeArrayBuilder converts
operands to make use of the OperandTypes specified in bytecodes.h.
This avoids having to individually convert operands to their raw output
value before calling Output(...).
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2393683004
Cr-Commit-Position: refs/heads/master@{#40543}
Additionally, remove all code related to the old-style slots filtering and black area end markers.
BUG=chromium:648568
Review-Url: https://chromiumcodereview.appspot.com/2440683002
Cr-Commit-Position: refs/heads/master@{#40494}
Added a size constraint to the configuration to limit the segment pool.
This will likely fix the memory alerts from small android devices.
BUG=chromium:655129
Review-Url: https://chromiumcodereview.appspot.com/2424393002
Cr-Commit-Position: refs/heads/master@{#40476}
Currently it is possible to get into a cycle of
mark-compact -> memory reducer -> mark-compact -> memory reducer ...
where the memory reducer does not free memory.
This patch ensures that the memory reducer restarts only if the
committed memory increased by sufficient amount after the last run.
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2433933005
Cr-Commit-Position: refs/heads/master@{#40457}
This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.
This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.
Additionally, this CL implements the proper base + offset initialization
behavior for tables.
R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316
Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}
MIPS64 doesn't support Word32 compare instructions. Instead it relies
that the values in registers are correctly sign-extended and uses
Word64 comparison instead. This behavior is correct in most cases,
but doesn't work when comparing signed with unsigned operands.
The solution proposed here tries to match a comparison of signed
with unsigned operand, and perform Word32Compare simulation only
in those cases. Unfortunately, the solution is not complete because
it might skip cases where Word32 compare simulation is needed, so
basically it is a hack.
BUG=
TEST=mjsunit/compiler/uint32
Review-Url: https://codereview.chromium.org/2391393003
Cr-Commit-Position: refs/heads/master@{#40398}
EffectPhis can cause a cycle in a TurboFan graph. We delay the
processing of EffectPhis in the Int64Lowering to break these cycles. We
do the same already for Phis.
R=titzer@chromium.org
BUG=v8:5518
TEST=unittests/Int64LoweringTest.EffectPhiLoop
Review-Url: https://codereview.chromium.org/2428583002
Cr-Commit-Position: refs/heads/master@{#40378}
This adds more useful information to the v8-heap-stats tool.
BUG=v8:5489
Review-Url: https://codereview.chromium.org/2394213003
Cr-Commit-Position: refs/heads/master@{#40361}
Adds a boolean flag to the liveness analysis which makes it also analyze
the accumulator. This can help prevent the accumulator escaping loops,
as well as decreasing the number of distinct state values nodes in the
graph.
The flag is a kind of ugly way to hack this in, however it is probably
the simplest to add, and (more importantly) to remove once the AST graph
builder is gone.
I measure a 2.6% improvement on Mandreel on my x64 machine, and a ~2%
improvement on Navier-Stokes. Other improvements are expected.
Review-Url: https://codereview.chromium.org/2428503002
Cr-Commit-Position: refs/heads/master@{#40359}
This allows people writing code stubs to just verify the graph of the stub they're working on, at least until we fix all of the issues we have and enable the verification by default.
Also fixes representations in CodeStubAssembler::SmiOr and InterpreterAssembler::StarDispatchLookahead.
R=bmeurer@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2413653006
Cr-Commit-Position: refs/heads/master@{#40320}
This CL also introduces a NoBarrierAtomicValue with NoBarrier accessors.
BUG=chromium:648568
Review-Url: https://codereview.chromium.org/2408233004
Cr-Commit-Position: refs/heads/master@{#40213}
For the asm.js to WASM pipeline, the current stack traces only show
low-level WASM information.
This CL maps this back to asm.js source positions.
It does so by attaching the asm.js source Script to the compiled WASM
module, and emitting a delta-encoded table which maps from WASM byte
offsets to positions within that Script. As asm.js code does not throw
exceptions, we only store a mapping for call instructions.
The new AsmJsWasmStackFrame implementation inherits from
WasmStackFrame, but contains the logic to provide the source script and
the position inside of it.
What is still missing is the JSFunction object returned by
CallSite.getFunction(). We currently return null.
R=jgruber@chromium.org, titzer@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2404253002
Cr-Commit-Position: refs/heads/master@{#40205}
If passing <nullptr, 0> to the decoder and trying to decode something,
it correctly detects the error and sets an error message, but still
returns true on ok(), and returns a valid result.
I triggered this error by passing a null Vector, returned by FindSection(), to
the decoder.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2410913002
Cr-Commit-Position: refs/heads/master@{#40204}
- Adds an optional representation field to VReg and TestOperand structs.
- Adds a simple FP allocation test to register-allocator-unittest.cc.
- Adds some simple FP tests to move-optimizer-unittest.cc.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2400513002
Cr-Commit-Position: refs/heads/master@{#40117}
There were once plans to generate cross-context code with TurboFan,
however that doesn't fit into the model anymore, and so all of this
is essentially dead untested code (and thus most likely already broken
in subtle ways). With this mode still in place it would also be a lot
harder to make inlining based on SharedFunctionInfo work.
BUG=v8:2206,v8:5499
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2406803002
Cr-Commit-Position: refs/heads/master@{#40109}
Found with libfuzzer. The length is automatically converted to int (thus
large sizes could become negative, even though they are legal "array sizes").
Besides that, the length is coerced to a SMI (which is an even tighter
constraint on 32-bit systems, where it limits the legal sizes to 2^30 - 1).
Add checks that the length of a dense array is below that threshold, and also
fail fast if a length that is provided obviously could not be the correct dense
length (because there isn't enough data left in the buffer to populate such an
array).
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2399873002
Cr-Commit-Position: refs/heads/master@{#40094}
Previously this would result in applying trying to find a size modulo zero,
which causes SIGFPE. This approach was preferred over adding a default case
to preserve the ability of the compiler to detect unhandled switch cases
(within the valid range of the enum).
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2395073003
Cr-Commit-Position: refs/heads/master@{#40088}
This reverts commit 7db0ecdec3.
Manual revert since automatic revert is too large for the web interface.
BUG=
TBR=bmeurer@chromium.org,mstarzinger@chromium.org,yangguo@chromium.org,ahaas@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
Review-Url: https://codereview.chromium.org/2396353002
Cr-Commit-Position: refs/heads/master@{#40082}
Imports and exports in 0xC can be much more than functions, including
tables, memories, and globals. This CL refactors the underlying
organization of imports and exports to support these new import types.
BUG=
Committed: https://crrev.com/599f8a83420346d9cba5ff97bd2a7520468207b6
Review-Url: https://codereview.chromium.org/2390113003
Cr-Original-Commit-Position: refs/heads/master@{#40033}
Cr-Commit-Position: refs/heads/master@{#40050}
With this CL, we devolve all Constants introduced as they are with an object handle into
* Range - for integers
* Nan
* MinusZero
* OtherNumberConstant - for doubles
* HeapConstant
We reduce the amount we have to inspect an object handle during optimization. Also, simplifications result. For example, you never have to check if a Range contains a HeapConstant.
BUG=
Review-Url: https://codereview.chromium.org/2381523002
Cr-Commit-Position: refs/heads/master@{#40041}
Imports and exports in 0xC can be much more than functions, including
tables, memories, and globals. This CL refactors the underlying
organization of imports and exports to support these new import types.
BUG=
Review-Url: https://codereview.chromium.org/2390113003
Cr-Commit-Position: refs/heads/master@{#40033}
Reason for revert:
Speculative revert due to very strange-looking win/dbg failures
which reference SignedDivisionByConstant:
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736
Original issue's description:
> Reland "Turn libbase into a component"
>
> Original issue's description:
> > Turn libbase into a component
> >
> > This is a precondition for turning libplatform into a component
> >
> > BUG=v8:5412
> > R=jgruber@chromium.org,machenbach@chromium.org
> > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_
> dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
> >
> > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104
> > Cr-Commit-Position: refs/heads/master@{#39950}
>
> BUG=v8:5412
> TBR=jgruber@chromium.org,machenbach@chromium.org
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng
>
> Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb
> Cr-Commit-Position: refs/heads/master@{#39969}
TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5412
Review-Url: https://codereview.chromium.org/2396933002
Cr-Commit-Position: refs/heads/master@{#40009}
If possible, take the constant map from the (known) native context for
JSCreateIterResultObject, so that subsequent map checks can be
eliminated in case of iterator inlining.
R=jarin@chromium.org
BUG=v8:3822
Review-Url: https://codereview.chromium.org/2394783002
Cr-Commit-Position: refs/heads/master@{#39974}
Original issue's description:
> Turn libbase into a component
>
> This is a precondition for turning libplatform into a component
>
> BUG=v8:5412
> R=jgruber@chromium.org,machenbach@chromium.org
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_
dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
>
> Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104
> Cr-Commit-Position: refs/heads/master@{#39950}
BUG=v8:5412
TBR=jgruber@chromium.org,machenbach@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng
Review-Url: https://codereview.chromium.org/2395553002
Cr-Commit-Position: refs/heads/master@{#39969}
Reason for revert:
Main suspect for roll block:
https://codereview.chromium.org/2387403002/
Original issue's description:
> Turn libbase into a component
>
> This is a precondition for turning libplatform into a component
>
> BUG=v8:5412
> R=jgruber@chromium.org,machenbach@chromium.org
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
>
> Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104
> Cr-Commit-Position: refs/heads/master@{#39950}
TBR=jgruber@chromium.org,jochen@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5412
Review-Url: https://codereview.chromium.org/2393603002
Cr-Commit-Position: refs/heads/master@{#39960}
This is a precondition for turning libplatform into a component
BUG=v8:5412
R=jgruber@chromium.org,machenbach@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
Review-Url: https://codereview.chromium.org/2381273002
Cr-Commit-Position: refs/heads/master@{#39950}
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}
This patch replaces cumulative counters with the counters for the current GC cycle.
It also replaces the ring buffer of record incremental marking speeds with a single variable.
Review-Url: https://codereview.chromium.org/2361563004
Cr-Commit-Position: refs/heads/master@{#39826}
This matches current Crankshaft/fullcodegen behavior more closely and
thus reduces the chances that we run into unnecessary polymorphism due
to the field representation tracking in our object model.
Drive-by-fixes: Make sure the JSRegExp::lastIndex field stays Smi
if possible (otherwise we tank the regexp benchmark in Octane).
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_mac64_rel,v8_mac64_dbg
R=jarin@chromium.org
BUG=v8:5267
Committed: 6a939714e9
Committed: https://crrev.com/ee158e6c4cc896479a32245432a3c2fdd31bcb73
Committed: https://crrev.com/ddf792beb3a72f6dba83e94fc8ada03ebf1630bd
Review-Url: https://codereview.chromium.org/2367593003
Cr-Original-Original-Commit-Position: refs/heads/master@{#39692}
Cr-Original-Commit-Position: refs/heads/master@{#39748}
Cr-Commit-Position: refs/heads/master@{#39803}
[0xC] Convert to stack machine semantics.
[0xC] Use section codes instead of names.
[0xC] Add elements section decoding.
[0xC] Decoding of globals section.
[0xC] Decoding of memory section.
[0xC] Decoding of imports section.
[0xC] Decoding of exports section.
[0xC] Decoding of data section.
[0xC] Remove CallImport bytecode.
[0xC] Function bodies have an implicit block.
[0xC] Remove the bottom label from loops.
[0xC] Add signatures to blocks.
[0xC] Remove arities from branches.
Add tests for init expression decoding.
Rework compilation of import wrappers and how they are patched.
Rework function indices in debugging.
Fix ASM->WASM builder for stack machine.
Reorganize asm.js foreign functions due to import indices change.
R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
BUG=chromium:575167
LOG=Y
Committed: https://crrev.com/76eb976a67273b8c03c744f64ad850b0432554b9
Review-Url: https://codereview.chromium.org/2345593003
Cr-Original-Commit-Position: refs/heads/master@{#39678}
Cr-Commit-Position: refs/heads/master@{#39795}
The lowering of {JSToBoolean} operators in {JSTypedLowering} inserts
loads that are not part of the effect chain. This does not play well
with effect-sensitive data flow analysis (e.g. escape analysis). This
removes the lowering in question, we can implement it using a dedicated
simplified operator eventually if needed.
R=bmeurer@chromium.org
TEST=mjsunit/wasm/embenchen/lua_binarytrees
Review-Url: https://codereview.chromium.org/2366363003
Cr-Commit-Position: refs/heads/master@{#39773}
They are nops, but will be used when verifying the machine graph.
BUG=
Review-Url: https://codereview.chromium.org/2367413002
Cr-Commit-Position: refs/heads/master@{#39758}
The MachineOperatorReducer was only reducing word32 expressions of the type x << y | x >>> (32 - y) (and variants) to the equivalent Word32Ror. This CL applies the same pattern-matching logic to Word32Xor.
BUG=
Committed: https://crrev.com/a86397d890d3caa01a947e2a6e71beb1f58e6e6b
Review-Url: https://codereview.chromium.org/2199323003
Cr-Original-Commit-Position: refs/heads/master@{#38284}
Cr-Commit-Position: refs/heads/master@{#39757}
Reason for revert:
Tanks EarleyBoyer.
Original issue's description:
> [compiler] Properly guard the speculative optimizations for instanceof.
>
> Add a general feedback slot for instanceof similar to what we already have
> for for-in, which basically has a fast (indicated by the uninitialized
> sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
> we can only take the fast path when the feedback slot says it hasn't
> seen any funky inputs and nothing funky appeared in the prototype chain.
> In the TurboFan code we also deoptimize whenever we see a funky object
> (i.e. a proxy or an object that requires access checks) in the prototype
> chain (similar to what Crankshaft already did).
>
> Drive-by-fix: Also make Crankshaft respect the mode and therefore
> address the deopt loop in Crankshaft around instanceof.
>
> We might want to introduce an InstanceOfIC mechanism at some point and
> track the map of the right-hand side.
>
> BUG=v8:5267
> R=mvstanton@chromium.org
>
> Committed: https://crrev.com/a0484bc6116ebc2b855de87d862945e2ae07169b
> Cr-Commit-Position: refs/heads/master@{#39718}
TBR=mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2365223003
Cr-Commit-Position: refs/heads/master@{#39736}
Add a general feedback slot for instanceof similar to what we already have
for for-in, which basically has a fast (indicated by the uninitialized
sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
we can only take the fast path when the feedback slot says it hasn't
seen any funky inputs and nothing funky appeared in the prototype chain.
In the TurboFan code we also deoptimize whenever we see a funky object
(i.e. a proxy or an object that requires access checks) in the prototype
chain (similar to what Crankshaft already did).
Drive-by-fix: Also make Crankshaft respect the mode and therefore
address the deopt loop in Crankshaft around instanceof.
We might want to introduce an InstanceOfIC mechanism at some point and
track the map of the right-hand side.
BUG=v8:5267
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2370693002
Cr-Commit-Position: refs/heads/master@{#39718}
This matches current Crankshaft/fullcodegen behavior more closely and
thus reduces the chances that we run into unnecessary polymorphism due
to the field representation tracking in our object model.
R=jarin@chromium.org
BUG=v8:5267
Committed: 6a939714e9
Review-Url: https://codereview.chromium.org/2367593003
Cr-Commit-Position: refs/heads/master@{#39692}
Reason for revert:
Main suspect for tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/11893
Also changes layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/10036
+mips builder:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/4032
Original issue's description:
> [wasm] Master CL for Binary 0xC changes.
>
> [0xC] Convert to stack machine semantics.
> [0xC] Use section codes instead of names.
> [0xC] Add elements section decoding.
> [0xC] Decoding of globals section.
> [0xC] Decoding of memory section.
> [0xC] Decoding of imports section.
> [0xC] Decoding of exports section.
> [0xC] Decoding of data section.
> [0xC] Remove CallImport bytecode.
> [0xC] Function bodies have an implicit block.
> [0xC] Remove the bottom label from loops.
> [0xC] Add signatures to blocks.
> [0xC] Remove arities from branches.
> Add tests for init expression decoding.
> Rework compilation of import wrappers and how they are patched.
> Rework function indices in debugging.
> Fix ASM->WASM builder for stack machine.
> Reorganize asm.js foreign functions due to import indices change.
>
> R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
> BUG=chromium:575167
> LOG=Y
>
> Committed: https://crrev.com/76eb976a67273b8c03c744f64ad850b0432554b9
> Cr-Commit-Position: refs/heads/master@{#39678}
TBR=ahaas@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,rossberg@chromium.org,bradnelson@google.com,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:575167
Review-Url: https://codereview.chromium.org/2361053004
Cr-Commit-Position: refs/heads/master@{#39685}
[0xC] Convert to stack machine semantics.
[0xC] Use section codes instead of names.
[0xC] Add elements section decoding.
[0xC] Decoding of globals section.
[0xC] Decoding of memory section.
[0xC] Decoding of imports section.
[0xC] Decoding of exports section.
[0xC] Decoding of data section.
[0xC] Remove CallImport bytecode.
[0xC] Function bodies have an implicit block.
[0xC] Remove the bottom label from loops.
[0xC] Add signatures to blocks.
[0xC] Remove arities from branches.
Add tests for init expression decoding.
Rework compilation of import wrappers and how they are patched.
Rework function indices in debugging.
Fix ASM->WASM builder for stack machine.
Reorganize asm.js foreign functions due to import indices change.
R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
BUG=chromium:575167
LOG=Y
Review-Url: https://codereview.chromium.org/2345593003
Cr-Commit-Position: refs/heads/master@{#39678}
This makes sure the {EscapeAnalysisReducer} inserts proper {TypeGuard}
nodes if the replacement node is not a subtype of the original node.
This happens predominantly for code that has been made unreachable by
type checks.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-640497
BUG=chromium:640497
Review URL: https://codereview.chromium.org/2363573003 .
Cr-Commit-Position: refs/heads/master@{#39656}
This matches current Crankshaft/fullcodegen behavior more closely and
thus reduces the chances that we run into unnecessary polymorphism due
to the field representation tracking in our object model.
R=jarin@chromium.org
BUG=v8:5267
Review URL: https://codereview.chromium.org/2367593003 .
Cr-Commit-Position: refs/heads/master@{#39655}
Rename the high-level operators CheckTaggedSigned to CheckSmi and
CheckTaggedPointer to CheckHeapObject, to better match the naming
convention (i.e. ObjectIsSmi and CheckSmi, ObjectIsString and
CheckString, etc.).
For lowering CheckSmi, always report TaggedSigned representation
and let the RepresentationChanger come up with a reasonable conversion
from whatever input representation to TaggedSigned. This way we no
longer insert the useless ChangeSomethingToTagged and then Smi check
the result sequences, i.e. mostly reduces the amount of useless code
being generated. But we also observe a few performance improvements
on some crypto benchmarks.
This would enable us to avoid the Smi canonicalization when going from
Float64 to Tagged completely and thus match the representation selection
of Crankshaft in many areas (which might reduce the amount of
polymorphism until we fix our object model).
A follow-up CL will do the same for CheckHeapObject.
BUG=v8:5267
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/2362173003 .
Cr-Commit-Position: refs/heads/master@{#39654}
This CL optimizes the code in BytecodeArrayBuilder and
BytecodeArrayWriter by making the following main changes:
- Move operand scale calculation out of BytecodeArrayWriter to the
BytecodeNode constructor, where the decision on which operands are
scalable can generally be statically decided by the compiler.
- Move the maximum register calculation out of BytecodeArrayWriter
and into BytecodeRegisterOptimizer (which is the only place outside
BytecodeGenerator which updates which registers are used). This
avoids the BytecodeArrayWriter needing to know the operand types
of a node as it writes it.
- Modify EmitBytecodes to use individual push_backs rather than
building a buffer and calling insert, since this turns out to be faster.
- Initialize BytecodeArrayWriter's bytecode vector by reserving 512
bytes,
- Make common functions in Bytecodes constexpr so that they
can be statically calculated by the compiler.
- Move common functions and constructors in Bytecodes and
BytecodeNode to the header so that they can be inlined.
- Change large static switch statements in Bytecodes to const array
lookups, and move to the header to allow inlining.
I also took the opportunity to remove a number of unused helper
functions, and rework some others for consistency.
This reduces the percentage of time spent in making BytecodeArrays
in CodeLoad from ~15% to ~11% according to perf. The
CoadLoad score increase by around 2%.
BUG=v8:4280
Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64
Review-Url: https://codereview.chromium.org/2351763002
Cr-Original-Commit-Position: refs/heads/master@{#39599}
Cr-Commit-Position: refs/heads/master@{#39637}
