Without flushing the messages, the timing of the notifications
is unpredictable making it hard to build features on top.
Bug: chromium:1224371
Change-Id: Ice09ef82231186d1a93ca82508c49e26585ce260
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2991237
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75525}
Rolling v8/build: 969e9b2..f79e8a3
Rolling v8/buildtools/third_party/libc++abi/trunk: d46361b..ae0481e
Rolling v8/buildtools/third_party/libunwind/trunk: 9303368..ed4a85e
Rolling v8/third_party/aemu-linux-x64: kZbnq1Wh_y69PWihHdedFiEIQANIiZchdysb5-fpBTEC..czR22wy3jcAfrw7l4ljto3qX6BpD2DSahnluWvqUockC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/949bca8..36f311b
Rolling v8/third_party/googletest/src: 255323c..4ec4cd2
Rolling v8/tools/luci-go: git_revision:ede472114f4e51eaa068cd84cadcf470773f19ef..git_revision:e20098f56b10587e3cc0bc9ccac4934a13158de3
Rolling v8/tools/luci-go: git_revision:ede472114f4e51eaa068cd84cadcf470773f19ef..git_revision:e20098f56b10587e3cc0bc9ccac4934a13158de3
Rolling v8/tools/luci-go: git_revision:ede472114f4e51eaa068cd84cadcf470773f19ef..git_revision:e20098f56b10587e3cc0bc9ccac4934a13158de3
TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I4f07d610e608afbf4dfb8f5bec70a694ad660ca9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3002689
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#75523}
Currently the process-wide CodeRange, once created, lives until process
shutdown. This CL changes it to be alive as long as there is a Heap,
when the last Heap is gone it gets destroyed and will be recreated the
next time a Heap is created. This behavior is shared with
SingleCopyReadOnlyArtifacts.
Bug: v8:11929
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Change-Id: I8a545926c3a4122991f9682bd3fd90e72697ea5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2989103
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75522}
With relative paths in the debug symbols, lldb cannot find the source
files, so set up a source map to direct "../.." to V8 root. This is
similar to what Chromium does in src/tools/lldb/lldbinit.py.
Bug: v8:11879
Change-Id: Ic6126aacafa7e3462c69da538a9528041c92ef00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2998517
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75521}
Small refactoring to use an existing ElementSizeInPointers (which has
the same implementation). LinkageLocation::GetSize is now not called
anywhere else, so remove it. The instruction selector can then call
LinkageLocation::GetSizeInPointers instead of calculating it.
Bug: v8:11879
Change-Id: I6f717db1c4047e7847f00cf2bf96c6ec8ea52bda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2997924
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75520}
Splits FLAG_lazy into
- FLAG_lazy for main-thread compiled scripts/modules
- FLAG_lazy_streaming for streamed scripts
- FLAG_lazy_eval for eval
This allows us to evaluate the impact of non-lazy compilation for streamed
scripts.
Change-Id: I8a362ea184e0afd3aa7cdb11a7eab5b7497a4691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999090
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75518}
In the existing code we calculate twice how we want to compile a
WebAssembly function, first in InitializeCompilationProgress, and then
again in InitializeCompilationUnit. With this CL we use the information
in the compilation progress to create the CompilationUnits. Not only
does this make the code cleaner, it will also allow us to initialize the
compilation progress differently for deserialization but reuse the code
to create CompilationUnits.
R=clemensb@chromium.org
Bug: v8:11862
Change-Id: Iee48727be429e3a3a950404806fdd04264145999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988759
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75516}
Changes:
- Use a lightweight WasmElemSegment::Entry struct to store element
segment entries in a WasmModule.
- Also, restructure LoadElemSegmentImpl to handle all types of
global.get entries correctly.
- Simplify InitializeIndirectFunctionTables and make it handle all types
of entries correctly.
- In the above two cases, reject WasmJSFunctions for now.
Bug: v8:11895
Change-Id: Ie714f8c7f1af8959486138d2ad49bc622a89276d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2991248
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75513}
NewEmptyCode was missing the initialisation of three fields.
These were crashing when running with --verify-heap.
Bug: v8:11872
Change-Id: I679f0d2d68c5594b0e9700b26c031483c3d46b68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999095
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75511}
When adding up the results of the recursive steps, the Karatsuba
algorithm can temporarily have intermediate results that are one
bit bigger than the final result. This patch makes sure we handle
that case correctly.
Since that extra bit would always get subtracted again, the old
code would not have caused incorrect results or memory corruption,
but it did run into DCHECK-failures, and potentially could have
caused segfaults.
Bug: v8:11515, chromium:1223724
Change-Id: I3592835d01cc36def8f0a9bae625e9249864ef78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988758
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75509}
This CL improves setting the javascript_execution_assert
on the isolate from generated code by adding a single wrapper
function around the fast call creation, along with its setup
and teardown. It's a follow-up for
https://chromium-review.googlesource.com/c/v8/v8/+/2982998/
Bug: chromium:1218898
Change-Id: I0dc45520aa2a9b60ce03076a495e3f68c05945c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999086
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75506}
It is possible that we fallback to GenericLowering for minimorphic
property accesses. So handle MinimorphicPropertyAccess in
ShouldUseMegamorphicLoadBuiltin.
Bug: chromium:1223733
Change-Id: Ia1ba8c8786be91dda841d4138cffe81185c066b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2997104
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75505}
This relands squashed CLs:
59b9aaf7db8f84d0bb8f
The revert was at crrev.com/c/2996198.
Changed: Fixed a test in which bytecode flushing caused a behavioral
change between serialized- and unserialized SFI Refs. The serialized
SFI ref kept bytecode alive while unserialized SFIs allow flushing.
The test was fixed by adding a %PrepareFunctionForOptimization
annotation.
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7790, v8:11939
Change-Id: I170f8085bd7454a2a5f2bb03c8824e2862857827
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999089
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75504}
The files that Node.js checks in source control are not enough
for BUILD.gn.
Change-Id: I84f4794b9354bf8a4006965cc84d8610ea3a1a7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2991647
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75503}
This special-cases the most common situation to avoid call overhead.
Bug: chromium:1224299
Change-Id: Ic4bac2d5565f9b7a174eed845952b596adecbc8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2997584
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75502}
Start a local symbol server using the local-web-sever node package:
ws --stack system-analyzer/lws-middleware.js lws-static cors
The system-analyzer will then use it to symbolize profiles.
Note: The symbol server will execute `nm` and `objdump` locally.
Change-Id: Icff6e9f5af24f214f353c049f5cd13eedccf0f88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979591
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75501}
We've already been zero-extending 32-bit offset registers since
https://chromium-review.googlesource.com/c/v8/v8/+/2917612,
but that patch only covered the case where offset_imm == 0.
When there is a non-zero offset, we need the same fix.
Bug: chromium:1224882,v8:11809
Change-Id: I1908f735929798f411346807fc4f3c79d8e04362
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2998582
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75500}
Bug: v8:7790, chromium:1225521
Change-Id: I4210ca9d3eccdc4de0b5b865bac37dc32b8e6f17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999085
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75499}
We currently only measure the compilation time of individual functions,
but that does not include other things that happen for lazy compilation,
like switching memory permissions or publishing the code.
This CL adds a dedicated counter to measure the complete lazy
compilation time.
R=jkummerow@chromium.orgCC=dlehmann@google.com
Bug: v8:11940
Change-Id: I9a87882d2adc7bea6c5258954a642da18b8337ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2997106
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75498}
Bug: v8:7790, chromium:1225300
Change-Id: I36ae331db0abb072ebc597b4682c3983a00d8a1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999084
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75497}
- Updated implementation of platform-starboard
- Introducing stack_trace_starboard.cc
- Adding Starboard implementation for sys-info, random and memory
- Disabling some code in ostream.
Bug: v8:10927
Change-Id: I4548a413449fc8e43c5d4ae485b3644c60c07830
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2952864
Commit-Queue: John Xu <johnx@google.com>
Auto-Submit: John Xu <johnx@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75495}
There are still a few cases remaining that seem more controversial;
I'll upload those separately.
Bug: chromium:1066980
Change-Id: Iabbaf23f9bbe97781857c0c589f2b3db685dfdc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994804
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75494}
Fix a offset error, this is related to
commit 38fb148730
Delete cctest/test-run-machops/StackSlotAlignment, this is
related to commit a58f812c48
Change-Id: I3ef1b96d8a3bdba530200cbac4f7a062496ace59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994813
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Auto-Submit: Liu yu <liuyu@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#75493}
This is a reland of 071a1acf32
Changes compared to original:
Expect SIMD test to fail if SIMD is not supported.
Original change's description:
> [wasm] Refactor initializer expression handling
>
> Design doc: https://bit.ly/3xPxWUe
>
> This CL introduces two main changes:
> - Initializer expressions are now decoded by WasmFullDecoder. With
> wasm-gc, initializer expressions are no longer just constants, and
> require complex decoding (including stack tracking). This resulted in
> extensive code duplication.
> - Initializer expressions are not stored explicitly by module-decoder as
> an AST (WasmInitExpr), but rather as a WireBytesRef, and are decoded
> again during module instantiation. This should reduce memory
> consumption for globals and other module elements with initializer
> expressions (which has been observed in the 40MB range in some
> real-world benchmarks.
>
> Summary of changes:
> - Add a static parameter {kFunctionBody, kInitExpression} to the
> WasmDecoder. Use it to specialize validation to function bodies/init.
> expressions.
> - Introduce a new Interface for the WasmFullDecoder for init.
> expressions.
> - Differentiate between constant and non-constant opcodes in
> WasmFullDecoder.
> - Change representation of init. expressions in WasmModule to
> WireBytesRef.
> - Reimplement EvaluateInitExpression in module-instantiate to re-decode
> initializer expressions.
> - Remove some now-invalid module decoder tests.
>
> Pending changes:
> - Also refactor initializer expressions for element segment entries.
> - Reintroduce deleted tests.
>
> Bug: v8:11895
> Change-Id: I76512bfe1386c8338667d30fa6db93880a1e4b42
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972910
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75476}
Bug: v8:11895
Change-Id: I2dface5ff28d5a2d439a65d3e5cb83135c061bb9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2997722
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75492}
Grouping a couple of small, non-functional fixes:
- add a comment to GetStackParameterDelta
- small typo fixes to a couple of places I saw while reading related
code
Bug: v8:11879
Change-Id: I8566c9778fd6268b08ea3aefbdaa84ef894bcd35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2997922
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75490}
PropertyArray::get() and a few other functions there call
PropertyArray::length() in an assert. These need to be the acquire
load version of length() to keep TSAN happy.
Bug: chromium:1225277
Change-Id: Ic43bfc1902dea3e87f353be0efd03563c13c1e10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2997105
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75489}
Currently, running jco gives us an error message like so:
(lldb) jco $pc
Failed to evaluate command _v8_internal_Print_Code((void*)($pc)) :
error: <user expression 0>:1:1: '_v8_internal_Print_Code' has unknown
return type; cast the call to its declared return type
_v8_internal_Print_Code((void*)($pc))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The fix is to cast the call to (void). I've only used and found this
issue with jco, but I think the other commands have the same issue, so
fixing those together here.
FYI I am using lldb version 11.
Bug: v8:11879
Change-Id: Id9d8e8091fd011585e6fea863de5b4d7c9d47c5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994764
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75487}
No longer needed now that the predicate is fixed.
Bug: v8:7790,v8:11779
Change-Id: If585c3692aed77659b53f670182129988ba93130
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996193
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75486}
This reverts commit 071a1acf32.
Reason for revert: Breaks on nosse: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/42795/overview
Original change's description:
> [wasm] Refactor initializer expression handling
>
> Design doc: https://bit.ly/3xPxWUe
>
> This CL introduces two main changes:
> - Initializer expressions are now decoded by WasmFullDecoder. With
> wasm-gc, initializer expressions are no longer just constants, and
> require complex decoding (including stack tracking). This resulted in
> extensive code duplication.
> - Initializer expressions are not stored explicitly by module-decoder as
> an AST (WasmInitExpr), but rather as a WireBytesRef, and are decoded
> again during module instantiation. This should reduce memory
> consumption for globals and other module elements with initializer
> expressions (which has been observed in the 40MB range in some
> real-world benchmarks.
>
> Summary of changes:
> - Add a static parameter {kFunctionBody, kInitExpression} to the
> WasmDecoder. Use it to specialize validation to function bodies/init.
> expressions.
> - Introduce a new Interface for the WasmFullDecoder for init.
> expressions.
> - Differentiate between constant and non-constant opcodes in
> WasmFullDecoder.
> - Change representation of init. expressions in WasmModule to
> WireBytesRef.
> - Reimplement EvaluateInitExpression in module-instantiate to re-decode
> initializer expressions.
> - Remove some now-invalid module decoder tests.
>
> Pending changes:
> - Also refactor initializer expressions for element segment entries.
> - Reintroduce deleted tests.
>
> Bug: v8:11895
> Change-Id: I76512bfe1386c8338667d30fa6db93880a1e4b42
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972910
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75476}
Bug: v8:11895
Change-Id: I9fcfdedad73ef21beb9632f50305b8e678a2dff6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2997582
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#75484}
FLAG_SCOPE_EXTERNAL can be used outside of the v8::internal namespace,
while FLAG_SCOPE can not.
This CL refactors FLAG_SCOPE such that it can be used anywhere, and
removes the redudant FLAG_SCOPE_EXTERNAL macro.
Also, UNFLAG_SCOPE_EXTERNAL is removed in favor of FLAG_SCOPE_VAL, as
the word "flag" in the macro name is meant to refer to a flag, and not
to the verb or action of "flagging" something, hence "unflag" does not
match the terminology.
R=ahaas@chromium.org
Bug: v8:11879
Change-Id: I2d761012c3e4330abb611bf67130eb57ec5bb964
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988920
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75482}
regress-crbug-482998 is skipped and regress-331444 is marked
as slow.
Bug: v8:11875
Change-Id: I01c14dee704c5179d62b79cca0681f833102680d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996842
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#75481}
There are instructions that take 7 bytes, e.g.
4881ec10000000 REX.W subq rsp,0x10
Hence increase the padding from 12 characters to 14 characters to
restore alignment.
Drive-by: Rewrite the padding loop to make it more readable and add a
comment.
R=jkummerow@chromium.org
Change-Id: Iddd6a721574fc47b4a072fe40c2f5e90cb3d1186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996200
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75480}
The {EnterFrame} and {LeaveFrame} methods will already emit a (scoped)
code comment in the form
[ EnterFrame
... instructions ...
]
Thus skip the additional code comment emitted by Liftoff.
R=ahaas@chromium.org
Bug: v8:11879
Change-Id: I488568022cb03b16f07a12c1a575d90613691758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996197
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75479}
Extern ref in Liftoff is enabled since M-90
(https://crrev.com/c/2625886), hence remove the flag to simplify the
code.
R=ahaas@chromium.org
Bug: v8:11879
Change-Id: Ie72dfbc006d6f42e2e9e83d44ff78e3c53a82614
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996195
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75478}
We currently merge i32 binary operations with a subsequent if or br_if,
and we merge i32.eqz with a subsequent br_if. The combination i32.eqz +
if was missing, even thought there is already support for that in the
"if" handler.
R=ahaas@chromium.org
Change-Id: Id4386d0c5d6dcf3605c72ea1146169d2088abe98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996196
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75477}
