This is a first small step for implementing the memory64 proposal:
1. Add a feature flag.
2. Add the 0x04 and 0x05 limits flag for memory64.
3. Read memory limits as LEB-encoded u64 (instead of u32) if a memory64
limit flag was read.
4. Unify {MaximumFlag} and {MemoryFlag}, which was used inconsistently
before.
5. Add test for memory limits encoded with >5 bytes.
6. Move some macros from module-decoder-unittest.cc to wasm-macro-gen.h.
Note that still the same limits for the maximum number of pages applies
as before, i.e. you cannot specify a memory >4GB yet. But you can encode
that small number in >5 bytes.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I90a4f08426ae714a67440281785eb00cfc24a349
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423712
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70110}
This fixes a case in which we forgot to assign flags to TextNodes
created through
AddBmpCharacters
AddNonBmpSurrogatePairs
AddLoneLeadSurrogates
AddLoneTrailSurrogates
functions. If these initially had a flag (e.g. case-insensitive 'i')
set, that information was lost. This bug resulted in missing case
folding in no_i18n builds (perhaps other things as well that just
aren't covered by our test suite).
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Bug: v8:10131,v8:10120
Change-Id: Icef4f0dbd47971a538e07bab2f1067c383fd59c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423718
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70106}
Benchmarks showed a large number of useless NCI compilation
tasks, i.e. code objects were generated and cached but never used.
Ideally, we'd only spawn an NCI task when the generated code will
be used in the future. To approximate this behavior, we now delay
task creation to the *second* time a function is optimized; the
thought being that a function that has been optimized twice is likely
to be optimized (= become hot) again in the future.
Bug: v8:8888
Change-Id: Ia37ae6a4c3861a611086964c20c313dda1974f14
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414032
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70103}
Load splat implementation is almost the same, except for the vector
format used for the output register. We encode this information in
MiscField (the size of each lane), and with some helper functions we can
easily reuse a single opcode for 4 load splats.
Bug: v8:10930
Change-Id: Ieed4dc7358821a0d1d7bab4add7a59d808c5aad8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422354
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70098}
Add lowering for F64x2 in S128Const and converting to and from f64x2.
Bug: v8:10507
Change-Id: Ic2c4f1f41d3dd804e012a943391a46b534864b51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424679
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70097}
For now, V128 values are converted to String16 (since they are not
serializable). It is shown as a list of 16 uint8_t (hex). This
description can be tweaked as necessary.
Some updates to ARM64 required to push/pop the full Q register.
Bug: v8:10347
Bug: chromium:1130474
Change-Id: I1bffbb49f47c06da3cd26d830addae0416a4441a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422082
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70096}
This CL fixes two things:
1) It properly creates code entries for the generic js-to-wasm builtin
(others are left out because we don't want to include all builtins in
profiles).
2) It includes js-to-wasm frames in profiles. The generic js-to-wasm
builtin will map to that frame type in the future (see referenced
bug). js-to-wasm frames are currently included because they are wrongly
mapped to OPTIMIZED frames by the SafeStackTraceIterator.
R=petermarshall@chromium.orgCC=ahaas@chromium.org, evih@google.com
Bug: v8:10701
Change-Id: I26e3fa6901890e041feab7c001069e67a616c986
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416495
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70095}
- Make Module::RecordErrorUsingPendingException and
Module::RecordError static (There is no need for them to be
"fast" instance methods with raw pointers)
- Share various debug print snippets
- Share status change code in SetStatusInternal
- Simplify several casts
Change-Id: I159dc3dd9104bf76858a2d5ad142a72a75640716
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416490
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70094}
Avoid --log-all which activates profiling timers that have issues on
certain bots. --log-code is good enough to test whether logging works.
Bug: v8:10937
Change-Id: I3284801f7b423480756abb0f3c33980a9776575d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424349
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70093}
Currently, the generic wrapper is used for i32 and i64 params and 0 or 1
i32, i64, f32, f64 return value.
Bug: v8:10701
Change-Id: I610172995457354879afd3c9c2c6c2d55c2b700f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414219
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#70090}
We currently have a pattern of setting a dereferenced Handle location to
update that Handle's value:
*handle.location() = new_value.ptr()
This is slightly opaque, and definitely not type-safe, so add a new
Handle<T>::PatchValue method which does this operation.
Ideally we would make Handle::location() return a const pointer to
discourage this sort of use, but there's a bunch of places where that
location pointer is used and passed around as a Handle surrogate, so
those would have to be updated first.
Change-Id: I157f7e2473ed1b86f7a93cae260b0932fed0ad88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424249
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70088}
Currently the kWasmInstanceOffset is computed according to the reg
a0(kWasmInstanceRegister)'s position in the frame. And according
to Builtins::Generate_WasmCompileLazy, it's the 7th gp_regs that
are pushed on to stack, so the index should be 6 other than 7.
Since the kWasmInstanceRegister will be pushed on to stack after
all parameter registers, so we can use it's index, which does not
reply on which reg kWasmInstanceRegister is, and what order the
parameter registers are pushed on to stack.
So the new index is equal to the number of all parameter registers.
Change-Id: I7a77fb052a5d68ee28dab10409462260ad491578
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2425329
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70087}
For invalid modules, the {kFinishedExportWrappers} event and the
validation error can happen in any order. Make the order deterministic
for predictable mode.
R=clemensb@chromium.org
Bug: v8:10936
Change-Id: Ib5b1e5a1a3af901a81bc37919b5aff4e5c237579
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424134
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70086}
Not needed for correctness but this avoids adding the pending object
to the on_hold worklist.
Bug: v8:10315
Change-Id: Ide910cee37a4069c71c4046c32fa9f663265775e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424137
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70085}
The m (multiline) and s (dotall) flags just needed to be marked as
allowed; the required logic was already in the regexp parser.
A regexp /<x>/ without the y (sticky) flag is equivalent to the sticky
regexp /.*?<x>/y. The interpreter now assumes that every regexp is
sticky, and the compiler appends a preamble corresponding to /.*?/
before non-sticky regexps. To reuse existing code for compiling this
preamble, the logic for each kind of quantifier is now in a separate
function and called from VisitQuantifier and for the preamble.
The commit also includes some improvements/fixes for character ranges:
- Empty character ranges/disjunctions should never match, but before
this commit they would *always* match.
- The check of the range bounds in CanBeHandledVisitor was unncessary;
without the unicode flag this can't be a range that can't be specified
in 2-byte codepoints, and once we support unicode we simply support
all codepoints.
- The capacity of the list containing the complementary intervals of a
character range is now calculated more accurately.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I71a0e07279b4e1140c0ed1651b3714200c801de9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404766
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70082}
This fixes a bug caused by StartFunction() being called for an invalid
module.
Bug: v8:7748
Change-Id: I47a3f3573355d87554b123dd1edc7c829bb43d0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423710
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70081}
This reverts commit 2bc09b8916.
Reason for revert: Skip some tests on ARM devices for now
Original change's description:
> Revert "[wasm-simd][scalar-lowering] Enable some spec tests"
>
> This reverts commit cfe9544aa6.
>
> Reason for revert: Some spec tests fail:
> https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/15933
>
> Original change's description:
> > [wasm-simd][scalar-lowering] Enable some spec tests
> >
> > These tests can now be enabled as we implemented more scalar lowering
> > support.
> >
> > Bug: v8:10507
> > Change-Id: Ida5f896300e074db079ec24720302729b0582d9d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411774
> > Reviewed-by: Bill Budge <bbudge@chromium.org>
> > Commit-Queue: Zhi An Ng <zhin@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70006}
>
> TBR=bbudge@chromium.org,zhin@chromium.org
>
> Change-Id: Idb2da40178860f045ffab9ab5b2c8b1f2ebafcf6
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:10507
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419036
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70010}
TBR=bbudge@chromium.org,zhin@chromium.org
# Not skipping CQ checks because this is a reland.
Bug: v8:10507
Change-Id: Ifaf15c49ece65cfeaef83b0ace6cfbb804e93a4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419039
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70078}
This is a reland of 21bb43cc6a
The build failures seems to be an infra flake.
Original change's description:
> [log][d8] Only use d8.log.getAndStop on temporary log file
>
> We run tests in parallel which can cause multiple tests to write to
> the shared v8.log file. This obviously breaks the simple assertions in
> mjsunit/tools/log.js.
>
> - Use temporary files for log testing with --logfile='+'
>
> - Change the symbol from '&' to '+' for using temporary files for
> logging with --logfile
>
> - Enable skipped log tests again.
>
> Bug: v8:10937, chromium:1129854, chromium:1130196
> Change-Id: I607dc9a9ecc352e58525cdd21c1c93efebf0f09f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421826
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70071}
Bug: v8:10937
Bug: chromium:1129854
Bug: chromium:1130196
Change-Id: I2ccf7528f35057ef668aa211142e0f1073fc1fc3
Tbr: verwaest@chromium.org, victorgomes@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424257
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70076}
Ensure that events are triggered when a module is decoded, compiled,
instantiated and tiered-up.
This is a reland of I9dc87957fc03023c5ab1c4f49e865957c8324e1a.
R=clemensb@chromium.org
Bug: chromium:1092417
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: Ib5883a338c3756c6f3488fbdd7b6861ecc2ba218
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367866
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70074}
This reverts commit 21bb43cc6a.
Reason for revert: See broken build: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20builder/49882
Original change's description:
> [log][d8] Only use d8.log.getAndStop on temporary log file
>
> We run tests in parallel which can cause multiple tests to write to
> the shared v8.log file. This obviously breaks the simple assertions in
> mjsunit/tools/log.js.
>
> - Use temporary files for log testing with --logfile='+'
>
> - Change the symbol from '&' to '+' for using temporary files for
> logging with --logfile
>
> - Enable skipped log tests again.
>
> Bug: v8:10937, chromium:1129854, chromium:1130196
> Change-Id: I607dc9a9ecc352e58525cdd21c1c93efebf0f09f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421826
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70071}
TBR=cbruni@chromium.org,verwaest@chromium.org,victorgomes@chromium.org
Change-Id: I5de61792c283139b2a898334e28e1f7b2d7c08f8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10937
Bug: chromium:1129854
Bug: chromium:1130196
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424625
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70072}
We run tests in parallel which can cause multiple tests to write to
the shared v8.log file. This obviously breaks the simple assertions in
mjsunit/tools/log.js.
- Use temporary files for log testing with --logfile='+'
- Change the symbol from '&' to '+' for using temporary files for
logging with --logfile
- Enable skipped log tests again.
Bug: v8:10937, chromium:1129854, chromium:1130196
Change-Id: I607dc9a9ecc352e58525cdd21c1c93efebf0f09f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421826
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70071}
This CL extends fast-path transformations of JavaScript parameters
when calling an exported WebAssembly function from JavaScript
to support types kF32 and kF64.
Bug: v8:10943
Change-Id: I730a04c426614460777cad7c6552533868cd902e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424263
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Vicky Kontoura <vkont@google.com>
Cr-Commit-Position: refs/heads/master@{#70070}
Load and zero extend is still in prototype phase [0], implementing for ARM64 in
order to get more benchmark results.
[0] https://github.com/WebAssembly/simd/pull/237
Bug: v8:10713
Change-Id: I7d632324e4bdb0934ab024911201a06b19a1a83d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416407
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70069}
This reverts commit 64caf2b0b2.
Reason for revert: Seems to be causing a failure:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
Original change's description:
> [torque] refactor: use -tq only in filenames derived from .tq files
>
> This is to establish a naming rule for Torque-generated files:
> - If the file is called foo/bar-tq..., then it is derived from a
> file foo/bar.tq
> - Otherwise it doesn't belong to a specific .tq file.
>
> So far, we attached -tq to all Torque-generated file names, where it
> sometimes corresponded to a .tq file name and sometimes not.
> It is not necessary to add -tq to file names to indicate that they are
> Torque-generated, since they are already in a directory called
> torque-generated, and we always refer to them as
> "torque-generated/filename", so there is no confusion even though some
> files now have the same name as a corresponding hand-written file, for
> example factory.cc.
>
> TBR: hpayer@chromium.org
> Bug: v8:7793
> Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70060}
TBR=jgruber@chromium.org,tebbi@chromium.org
Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70065}
Using associative property of addition: (x + A) + B => x + (A + B).
Note: A and B need to have the same sign and we need to check that
(x + A) isn't used anywhere else.
20% perf improvement of the following function.
function f(n) {
var c = 0;
for (var i = 0; i < n; i++) {
c = c + 2 + 3;
}
return c;
}
for n = 10_000_000.
Before: 7.31s.
After: 6.05s.
Bug: v8:10305
Change-Id: If45d1cad6128a9a25cb9f43a4828ae28d594a84b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2365221
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70064}
We are hitting some limits in number of opcodes on ARM64. Try to reduce
it by merging AnyTrue opcodes (from 4 to 1) since the codegen is
identical.
Bug: v8:10930
Change-Id: Ib0bcedbd24d122a4da1ffcb29c1e4b5656fa6ac2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422087
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70063}
The detach CHECK is currently crashing on a non-TypedArray and non-Array
input source to TypedArray#set that detaches the destination TypedArray
in its length getter.
Bug: v8:10885
Change-Id: I80bcb4ffb4e4122afbff5c412623c008dc9509df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419655
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70062}
Strange things happen if we add too many opcodes such that we exceed the
number of bits ArchOpcodeField has, and in some arch (ARM64), we are
only one away from requiring 10 bits (at 0x1ff) now.
Bug: v8:10930
Change-Id: I8dc6b7e0822291f2403db4e4e1dfaf90b9416a8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422843
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70061}
