This is a reland of 95aa697b2f
Original change's description:
> [test][d8] Add d8.log.getAndStop helper
>
> The new helper function allows us to write tests for log parsing
> without the need to first generating a log file. This makes it easier
> to spot errors when the log format changes.
>
> - Add d8 global variable
> - Add file_name accessor to Logger and Log classes
> - Change OS::LogFileOpenMode to w+ / wb+
> - Use separate Log::WriteLogHeader method
> - Remove unused logger_ instance variable from Log
>
> Bug: v8:10644
> Change-Id: Ifc7e35aa4e91b3f01f0847843263946e085944c3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387563
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69715}
Bug: v8:10644
TBR=verwaest@chromium.org
Change-Id: I54741344834d88a376b74e2e3a2047e880a94624
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396081
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69769}
This CL migrates cppgc to use Ulan's new worklist implementation.
Since there is no central segments array anymore, we cannot rely on
getting the same view (now renamed to Local) given the same task id.
To avoid creating many short lived segments (e.g. for write barriers)
marking state now holds local views for all worklists and provides
access to them.
Bug: chromium:1056170
Change-Id: Id19fe1196b79ed251810e91074046998dc2a9177
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390771
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69767}
Follow up to 3f4f4a0: "[regexp] Handle zero-length matches in
experimental engine".
We want to assert an equivalence, not an implication in the boring
direction.
Bug: v8:10765
Change-Id: Ia7b4851feb1f5f621d687779d0cae0e28433f00e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398536
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Cr-Commit-Position: refs/heads/master@{#69764}
This reverts commit 81577a79e1.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared/10544
Original change's description:
> [serializer] Change deferring to use forward refs
>
> Now that we have forward references, we can replace the body deferring
> mechanism with forward references to the entire pointer.
>
> This ensures that objects are always deserialized with their contents
> (aside from themselves maybe holding forward refs), and as a result we
> can simplify the CanBeDeferred conditions which encode the constraint
> that some objects either need immediately have contents, or cannot be
> deferred because their fields are changed temporarily (e.g. backing
> store refs).
>
> This also means that objects with length fields (e.g. arrays) will
> always have those length fields deserialized when the object is
> deserialized, which was not the case when the body could be deferred.
> This helps us in the plan to make GC possible during deserialization.
>
> Bug: v8:10815
> Change-Id: Ib0e5399b9de6027765691e8cb47410a2ccc15485
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390643
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69760}
TBR=jgruber@chromium.org,leszeks@chromium.org
Change-Id: I7a93a59217a2b38e2157c0f7ffc7ac648590a8d6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10815
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398535
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69763}
This reverts commit 1c7618abad.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared/10544
Original change's description:
> [serializer] Remove new space
>
> The new space is unused in the snapshot, as we convert all new objects
> to old space objects when serializing. This means we can get rid of
> the snapshot new space entirely, and as a result get rid of the write
> barrier checks.
>
> This also rejiggles the order of the general spaces enum so that the new
> spaces are at the end, and can be truncated off for the SnapshotSpace
> enum.
>
> As a drive by, fix a bug in an unrelated test-api test which this patch
> exposed.
>
> Change-Id: If67ff8be5bf03104a3ffae7df707c22460bba3a1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390762
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69761}
TBR=jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org
Change-Id: Iaf2362d8cd3a17d8410030aca0dd2250c5a0a7af
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398533
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69762}
The new space is unused in the snapshot, as we convert all new objects
to old space objects when serializing. This means we can get rid of
the snapshot new space entirely, and as a result get rid of the write
barrier checks.
This also rejiggles the order of the general spaces enum so that the new
spaces are at the end, and can be truncated off for the SnapshotSpace
enum.
As a drive by, fix a bug in an unrelated test-api test which this patch
exposed.
Change-Id: If67ff8be5bf03104a3ffae7df707c22460bba3a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390762
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69761}
Now that we have forward references, we can replace the body deferring
mechanism with forward references to the entire pointer.
This ensures that objects are always deserialized with their contents
(aside from themselves maybe holding forward refs), and as a result we
can simplify the CanBeDeferred conditions which encode the constraint
that some objects either need immediately have contents, or cannot be
deferred because their fields are changed temporarily (e.g. backing
store refs).
This also means that objects with length fields (e.g. arrays) will
always have those length fields deserialized when the object is
deserialized, which was not the case when the body could be deferred.
This helps us in the plan to make GC possible during deserialization.
Bug: v8:10815
Change-Id: Ib0e5399b9de6027765691e8cb47410a2ccc15485
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390643
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69760}
Previously to this commit only quantifiers of the form /<x>*/, i.e.
arbitrarily often greedy repetition, were implemented. Now a much
larger class is supported, e.g. + and ? and their non-greedy variants.
Because it came up repeatedly during the implementation, the commit also
adds the Label and DeferredLabel classes to patch JMP and FORK target
addresses more easily.
Still not supported are the following quantifiers:
- Possessive quantifiers, where I'm not entirely sure whether they could
be implemented in principle. Re2 doesn't support them.
- Quantifiers with large but finite numbers for min and max numbers of
repetitions, as in e.g. /<x>{9000, 90000}/. These are currently
limited to some small value. This is because the body of such
repetitions is unrolled explicitly, so the size of the bytecode is
linear in the number of repetitions.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: Id04d893252588abb0f80c3cb33cfc707f6601ea0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387575
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69759}
Add in f64x2 opcodes to simd scalar lowering, this allows us to enable
most of the f64x2 test cases with quite little changes - the significant
change is to make sure the comparisons return a Int64 node.
Bug: v8:10507
Change-Id: I8c8920d37c0cd0841dafcdb0310b6340b3c16189
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2399051
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69757}
SIMD lowering can result in int64 nodes (from i64x2), and int64 nodes
won't create SIMD nodes. So run SIMD lowering first, then int64
lowering.
Bug: v8:10507
Change-Id: Id720d98eda0bcd9ab441df687f974fd84bf9118c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2393497
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69756}
v128.const was incorrectly always lowered to 4 word32 nodes, regardless
of what the lowered type was set to be.
In the test case, v128.const was consumed by i8x16.eq, so the lowered
typed of v128.const node was set to SimdType::kInt8x16, but it was still
lowered as a SimdType::kInt32x4, and then later crashes when lowering
the comparisons.
Bug: v8:10507
Change-Id: I24f16c94968cd8b6c7cd5d400d1a0046da3d47da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391919
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69755}
This reverts commit 10348e8eb6.
Reason for revert: https://crbug.com/1125951
Original change's description:
> [wasm][liftoff] Emit safepoints for externref values on the stack
>
> With this CL we emit safepoint maps for externref values on the Liftoff
> value stack. With that there is support for externref parameters and
> locals in Liftoff, as well as for intermediate values of type
> externref.
>
> R=thibaudm@chromium.org
>
> Bug: v8:7581
> Change-Id: I2df0a8d00b2da33fe06ff474b039cca4c7be726d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387571
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69725}
TBR=ahaas@chromium.org,thibaudm@chromium.org
Change-Id: I4cdf7fedfc91cd99302d5cb05e242dbb032c5803
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7581
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398529
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69754}
The original Profiler.getRuntimeCallStats implementation retrieved
a bunch of V8 Counters instead of runtime call counters. This
functionality is now available through the new APIs:
enableCounters, disableCounters and getCounters.
The getRuntimeCallStats API now retrieves real V8 Runtime Call Stats.
Change-Id: I702f60a6c43773f5c41b6861be3f9435975c370f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380853
Commit-Queue: Peter Kvitek <kvitekp@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69753}
When counting which backedges conflict with a loop-top phi value, we
should include values introduced at the start of the loop.
I don't expect this change to make performance differences on its own,
but it is a step toward changing the heuristic so that we're less likely
to introduce unnecessary load/store pairs across the backedge.
Bug: v8:10606
Change-Id: I299e388b0b964573119ba0b775d50f398c467c46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385715
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69752}
We need to also check SIMD support for v128.const and i8x16.shuffle,
these are separate functions, not part of the SimdOp or SimdLaneOp.
This was discovered while running some JS tests when trying to stage
SIMD.
Bug: v8:10835
Change-Id: I51c6e65cc9397058e0be83cf4116ab4bfe4c4ec9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391332
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69751}
Change FeedbackVector into a Torque-generated class, simplifying its
C++ implementation. As a drive-by, also get rid of the lower-cased,
integer-indexed slot accessors, and replace the calls that needed this
integer index with FeedbackSlot (potentially with a new WithOffset
adjustment for extra data slots).
Change-Id: Ie4f7e99b462ef95419edab46b4ac7ceecae9a05f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398638
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69749}
This reverts commit 9e8c54f830.
Reason for revert: Data races (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33100)
Original change's description:
> [Heap] ScavengerCollector use Jobs.
>
> No yielding is necessary since the main thread Join()s.
>
> max concurrency is determined based on either
> remaining_memory_chunks_ or global pool size
> (copied_list_ + promotion_list_)
>
> Change-Id: Ie30fa86c44d3224b04df5d79569bce126ce7d96b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354390
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69746}
TBR=ulan@chromium.org,etiennep@chromium.org
Change-Id: I206397c6086cf18d5e08cf615bdaaf0f34c6d36b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398852
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69748}
Port 10348e8eb6
Original Commit Message:
With this CL we emit safepoint maps for externref values on the Liftoff
value stack. With that there is support for externref parameters and
locals in Liftoff, as well as for intermediate values of type
externref.
R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I369c0e2e7fb1c4681101a149b01e1a9580051d45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398845
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69747}
No yielding is necessary since the main thread Join()s.
max concurrency is determined based on either
remaining_memory_chunks_ or global pool size
(copied_list_ + promotion_list_)
Change-Id: Ie30fa86c44d3224b04df5d79569bce126ce7d96b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354390
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69746}
With this CL we add support for all externref globals except for
imported mutable globals.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: I63cb26f8ad6f4b8fc1c276e223c5d45745122ebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396086
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69741}
The wasm interpreter is slow on an arm simulator build with asan when
it comes to return calls. An infinite return-call recursion therefore
caused a timeout on ClusterFuzz. With this CL we increase the costs of
return calls, and thereby avoid the timeout.
R=clemensb@chromium.org
Bug: chromium:1124899
Change-Id: If88e060779fbe2569e289e60170cf487dd31d7db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2397615
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69740}
The parameters should be processed and evaluated in an increasing order
(starting with the 1st param).
Before we started with the last (n-th) parameter which was not correct.
Bug: v8:10701, chromium:1124940
Change-Id: I8e0d8b1f0c53832c8f2d09551879c1a4413e1598
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396085
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@{#69739}
Port a2fd94f014https://crrev.com/c/2312783
Original Commit Message:
This adds the argument count (as intptr) to the standard frame.
StandardFrames are now in the same shape as OptimizedFrames.
The argument count in the stack will be used to tear down the
arguments when we remove the arguments adaptor frame.
Change-Id: I5cff9874735c1bdbd685deb0d829e57f1ee07ac2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2393323
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#69738}
It does a direct access iff the FLAG_turbo_direct_heap_access is
enabled. Otherwise, it uses the Data classes as it did before.
Bug: v8:7790
Change-Id: I4f42e5734fdb2c91dbe9ef08869aec621c9d04c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2382311
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69737}
Cast resource field in ExternalString as
v8: :String::ExternalStringResourceBase* would give us more info.
Change-Id: Iae97b477f400f58365e2381b7230d2226d490aa7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388742
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69734}
Sometimes the parser throws away redundant parts of the AST while
parsing. For example, the regexp /(?:(?=(f)o))?f/ is (almost)
equivalent to just /f/ because the optional block (...)? is zero-length.
The parser notices this and returns the same tree as for /f/. However,
there is a capture inside the (...)? block (which is never recorded
because the quantifier containing it can only match zero-width, which is
considered failure), so in this case it doesn't suffice to check that
the regexp AST doesn't contain captures.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I6145849d95b3522a397eadd2bae63d1d8e880f28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2397896
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Cr-Commit-Position: refs/heads/master@{#69733}
When the top frame is paused at a breakpoint, and this breakpoint is
being removed or was already removed, introduce a "dead breakpoint" in
the new code. This ensures that:
- The source position for the new frame is correct, otherwise it would
just pick the source position of the previous call,
- The offset between the source position and return address is the same
in the new and old code, which is necessary for OSR to find the correct
return address.
R=clemensb@chromium.org
Bug: v8:10337
Change-Id: I400886ff14846d3973d0634592c05960c05de738
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377686
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69731}
An earlier cl:
https://chromium-review.googlesource.com/c/v8/v8/+/2354810 fixed loading
double fields with dynamic map checks. The fix however didn't update the
expected type information to also expect Smi fields. So, in the later
optimization phases the CheckHeapObject operation was reduced to a NoP
since the expected type was a HeapObject. This cl fixes the bug by
updating the type to Type::Any.
Bug: chromium:1124696, v8:10582
Change-Id: Ic96dd74c97caf8eaf5289d8e8939f6feb1686a57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396088
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69730}
The GetReadOnlyRoots will need to remain on HeapObject due to pointer
compression and the Isolate overload of HashSeed is convenient.
Change-Id: Id7fa8e57e3b8bfa6f50465c24da1fc5d0b4db0bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2397889
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69729}
These flags are later packed into an InstructionCode by the
instruction selector, but not all bits are preserved. This CL adds a
few assertions and helper methods to clarify and make this a bit
safer.
Bug: v8:8888
Change-Id: I01adc9f7887cc21c623d790dc204ac1d4b9bc7ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388116
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69728}
The current implementation in AssembleSwap will generate a push-pop pair to swap between a general register and a stack slot for both x64 and ia32 targets. This is unnecessary for x64 target, as we can use the kScratchRegister to save the general register and swap with the stack slot.
Change-Id: I10e0dc360dec22cdf5afa63ece3d5943685d7ecb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2394177
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Yolanda Chen <yolanda.chen@intel.com>
Cr-Commit-Position: refs/heads/master@{#69726}
With this CL we emit safepoint maps for externref values on the Liftoff
value stack. With that there is support for externref parameters and
locals in Liftoff, as well as for intermediate values of type
externref.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: I2df0a8d00b2da33fe06ff474b039cca4c7be726d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387571
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69725}
When a WasmGCForegroundTask starts during runMessageLoopOnPause, the
stack may contain Wasm code. In this case we need to scan the stack to
report live code.
This is already caught by some tests when RemoveBreakpoint is
implemented correctly, which will be done in a separate CL, so no
regression test is added here.
R=clemensb@chromium.org
Bug: v8:10337
Change-Id: I308145b9c2cf69f0100853be47ec9e30ce79a876
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379510
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69724}
If we generate more code than allowed by the --wasm-max-code-space flag,
the {WasmCodeManager::Commit} method will fail (via fatal error). The
DCHECK that was placed before that call checked for a related condition
though, and failed before the {Commit} method could fail.
By moving it after the call, we fix this issue.
Adding a test case for this seems to be involved, since that test would
crash the whole process (because of the fatal error). So it would have
to be a unittest such that we can use ASSERT_DEATH_IF_SUPPORTED. In
unittests though we don't yet have the infrastructure to create a
NativeModule (needed for the WasmCodeAllocator). Alternatively we could
add special testing methods (and a constructor) to the
WasmCodeAllocator, but I do not consider this worth the effort for this
little fix.
R=thibaudm@chromium.org
Bug: chromium:1124646
Change-Id: Ief09dfbd0a5b0b040fe9cf8a34e458d1d01dfacc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390754
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69723}
memchr is used in the default case but for two-byte strings that contain
mostly ascii sequences every other byte is 0.
This CL special-cases the 0 byte search in a two-byte string to simply
peform a simple for loop which is rouhly 10x faster than the repeated
memchr approach.
Bug: v8:10737
Change-Id: Icde6b858b6679da69448295616734c46aa95e439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364507
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69721}
