Previously we had the debugger / inspector support declared in
debug-interface.h, but the implementation was sprinkled all across
api.cc, which was quite messy. This moves the relevant macros and
other bits into api-macros.h (with api-macros-undef.h to support
jumbo builds), and moves the debugger interface implementation to
src/debug/debug-interface.cc.
Bug: chromium:1162229
Change-Id: If2698cba7bcc0b54b0f889220588ec214405848b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656256
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72402}
This is a reland of a80d51d488
There were two main issues:
- Liftoff did 32 bit addition to get the offset, which overflowed and
created a valid address where an OOB was expected
- The access mode and landing pad was missing for SIMD load and store
instructions
Also fixed the macros to disable trap handlers from simulator builds.
Original change's description:
> [wasm][mac][arm64] Enable OOB trap handler
>
> R=ahaas@chromium.org,mark@chromium.org,mseaborn@chromium.org
>
> Bug: v8:11098
> Change-Id: Ic4eb02a96805e49da71f301269567a6e0ac1b843
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519555
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72136}
Bug: v8:11098
Change-Id: I2ebe434577f2cbe168f0bccf2936f69ca211e3c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637223
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72401}
Needed since default manifest assignment will be put into the test() template in https://chromium-review.googlesource.com/c/chromium/src/+/2596114
Bug: chromium:1132878
Change-Id: I2475280c590f67cc88bcf6e877cab347079d734c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650765
Commit-Queue: Wez <wez@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Chong Gu <chonggu@google.com>
Cr-Commit-Position: refs/heads/master@{#72398}
This reverts commit 1b4811f716.
Reason for revert: makes "git cl upload" fail (the change related to files_to_skip)
Original change's description:
> [debug][api] Move debugger support to debug-interface.cc.
>
> Previously we had the debugger / inspector support declared in
> debug-interface.h, but the implementation was sprinkled all across
> api.cc, which was quite messy. This moves the relevant macros and
> other bits into api-macros.h (with api-macros-undef.h to support
> jumbo builds), and moves the debugger interface implementation to
> src/debug/debug-interface.cc.
>
> Bug: chromium:1162229
> Change-Id: I6965ebf2301459c89e3217bd87396ec353d814e9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653154
> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72392}
TBR=yangguo@chromium.org,bmeurer@chromium.org
Change-Id: Ib9460709df799cd63b221f9f30dc33dff53075bd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1162229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655508
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72393}
Previously we had the debugger / inspector support declared in
debug-interface.h, but the implementation was sprinkled all across
api.cc, which was quite messy. This moves the relevant macros and
other bits into api-macros.h (with api-macros-undef.h to support
jumbo builds), and moves the debugger interface implementation to
src/debug/debug-interface.cc.
Bug: chromium:1162229
Change-Id: I6965ebf2301459c89e3217bd87396ec353d814e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653154
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72392}
(Initially copied from nicohartmann@ CL
https://chromium-review.googlesource.com/c/v8/v8/+/2135631)
This CL adds a new intrinsic %ObserveNode(expr) which has noop semantics
but triggers the new NodeObserver set on the OptimizedCompilationInfo
when the node generated for expr is created or changed in any phase
(until EffectControlLinearization).
This provides the infrastructure to write reasonable unit tests that
check for the construction of or lowering to specific nodes (e.g.
depending on feedback).
When %ObserveNode(expr) is used an object of class ObserveNodeManager is
registered to every Reducer/GraphReducer and is notified by the Reducer
with all node changes. The same logic is added to classes
SimplifiedLowering/RepresentationSelector, which do not inherit from
class Reducer.
Observed Node modifications currently are:
* The Node Operator
* The Node type
* Node replacements
A first use case (cctest/test-sloppy-equality.cc) is included in this CL.
Change-Id: Idc5a5e38af8b1d9a2ec5021bf821c4e4e1406220
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555219
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72331}
Due to some unusual build failures on some trybots,
v8_generate_external_defines_header was reverted to false. This turns it
back on but changes the behaviour so that defines are added to the
command line as well as to the header. Because the generated header
checks that flags that should be unset are actually unset and flags that
should be set are either unset or set to 1, this will cause build
failures on many types of mismatches, although it will not detect where a
flag is not set on the command line when it is set by the header.
If no further failures show up with this, the hybrid part can be removed
and the v8-gn.h header can stand on its own.
Bug: v8:11292, v8:11341
Change-Id: I1deeeebec58f79607e68a28f808649e884810923
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649041
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72327}
For now, that flag only avoid the installation of the 'WebAssembly'
global. Follow-up CLs will remove unneeded code from the binary if the gn
arg is not set to true.
R=ecmziegler@chromium.org, machenbach@chromium.org
Bug: v8:11238, v8:11344
Change-Id: Ie95b608ed12b0476470cb552138e369f863d249b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2646833
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72296}
The final CL of this chain, this extracts translation opcodes into the
TranslationOpcode class, and merges logic for TranslationArray
creation into TranslationArrayBuilder.
Drive-by: Pull TranslationArray printing logic into
translation-state.cc.
Bug: v8:11332
Change-Id: Ia4bbb6cdd15ea3318dfb9b7edb6eb881530dda54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642254
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72278}
Users of padded objects must know the actual object size for
implementing custom finalizers.
Bug: chromium:1056170
Change-Id: I0ddf9066cfece0a8d18a9e6fd985d09449eea92a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644941
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72269}
This CL introduces cppgc::HistogramRecorder api which is similar to the
v8::metrics::Recorder api and is used by cppgc to report histogram
samples to embedders. Embedders should implement the api if they want to
collect histograms and provide an instance of it on heap creation.
CppHeap uses an adaptor class that implements the HistogramRecorder api
and is used to forward the relevant info to the relevant
v8::metrics::Recorder.
The api used 3 data structures: 2 for incremental steps that need to be
reported as they come (marking and sweeping) and 1 for the end of a GC
cycle that aggregates statistics over the entire cycle.
The data structure only provide the "raw" samples (e.g. atomic mark
time, incremental mark time, etc...). The embedder is expected to
compute aggregate histogram on its own (e.g. overall marking time).
Bug: chromium:1056170
Change-Id: If63ef50a29a21594f654edb83084598980d221ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642258
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72256}
This reverts commit 6ada6a90ee.
Reason for revert: Revert for link issue:
https://bugs.chromium.org/p/v8/issues/detail?id=11335
Original change's description:
> Reland "Faster JS-to-Wasm calls"
>
> This is a reland of 860fcb1bd2
>
> - Disabled the tests for this feature in V8-lite mode (the original
> change broke V8-lite tests)
> - Also modified test console-profile-wasm.js that was brittle with this
> change because it assumed that there was always a JS-to-Wasm wrapper
> but this is not the case when the TurboFan compilation completes before
> the Liftoff-compiled code starts to run.
>
> More changes in Patchset 8:
>
> - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
> into a new phase, wasm-inlining that reuses the JSInliner reducer.
> The doc
> https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
> describes the new logic.
>
> - Fixed a couple of small issues in wasm_compiler.cc to make sure that
> the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
> this should solve the problem we had inlining the calls in functions
> that can throw exception.
>
>
> Original change's description:
> > Faster JS-to-Wasm calls
> >
> > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
> >
> > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> > the basis of the signature of a Wasm function to call, and whose task
> > is to:
> > - set "thread_in_wasm_flag" to true
> > - convert the arguments from tagged types into Wasm native types
> > - calculate the address of the Wasm function to call and call it
> > - convert back the result from Wasm native types into tagged types
> > - reset "thread_in_wasm_flag" to false.
> >
> > This CL tries to improve the performance of JS-to-Wasm calls by
> > inlining the code of the JS-to-Wasm wrappers in the call site.
> >
> > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> > this kind of calls. A 'JSWasmCall' node is associated to
> > WasmCallParameters, which contain information about the signature of
> > the Wasm function to call.
> >
> > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
> > of the Wasm function, when the conversion is not necessary.
> > The actual inlining of the graph generated for this wrapper happens in
> > the simplified-lowering phase.
> >
> > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> > lazy deoptimizations that can happen if the Wasm function callee calls
> > back some JS code that invalidates the compiled JS caller function.
> >
> > Bug: v8:11092
> > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> > Cr-Commit-Position: refs/heads/master@{#71824}
>
> Bug: v8:11092
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
> Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72147}
Tbr: ahaas@chromium.org, jgruber@chromium.org
Bug: v8:11092, v8:11335
Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72253}
deoptimized-frame-info: Used only by the debugger.
translated-state: Combines translations and current frame states to
describe in- and output frames.
translation-array: Utils for accessing the on-heap TranslationArray
object.
Bug: v8:11332
Change-Id: I86757bed370d6d9e493862eb24a9e92533f80933
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640414
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72229}
This CL keep the Deoptimizer class in deoptimizer.{h,cc} and moves
everything else into translations.{h,cc}. Translations may be further
split up in follow-up work.
Drive-by: Remove dead code and clean up includes.
Bug: v8:11332
Change-Id: If774399843da1322c01e03d71c97b10fc88e45cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639955
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72228}
This is a reland of d1da9694d4
Relanding now that fixes for perfetto and cppgc are in:
https://chromium-review.googlesource.com/c/v8/v8/+/2640458https://chromium-review.googlesource.com/c/v8/v8/+/2640480
Original change's description:
> [build] Enable external flag header by default
>
> Turns on v8_generate_external_defines_header.
>
> Bug: v8:11292
> Change-Id: I4b1d9b47390b560b7cbf677948310694d8b03367
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610966
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Auto-Submit: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72201}
Bug: v8:11292
Change-Id: Ia47eeb6c45f4cc3db72c10782d677b69506fa3d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642249
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72226}
This is a reland of 1694925c72
Minor fix to linkage for constexpr.
TBR=ahaas@chromium.org,neis@chromium.org
Original change's description:
> Reland "[compiler][wasm] Align Frame slots to value size"
>
> This is a reland of cddaf66c37
>
> Original change's description:
> > [compiler][wasm] Align Frame slots to value size
> >
> > - Adds an AlignedSlotAllocator class and tests, to unify slot
> > allocation. This attempts to use alignment holes for smaller
> > values.
> > - Reworks Frame to use the new allocator for stack slots.
> > - Reworks LinkageAllocator to use the new allocator for stack
> > slots and for ARMv7 FP register aliasing.
> > - Fixes the RegisterAllocator to align spill slots.
> > - Fixes InstructionSelector to align spill slots.
> >
> > Bug: v8:9198
> >
> > Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#71644}
>
> Bug: v8:9198
> Change-Id: Ib91fa6746370c38496706341e12d05c7bf999389
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633390
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72195}
Bug: v8:9198
Change-Id: I91e02b823af8ec925dacf075388fb22e3eeb3384
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640890
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72209}
This reverts commit 1694925c72.
Reason for revert: Link error in CFI release build: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Clusterfuzz%20Linux64%20CFI%20-%20release%20builder/19756/overview
Original change's description:
> Reland "[compiler][wasm] Align Frame slots to value size"
>
> This is a reland of cddaf66c37
>
> Original change's description:
> > [compiler][wasm] Align Frame slots to value size
> >
> > - Adds an AlignedSlotAllocator class and tests, to unify slot
> > allocation. This attempts to use alignment holes for smaller
> > values.
> > - Reworks Frame to use the new allocator for stack slots.
> > - Reworks LinkageAllocator to use the new allocator for stack
> > slots and for ARMv7 FP register aliasing.
> > - Fixes the RegisterAllocator to align spill slots.
> > - Fixes InstructionSelector to align spill slots.
> >
> > Bug: v8:9198
> >
> > Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#71644}
>
> Bug: v8:9198
> Change-Id: Ib91fa6746370c38496706341e12d05c7bf999389
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633390
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72195}
TBR=bbudge@chromium.org,neis@chromium.org,ahaas@chromium.org
Change-Id: Ic94763925195c3a3552930e61a0eb0b7f0c0c756
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9198
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640474
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72197}
This is a reland of cddaf66c37
Original change's description:
> [compiler][wasm] Align Frame slots to value size
>
> - Adds an AlignedSlotAllocator class and tests, to unify slot
> allocation. This attempts to use alignment holes for smaller
> values.
> - Reworks Frame to use the new allocator for stack slots.
> - Reworks LinkageAllocator to use the new allocator for stack
> slots and for ARMv7 FP register aliasing.
> - Fixes the RegisterAllocator to align spill slots.
> - Fixes InstructionSelector to align spill slots.
>
> Bug: v8:9198
>
> Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71644}
Bug: v8:9198
Change-Id: Ib91fa6746370c38496706341e12d05c7bf999389
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633390
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72195}
This change adds Torque field definitions for ScopeInfo and begins to
use the Torque-generated accessors in some places. It does not change
the in-memory layout of ScopeInfo.
Torque compiler changes:
- Fix an issue where the parser created constexpr types for classes
based on the class name rather than the `generates` clause. This meant
that generated accessors referred to the imaginary type HashTable
rather than the real C++ type FixedArray.
- Don't pass Isolate* through the generated runtime functions that
implement Torque macros. Maybe we'll need it eventually, but we don't
right now and it complicates a lot of things.
- Don't emit `kSomeFieldOffset` if some_field has an unknown offset.
Instead, emit a member function `SomeFieldOffset()` which fetches the
slice for some_field and returns its offset.
- Emit an `AllocatedSize()` member function for classes which have
complex length expressions. It fetches the slice for the last field
and performs the multiply&add to compute the total object size.
- Emit field accessors for fields with complex length expressions, using
the new offset functions.
- Fix a few minor bugs where Torque can write uncompilable code.
With this change, most code still treats ScopeInfo like a FixedArray, so
I would like to follow up with some additional changes:
1. Generate a GC visitor for ScopeInfo and use it
2. Generate accessors for struct-typed fields (indexed or otherwise),
and use them
3. Get rid of the FixedArray-style get and set accessors; use
TaggedField::load and similar instead
4. Inherit from HeapObject rather than FixedArrayBase to remove the
unnecessary `length` field
After that, there will only be one ugly part left: initialization. I
think it's possible to generate a factory function that takes a bunch of
iterator parameters and returns a fully-formed, verifiably correct
ScopeInfo instance, but doing so is more complicated than the four
mostly-mechanical changes listed above.
Bug: v8:7793
Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72187}
Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI
Modify that C++ backend so that it can emit either runtime C++ or
postmortem debugging code. When in postmortem debugging mode, the
overall code structure would look similar with some difference:
1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor.
2. Instead of runtime class names like String, we use uintptr_t
3. When loading data from objects, instead of TaggedField<T>::load or
Object::ReadField (which read from the current process), we use the
MemoryAccessor and read data from the debuggee process.
4. Return values should be wrapped in the Value struct.
Implement the debug accessors for complex length expressions and add
test for such class (SmallOrderedHashSet).
Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72148}
This is a reland of 860fcb1bd2
- Disabled the tests for this feature in V8-lite mode (the original
change broke V8-lite tests)
- Also modified test console-profile-wasm.js that was brittle with this
change because it assumed that there was always a JS-to-Wasm wrapper
but this is not the case when the TurboFan compilation completes before
the Liftoff-compiled code starts to run.
More changes in Patchset 8:
- Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
into a new phase, wasm-inlining that reuses the JSInliner reducer.
The doc
https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
describes the new logic.
- Fixed a couple of small issues in wasm_compiler.cc to make sure that
the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
this should solve the problem we had inlining the calls in functions
that can throw exception.
Original change's description:
> Faster JS-to-Wasm calls
>
> This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
>
> Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> the basis of the signature of a Wasm function to call, and whose task
> is to:
> - set "thread_in_wasm_flag" to true
> - convert the arguments from tagged types into Wasm native types
> - calculate the address of the Wasm function to call and call it
> - convert back the result from Wasm native types into tagged types
> - reset "thread_in_wasm_flag" to false.
>
> This CL tries to improve the performance of JS-to-Wasm calls by
> inlining the code of the JS-to-Wasm wrappers in the call site.
>
> It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> this kind of calls. A 'JSWasmCall' node is associated to
> WasmCallParameters, which contain information about the signature of
> the Wasm function to call.
>
> WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
> of the Wasm function, when the conversion is not necessary.
> The actual inlining of the graph generated for this wrapper happens in
> the simplified-lowering phase.
>
> A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> lazy deoptimizations that can happen if the Wasm function callee calls
> back some JS code that invalidates the compiled JS caller function.
>
> Bug: v8:11092
> Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#71824}
Bug: v8:11092
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72147}
Adds a v8-gn.h file containing defines that are used in the
externally-visible headers files like v8.h. This must be included by
include/v8config.h which includes it if the GN flag
v8_generate_external_defines_header is on. (Currently off by default).
To enable the v8config.h file to be included without the other v8
headers (as required by cppgc), this moves it into its own header set
which sets up the include path correctly.
Also updates some headers to ensure v8config.h is included before using
externally-visible defines.
Bug: v8:11292
Change-Id: I5be634f4adfbef144bf684071461d64f1cb30899
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608212
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72140}
Removes:
- v8_disable_arguments_adaptor GN flag
- ArgumentsAdaptorTrampoline
- ArgumentsAdaptorFrame class
Change-Id: I382ebe6c25c3c172bee5df3e86e762fca10fa392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622911
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72133}
If V8 is running in a context where Perfetto hasn't been initialized
(e.g., as part of mksnapshot), don't try to initialize track events
either.
Since perfetto::Tracing::IsInitialized() was only added recently, we
also roll Perfetto to the latest revision. This also requires updating
the proto_library GN template together with the underlying libprotobuf
dependency.
Bug: chromium:1006541
Change-Id: Icec626b7ed78264a81f1a80d73d60be3bde0d908
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632590
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72130}
This means that targets like pdfium don't have to manually set up the
include dir.
Bug: v8:11292
Change-Id: Idde914592a86f2f5a3fc5cf97060d5650467cc7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629280
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72093}
The wrappers target currently only has one header. Marking it as source
set created trouble on Windows and Mac builders.
Bug: v8:11303
Change-Id: I228d49c4150eb089e8494555886072b237b95940
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626855
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: John Xu <johnx@google.com>
Cr-Commit-Position: refs/heads/master@{#72089}
Previously the implementation of the scope iterator objects and the
debug proxy lived in src/wasm, and they are now being moved to
src/debug, to better align with the JavaScript debugging interface,
which also lives in src/debug.
Bug: chromium:1162229, chromium:1071432
Change-Id: I7f89ced88a1231ad6a923be6e85a93f1876a2024
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621084
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72007}
V8_USE_PERFETTO appears in used in the include directory so should be in
v8_header_features rather than features. Moving it means that all users
of the v8 headers will automatically get the define without having to
define it themselves.
Bug: chromium:1006541
Change-Id: I7eb67787fb42499d29c98a76a19a4ad8c04f7aa7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621083
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@{#72004}
Similar to V8, we provide the include/ headers through a "base" target.
Without this change, `gn check` complains about including cppgc headers
in Blink.
Bug: chromium:1056170
Change-Id: I09ad943cdfedae8c83ab7f957efba796637b8d48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617087
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71979}
Design doc:
https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U
A lot has changed since the last patchset! I recommend revisiting this
design doc and reading the parts in green. I explain the roadmap for
what changes to expect from ETW instrumentation as well as the
instrumentation of this particular CL.
I'll do my best to answer any further questions anyone has about my
particular instrumentation or ETW in general :)
---
This is the first of a series of changelists to round out ETW
instrumentation for V8.
This changelist represents the most minimal change needed to instrument
ETW in V8. In particular, it:
- defines and registers the ETW provider,
- interacts minimally with the rest of V8, by hooking into the
existing TracingController::AddTraceEvent function,
- is designed with a platform-agnostic layer, so that event tracers
for other platforms can be instrumented in teh future.
Some notes on instrumentation (aka I copied stuff from the design doc):
We make heavy use of the TraceLogging API to log events. It differs from
previous methods of emitting ETW events in that it doesn<E2><80><99>t
require the overhead of a separate manifest file to keep track of
metadata; rather, events using this API are self-descriptive.
Here are the five major steps to instrument the TraceLogging API:
- Forward declare the provider (from provider-win.h)
- Define the provider in a .cc file (from provider-win.cc)
- Register the provider (called from v8.cc).
- Write events (called from libplatform/tracing-controller.cc)
- Unregister the provider (called from v8.cc)
At the base, we have an abstract provider class that encapsulates the
functionality of an event provider. These are things like registering
and unregistering the provider, and the actual event-logging.
The provider class is split into provider-win and provider-mac
(currently not instantiated) classes, with OS-dependent implementations
of the above functions.
In particular, the TraceLogging API is used only in provider-win. It is
here that we forward declare and define the provider, as well as write
ETW events.
Finally, there is a v8-provider class that serves as a top-level API and
is exposed to the rest of V8. It acts as a wrapper for the
platform-specific providers.
The .wprp file is needed so that Windows Performance Recorder knows how
to capture our events.
Some considerations:
- Is TracingController::AddTraceEvent the best place from which to
write my events?
- Is src/libplatform/tracing the best place to put my instrumentation?
- Right now, I fail the preupload because of this, which tells me my
files are probably not in the best location:
You added one or more #includes that violate checkdeps rules.
src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h"
Because of "-src/libplatform" from src's include_rules.
Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf
Bug: v8:11043
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Sara Tang <sartang@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71918}
With https://crrev.com/c/2087396 we introduced a new CDP method
`Debugger.executeWasmEvaluator()`, which we originally intended
to use as the foundation for Debug-Evaluate on Wasm frames.
However in the process of prototyping we learned that it is too
costly and too inefficient to use WebAssembly modules here, and
we switched to regular Debug-Evaluate with JavaScript instead
(with a special debug proxy exposed that allows JavaScript to
peak into the Wasm frame), since JavaScript is better suited
for short-lived / short-running snippets and we don't need
clang and wasm-ld then to generate these snippets.
The JavaScript exposed debug proxy (as described in [1]) not
only enables more powerful and flexible Debug-Evaluate for the
DWARF C/C++ extension, but also serves as the basis for various
aspects of the Basic Wasm Developer Experience.
In order to pay down technical debt and to keep the maintenance
overhead low, we should remove the initial prototype now, also
to ensure that we don't accidentally attract other users of CDP
to rely on this unsupported API (despite it being marked as
"experimental").
[1]: https://docs.google.com/document/d/1VZOJrU2VsqOZe3IUzbwQWQQSZwgGySsm5119Ust1gUA
Fixed: chromium:1162062
Bug: chromium:1020120, chromium:1068571, chromium:1127914
Change-Id: I6dba8c906a8675ce6c29a52e3c32bb6626a27247
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605186
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71882}
This CL changes SharedFunctionInfo::GetBytecodeArray to a function
template, which is specialized for Isolate and LocalIsolate arguments.
This allows main thread only uses to avoid taking a lock.
Bug: v8:7790, chromium:1154603
Change-Id: I3462c4e36b66073e09393c01c765dd8a018a98f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595307
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71833}
This reverts commit 860fcb1bd2.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/13831/overview
Original change's description:
> Faster JS-to-Wasm calls
>
> This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
>
> Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> the basis of the signature of a Wasm function to call, and whose task
> is to:
> - set "thread_in_wasm_flag" to true
> - convert the arguments from tagged types into Wasm native types
> - calculate the address of the Wasm function to call and call it
> - convert back the result from Wasm native types into tagged types
> - reset "thread_in_wasm_flag" to false.
>
> This CL tries to improve the performance of JS-to-Wasm calls by
> inlining the code of the JS-to-Wasm wrappers in the call site.
>
> It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> this kind of calls. A 'JSWasmCall' node is associated to
> WasmCallParameters, which contain information about the signature of
> the Wasm function to call.
>
> WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
> of the Wasm function, when the conversion is not necessary.
> The actual inlining of the graph generated for this wrapper happens in
> the simplified-lowering phase.
>
> A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> lazy deoptimizations that can happen if the Wasm function callee calls
> back some JS code that invalidates the compiled JS caller function.
>
> Bug: v8:11092
> Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#71824}
TBR=neis@chromium.org,ahaas@chromium.org,jgruber@chromium.org,tebbi@chromium.org,ishell@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org,paolosev@microsoft.com
Change-Id: I214cbdee74c1a2aaad907ffc84662ed25631983e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11092
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595438
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71825}
This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
the basis of the signature of a Wasm function to call, and whose task
is to:
- set "thread_in_wasm_flag" to true
- convert the arguments from tagged types into Wasm native types
- calculate the address of the Wasm function to call and call it
- convert back the result from Wasm native types into tagged types
- reset "thread_in_wasm_flag" to false.
This CL tries to improve the performance of JS-to-Wasm calls by
inlining the code of the JS-to-Wasm wrappers in the call site.
It introduces a new IR operand, JSWasmCall, which replaces JSCall for
this kind of calls. A 'JSWasmCall' node is associated to
WasmCallParameters, which contain information about the signature of
the Wasm function to call.
WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
of the Wasm function, when the conversion is not necessary.
The actual inlining of the graph generated for this wrapper happens in
the simplified-lowering phase.
A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
lazy deoptimizations that can happen if the Wasm function callee calls
back some JS code that invalidates the compiled JS caller function.
Bug: v8:11092
Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71824}
This reverts commit cddaf66c37.
Reason for revert: Multiple fuzzer failures
TBR=neis@chromium.org,ahaas@chromium.org
Original change's description:
> [compiler][wasm] Align Frame slots to value size
>
> - Adds an AlignedSlotAllocator class and tests, to unify slot
> allocation. This attempts to use alignment holes for smaller
> values.
> - Reworks Frame to use the new allocator for stack slots.
> - Reworks LinkageAllocator to use the new allocator for stack
> slots and for ARMv7 FP register aliasing.
> - Fixes the RegisterAllocator to align spill slots.
> - Fixes InstructionSelector to align spill slots.
>
> Bug: v8:9198
>
> Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71644}
TBR=bbudge@chromium.org,neis@chromium.org,ahaas@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9198
Change-Id: Ib26d016df6f30f333d30b5ac14eed9630bba8252
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584200
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71703}
Currently, all runtime C++ code generated for Torque macros all goes
into a single .cc file and corresponding header. This is simple, but
limits how we can use that generated code. For example, field accessors
are generally expected to be inlinable at compilation time (not relying
on LTO).
This change updates the Torque compiler to output runtime C++ code into
the same *-tq-inl.inc files that contain implementations of member
functions for generated classes. All Torque macros transitively called
from the top-level macros are included in the same file, to avoid any
need for these generated files to #include each other. These macros are
emitted within per-file namespaces to avoid multiple-definition build
failures.
Bug: v8:7793
Change-Id: Ic9ac3748c5020a05304773a66d7249efdc56b080
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565067
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71664}
This is a reland of 064ee3c835
Issue 1: WasmEngine UAF when CompilationState is destroyed
asynchronously
Fix: Include https://chromium-review.googlesource.com/c/v8/v8/+/2565508
in this CL. Use OperationBarrier to keep WasmEngine alive.
Issue 2: In gin, JobTask lifetime is not extended beyond
JobHandle, thus making CancelAndDetach unusable.
This is fixed in chromium here:
https://chromium-review.googlesource.com/c/chromium/src/+/2566724
Original change's description:
> Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."
>
> Reason for revert: Data race:
> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
>
> It was assume that MockPlatform runs everything on 1 thread. However,
> MockPlatform::PostJob previously would schedule the job through
> TestPlatform, which eventually posts concurrent tasks, thus causing
> data race.
> Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
> ensures the jobs also run sequentially.
>
> Additional change:
> - CancelAndDetach is now called in ~CompilationStateImpl() to make sure
> it's called in sequence with ScheduleCompileJobForNewUnits
>
> Original CL description:
> To avoid keeping around a list of job handles, CancelAndDetach() is
> used in CancelCompilation. Dependency on WasmEngine is handled by a
> barrier that waits on all jobs to finish.
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Original-Commit-Position: refs/heads/master@{#71074}
> Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71459}
TBR=ulan@chromium.org
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: I6175092c97fea0d5f63a97af232e2d54cccea535
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569360
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71662}
Some wasm interpreter tests are failing since instructions generated
by gcc such as *multiply and and* (fmadds) create intermediate
results bigger than 8 bytes which doesn't match other architectures,
hence the resulting output differs.
Change-Id: I9c745c6be1b2b7a22085a230cc3f66ff756e0b62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2577460
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71647}
- Adds an AlignedSlotAllocator class and tests, to unify slot
allocation. This attempts to use alignment holes for smaller
values.
- Reworks Frame to use the new allocator for stack slots.
- Reworks LinkageAllocator to use the new allocator for stack
slots and for ARMv7 FP register aliasing.
- Fixes the RegisterAllocator to align spill slots.
- Fixes InstructionSelector to align spill slots.
Bug: v8:9198
Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71644}
Unifies various operators for dynamic map checks with the naming
scheme of DynamicCheckMaps (to be similar to CheckMaps.
BUG=v8:10582
Change-Id: I8ac842f55fe31cdc7b84968d077017a86ddf4442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567952
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71559}
This reverts commit 3599cce1f5.
Originally landed in
https://chromium-review.googlesource.com/c/v8/v8/+/2531775
Work on NCI is suspended, remove unused complexity. We may want to share
native-context-independent feedback in the future, but probably through other
means.
Bug: v8:8888
Change-Id: I23dfb67f6f01b4891af87bc42a9e62f99d0bf044
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567701
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71553}
This reverts commit 064ee3c835.
Reason for revert: Causing blink_web_tests to fail on builder "WebKit Linux MSAN"
https://bugs.chromium.org/p/chromium/issues/detail?id=1153968
Original change's description:
> Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."
>
> Reason for revert: Data race:
> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
>
> It was assume that MockPlatform runs everything on 1 thread. However,
> MockPlatform::PostJob previously would schedule the job through
> TestPlatform, which eventually posts concurrent tasks, thus causing
> data race.
> Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
> ensures the jobs also run sequentially.
>
> Additional change:
> - CancelAndDetach is now called in ~CompilationStateImpl() to make sure
> it's called in sequence with ScheduleCompileJobForNewUnits
>
> Original CL description:
> To avoid keeping around a list of job handles, CancelAndDetach() is
> used in CancelCompilation. Dependency on WasmEngine is handled by a
> barrier that waits on all jobs to finish.
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Original-Commit-Position: refs/heads/master@{#71074}
> Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71459}
TBR=ulan@chromium.org,jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,etiennep@chromium.org
Bug: chromium:1153968, v8:11209, v8:11210, v8:11212
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I2c8406bea81ee7cf6c5726c2fec50fffdce09611
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566446
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71519}
Reason for revert: Data race:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
It was assume that MockPlatform runs everything on 1 thread. However,
MockPlatform::PostJob previously would schedule the job through
TestPlatform, which eventually posts concurrent tasks, thus causing
data race.
Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
ensures the jobs also run sequentially.
Additional change:
- CancelAndDetach is now called in ~CompilationStateImpl() to make sure
it's called in sequence with ScheduleCompileJobForNewUnits
Original CL description:
To avoid keeping around a list of job handles, CancelAndDetach() is
used in CancelCompilation. Dependency on WasmEngine is handled by a
barrier that waits on all jobs to finish.
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#71074}
Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71459}
