Most wasm fuzzers live in the v8::internal::wasm::fuzzer namespace.
Thus also move the wasm-fuzzer there. Additionally
- use the C++20 syntax for declaring the namespace,
- skip unneeded full or partial classifications on types, and
- remove a redundant HandleScope.
R=ahaas@chromium.org
Bug: v8:13496
Change-Id: I31d948af449efd9708aa6b27f35e8f3c9280a3f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030579
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84300}
StackMemory::base() returned an approximate value for the root stack.
Ensure that it returns the exact value reported by the OS, so that
conservative stack scanning can use this method to determine the bounds
of each segment in a uniform way.
R=ahaas@chromium.org,nikolaos@chromium.org
Bug: v8:13493
Change-Id: I9f267a568494a7744882d148fd65fe42f7b119af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030316
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84298}
Now that lazy compilation is shipped, we effectively overwrite the
default (true) via the weak negative implication anyway. Hence switch
the default to false to avoid confusion.
R=ahaas@chromium.org
Bug: v8:12852
Change-Id: Idd662992930db8a5df565b967a6820d662681ec6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030480
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84297}
Create RegExpTextBuilder as a separate class to handle creation of text
elements in the regular expression parser.
The main motivation is to re-use the text builder for StringDisjunctions
in unicode sets mode (to be implemented).
Bug: v8:11935
Change-Id: Ice5f035f1638bb6d9c58f62ce2a133882da736ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3967901
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84296}
The isolate root is stored on the Wasm instance but also available
directly in the root register. Save (at least) one load and use the root
register directly.
R=jkummerow@chromium.org
Bug: v8:13449
Change-Id: I7426c6d2295e443e4971eea097b849ee50bf09c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026123
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84295}
With shipping lazy compilation, we lose the test coverage for eager
compilation. This is bad, because with PGO, eager compilation may have
a comeback. With this CL we enable eager compilation in the
nooptimization test variant. This variant seems to be the best fit, as
there are no conflicts with existing flags. The --liftoff flag is not a
problem, because Liftoff was anyways the default for eager compilation.
R=clemensb@chromium.org
Bug: v8:12852
Change-Id: I002ecb2a31ad2e2335a0469fdf5e3d5bda3b33bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027004
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84294}
Refactor the API to avoid passing in a pointer to a {shared_ptr}. In the
caller it's not always obvious that this can change the object that the
{shared_ptr} points to, which again can lead to UAF bugs.
Passing in a {shared_ptr} and receiving back a potentially updated
{shared_ptr} makes this more obvious.
R=ahaas@chromium.org, thibaudm@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Change-Id: Ib209c3c223df07446f0cd4472bc3f68f3897919f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020230
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84293}
So far the callback was not registered when the module got loaded from
the code cache.
R=clemensb@chromium.org
Bug: chromium:1384530
Change-Id: I9477ad50a2642e2268bfacf97a2eacda6610b25d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027927
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84292}
Don't re-use the same mechanism for non-tagged constants as we do for
tagged ones, since then we end up with untagged values in exception
phis.
Instead, emit constants along with other non-tagged materialisations --
however, avoid unnecessarily Push/Popping them on the stack, or calling
Builtin::kNewHeapNumber, but embed them directly as tagged values in the
code.
Bug: v8:7700
Change-Id: I8db1314c274104cec292178d37fac58ef45d769f
Fixed: chromium:1385271
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030477
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84291}
Allow nodes to be considered dead as soon as they are visited during
input assignment, by updating uses immediately (rather than waiting
until all inputs are assigned). This helps the case of clobbered
registers, which now know whether they need to be saved or not.
Also, disallow using existing blocked registers when assigning clobbered
inputs, so that a clobbering input doesn't accidentally clobber a
non-clobbering one.
Bug: v8:7700
Change-Id: I9b91b66ac159f0dd20c9554a860fdbf2545c400d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020508
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84290}
EnsureTagged for Int32 and Uint32 uses NodeInfo::tagged_alternative, but
Float64 was still using the old "check next node" approach. Update this
to be inline with the others.
Bug: v8:7700
Change-Id: I682c48828753d98b740df0f6ac21ae1c6bda722c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022708
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84288}
The interesting cases are already covered by !is_conversion() and
representation checks, so all these DCHECKs give us at this point is
clusterfuzz false positives.
Bug: v8:7700
Change-Id: I5d6b194ba57da2378f5b2eb3e71f520a53d6b5da
Fixed: chromium:1384318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4028146
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84287}
I needed to do something similar in crrev/c/4024485.
Change-Id: I99c97b4bb1739fcc453659b10b378d1a04f18c8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022374
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: S Ganesh <ganesh@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84285}
Before we start unmarking, notify the stats collector about it as
otherwise it would assume that no GC is in progress and fail on a
DCHECK. In addition, fix standalone unmarking.
Bug: v8:13475
Change-Id: I028dadda60ab82b8a8769d84679d8e066f196da0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026897
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84284}
shared_space() and shared_lo_space() weren't verified so far when
using --shared-space.
Bug: v8:13267
Change-Id: Ibe956d3f506651576815b3a3d84d531019419a3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027208
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84283}
If Int64Constant[value] can be casted from an Int32Constant(value>=int32_min and value<=int32_max), we can reduce the redundant Int32ToInt64:
-------------------------------------------------
Int64LessThan(Int32ToInt64(a), Int64Constant[value])
====>
Int32LessThan(a,Int32Constant[value])
-------------------------------------------------
Otherwise, if value<int32_min:
-------------------------------------------------
Int64LessThan(Int32ToInt64(a), Int64Constant[value])
====>
# Always false
Int32Constant[0]
-------------------------------------------------
If value>int32_max:
-------------------------------------------------
Int64LessThan(Int32ToInt64(a), Int64Constant[value])
====>
# Always true
Int32Constant[1]
-------------------------------------------------
Change-Id: Id0de1dacad99d1f17b8e652472c2f4bc9ae79c15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3967835
Commit-Queue: Jianxiao Lu <jianxiao.lu@intel.com>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84281}
These tests were needed when missing features were implemented in
Liftoff, and the in-progress implementation was disabled by default.
Since the Liftoff code is enabled by default now, the test copy can be
deleted.
R=jkummerow@chromium.org
Bug: v8:12926
Change-Id: Iecdf02645a63e93a51f6ce297d168e149d68be26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027928
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84279}
Otherwise compilation could fail with this error:
```
{standard input}: Error: instruction address is not a
multiple of 4
```
Note the number parameter specifies the log base 2.
Change-Id: I2571bc5ba58e90ccc45e1c3f34da768b82d91b3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027072
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84277}
A surrogate pair split by an "always succeeding" backreference
(backreference capturing undefined, because it hasn't captured anything
yet) was incorrectly combined into a surrogate pair, resulting in
incorrect matches.
Bug: v8:13410
Change-Id: I2faf9ca5f9fcfd55cd6933a1ea038c88f8d3f524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013159
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84276}
The CL add no-op hooks into MinorMC that calls into CppHeap young gen.
The unified-young-gen is gated behind the --cppgc-young-generation flag,
which implies --minor-mc.
The CL also removes then call into standalone CppHeap::RunMinorGC().
Bug: v8:13475
Change-Id: I854efdac29642a0667ccd18451807e9bfab6777e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020435
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84275}
Since crrev.com/30c19f3292fed9c499dd5a8f852bc76a481d6368, we always
allocate the wasm_internal_functions array on WasmInstanceObject
creation. This patch initializes that array with zero bits, so we
can use a Smi check (instead of a comparison to Undefined) to check
whether a given slot has been initialized already. This makes the
code generated for `ref.func` slightly smaller and more efficient.
Bug: v8:7748
Change-Id: I9d2b8fba4dc61d27e96b6e917c77133519af43ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4028561
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84272}
Speculation during builtin inlining doesn't have associated feedback,
so failures of speculation in such inlined builtins can cause deopt
loops.
The proper way of handling this is disabling speculation for these
calls, but a workaround is to not speculate and rely on type inference
for the inlined builtins (which is mostly sufficient for the ones we
have so far).
Bug: v8:7700
Change-Id: I6d88885fb13f744013c3b68508ec34d3022914cb
Fixed: chromium:1384428
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4028238
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84270}
Unlike the default scheme the ExternalCodeCompressionScheme allows
the cage to cross 4GB boundary at a price of making decompression
slightly more complex. The former outweighs the latter because it
gives us more flexibility in allocating the code range closer to
the .text section in the process address space. At the same time
decompression of the external code field happens relatively rarely
during GC.
Bug: v8:11880
Change-Id: Ia62bedd318f88c2147534ff000ab9fad354777f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899307
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84269}
32-bit comparisons were sometimes done on 64-bit. This was an issue in
cases where the upper 32 bits contained invalid bits, such as after a
Bitcast.
Fixed: chromium:1383204
Change-Id: Ie930dd579c01297b5717da8407fd9765586306ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020422
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84268}
When optimizing wasm code with MachineOperatorReducer, the
{allow_signalling_nan} flag should be off, as all wasm floating point
operations are specified to return quiet NaN.
Change-Id: I54c0bb1dfaec645ae2031f4448de5daa6dc55301
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026063
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84267}
By moving it from a runtime function to Torque.
Bug: v8:12868
Change-Id: Iede756af683d97c720040144a4ec02872da4c453
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020425
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84266}
Invariant in the normal mode:
- If the data is invalid, we'll fail gracefully (no crash, no DCHECK
failures)
Invariant in the hard fail mode:
- If the data is invalid (in a way we can detect), a CHECK fails at the
earliest location where we detect the inconsistency
Bug: chromium:1381404
Change-Id: Icae077a5c76329018fdb759122297134ae70b897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013142
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84265}
This adds a separate test module and output expectation for Wasm GC.
This covers the new types and instructions from
https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md
Unlike the previous disassembler tests, one cannot easily create the
module bytes with WABT's `wat2wasm` from the expected text output (at
least right now), so I used Binaryen's `wasm-as` instead to generate
the module from a separate input file (not included here, because it
uses folded expressions, which the debugger doesn't.)
Change-Id: Id0205b2788fd7be5ea7696242cbe8a74a4bca892
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013265
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84264}
Apparently the server-provided information changed, so we need to
work a little harder to find the latest release.
No-Try: true
Change-Id: Idc030fb648e39039175133dc0cb052c296193b94
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023861
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84263}
... to make it independent of the pointer compression scheme used for
the main cage and for code cage.
When external code space is enabled the next pointer is encoded as
Smi values representing a diff from the current FreeSpace object
address in kObjectAlignment chunks. Terminating value is stored as 0.
Such a representation has the following properties:
a) it can hold both positive an negative diffs for full pointer
compression cage size (HeapObject address has only valuable 30 bits
while Smis have 31 bits),
b) it's independent of the pointer compression base and pointer
compression scheme used for main cage and code cage.
When external code space is not enabled the old encoding is used:
it's either 0 or tagged pointer to the next FreeSpace "object".
Bug: v8:11880
Change-Id: Ie7bcd97964c52cce178bfc49355378dded465830
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023083
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84262}
... to make it independent of the pointer compression scheme used for
the main cage and for code cage.
When external code space is enabled forwarding pointers are encoded as
Smi values representing a diff from the source or map word host object
address in kObjectAlignment chunks. Such a representation has the
following properties:
a) it can hold both positive an negative diffs for full pointer
compression cage size (HeapObject address has only valuable 30 bits
while Smis have 30 bits + 1 sign bit),
b) it's independent of the pointer compression base and pointer
compression scheme used for main cage and code cage.
When external code space is not enabled the old encoding is used:
the forwared pointer represents the address of the new object location.
Bug: v8:11880
Change-Id: I8bd302874c45fce346d30d91ffcbc9b4ef2c1353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023081
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84260}
Tests don't work when incremental marking is started before the test
is run.
Bug: v8:13267
Change-Id: I00e30ede96bfe3632ef701436395479f5ef083ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026843
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84259}
For Int32Div (and Uint32- and -Mod), Turbofan has long had the ability
to replace division-by-constant with multiplication-by-inverse. This
patch brings the same goodness to Int64Div and friends.
This benefits Wasm code that uses i64.{div,rem}_{s,u} instructions.
Fun fact: Turboshaft supports this already.
Change-Id: I4be5536dfb81fb2f1c5d812f2a289da7dc2eef30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026762
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84257}
Changes since original:
- Updated to use the returned value from CompleteMergeInForeground as
the compilation result, which is important for correctness.
- Added a test to verify the above.
- Moved the merge code into code-serializer.cc so that it can run before
FinalizeDeserialization, which makes it more consistent with
background deserialization.
Original change's description:
> Merge with cached Script after synchronous deserialization
>
> Currently, if a script is deserialized on a background thread and a
> matching Script object is found in the Isolate compilation cache, the
> new content is merged into the existing Script. This CL implements the
> same merging for the much simpler case of deserializing on the main
> thread. I expect speed changes to be minimal, because merging is only
> needed in a small minority of compilations. When needed, it usually
> takes about 10% as long as the corresponding deserialization.
>
> Bug: v8:12808
> Change-Id: Ie7a92bcb3111edf4cdab0eddeb7567979b35f437
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4010100
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#84123}
Bug: v8:12808
Change-Id: I0628a381644e79888cb3ebdd97bda270814d0e9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4014644
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84255}
I recently updated the GC's bytecode flushing logic to accept the
possibility that two SharedFunctionInfos refer to the same
BytecodeArray (see https://crrev.com/c/v8/v8/+/3916272 ). However, that
change was insufficient for baseline code flushing. This change updates
the flushing logic to also check for already decompiled bytecode held by
the baseline code.
Bug: v8:13473
Change-Id: I58694727c417d608de3f8bf26dfd765fda1ae4f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4018272
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84254}
This is a reland of commit 05a80427dc.
We skip the test for now, until we figure out how to make it fast
enough.
Original change's description:
> [wasm] Do not add too much code at once
>
> Especially on arm64 we have a rather low code space limit (128MB), so it
> can happen that a background thread generates more code in one batch
> than can be held in a single code space. This case is not implemented
> yet.
>
> This CL implements this by never batch-adding more than half of a code
> space.
>
> In order to test the implementation, we add a new flag called
> --wasm-max-code-space-size-mb which can be used to artificially lower
> the code space size limits in tests.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13436
> Change-Id: I18a3457fda724129fb1bb8c44a9815df265b6b2c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023072
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84245}
Bug: v8:13436
Change-Id: I983ef2f2cc2316172edab1f62dbde0dd4cb56fdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4025548
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84253}
We were truncating Number inputs for identity bitwise Int32 Smi ops, but
forgot to truncate Int32 ones (in particular, those with Uint32 inputs).
Bug: v8:7700
Change-Id: Ifda802d0e0030f0102201550eca05d3f0f9bd475
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4025984
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84252}
Do not post a task if --single-threaded is enabled. Instead, execute
the task synchronously.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I853125325953a750cb32984db449b3e07ccc4dce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026342
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84251}
