InstanceBuilder::LoadTableSegments - Throw RuntimeError instead of
LinkError
WasmGraphBuilder::TableInit & WasmGraphBuilder::MemoryInit - Do not
check for active/dropped status if size == 0
WasmGraphBuilder::MemoryFill - Throw out-of-bounds error BEFORE
attempting any memory operations if necessary
R=ahaas@chromium.org
Bug: v8:9865
Change-Id: I6a67779dc99fdc1c6bda6a2526d0e9ee5385f3ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924442
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65098}
This is a reland of f2a74165bf
Original change's description:
> [regexp] Re-execute regexp when '.indices' is accessed.
>
> Instead of storing a pointer to the last_match_info, which may
> change, this cl modifies JSRegExpResult to store a pointer to
> the original JSRegExp which generated it, as well as additional
> data needed to re-execute the match.
>
> Basically a straight copy and tidy off jgruber@'s prototype:
> https://chromium-review.googlesource.com/c/v8/v8/+/1876810
>
> Bug: v8:9548
> Change-Id: I11b7deae681b8287e41e8d0e342291ff484751fb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910129
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65053}
Bug: v8:9548
Change-Id: Ieeba4b1ae59ef0c7946d654dc314adfae09d24b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925554
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65096}
This is necessary because the spec changed.
R=mstarzinger@chromium.org
Bug: v8:9865
Change-Id: Id8b4d85eafcf368d591666907036e6aa54664e63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921794
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65072}
When importing a JS function, Wasm tries to guess the type of function
(parameters & strict/sloppy mode). This can sometimes fail which leads
to re-creation of the wrapper. With this change, the same wrapper can
be used for strict and sloppy mode requiring the re-creation only on
arity mismatch.
R=mstarzinger@chromium.org
Change-Id: I77ec2b853153dec0772873cfb60c064a74065732
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921793
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65064}
This reverts commit f2a74165bf.
Reason for revert: Clusterfuzz
Bug: chromium:1026479
Original change's description:
> [regexp] Re-execute regexp when '.indices' is accessed.
>
> Instead of storing a pointer to the last_match_info, which may
> change, this cl modifies JSRegExpResult to store a pointer to
> the original JSRegExp which generated it, as well as additional
> data needed to re-execute the match.
>
> Basically a straight copy and tidy off jgruber@'s prototype:
> https://chromium-review.googlesource.com/c/v8/v8/+/1876810
>
> Bug: v8:9548
> Change-Id: I11b7deae681b8287e41e8d0e342291ff484751fb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910129
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65053}
TBR=jgruber@chromium.org,joshualitt@chromium.org
Change-Id: I6294e3d7ac0b3e2bd9404697823b8d3cc2545c16
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9548
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925651
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65057}
Instead of storing a pointer to the last_match_info, which may
change, this cl modifies JSRegExpResult to store a pointer to
the original JSRegExp which generated it, as well as additional
data needed to re-execute the match.
Basically a straight copy and tidy off jgruber@'s prototype:
https://chromium-review.googlesource.com/c/v8/v8/+/1876810
Bug: v8:9548
Change-Id: I11b7deae681b8287e41e8d0e342291ff484751fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910129
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65053}
This reduction relies on a known object layout of the regexp instance
in order to access the lastIndex field through a statically-determined
offset. Prior to this CL, we checked only for instance types, not for
the map, and thus it was possible to read garbage from either inside
or outside the current object.
Bug: chromium:1024758,v8:7779
Change-Id: I1eec8220797f443bdf3d05804e54f33b21fa2f00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924353
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65039}
This CL implements torque builtins for BigInt subtraction and extends
the compilation pipeline to lower calls to the generic subtraction
to SpeculativeBigIntSubtract and later to BigIntSubtract with
necessary checks in case of BigInt feedback.
The CL also implements lowering of these operators to native machine
word operations on 64 bit architectures if they are used in a
truncating context (aka BigInt.asUintN).
Bug: v8:9407
Change-Id: Idf5da14c380bc7c12375e7f084a3e1c455303f5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895566
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65037}
Bytecode flushing bit me again.
Bug: v8:9945, v8:9983
Change-Id: I9e4f9dd5e1793d60b24def447a8374e550fa248a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924352
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65036}
The optimization behavior in these configurations is strange, I'm
still trying to understand what exactly is going on.
Bug: v8:9945, v8:9983
Change-Id: I52782b9e73decb9f3b2439cddd5e23068faebdf4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924349
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65032}
... by disallowing checkpoint elimination across function boundaries.
See the comment in checkpoint-elimination.cc and the tests for details.
Bug: v8:9945
Change-Id: Ibf4ab6f0e4e709e26d3c4428a082ef45dcbeb8b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1906208
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65027}
The serialization of Construct was accidentally using the wrong hints
for the receiver. Also, the recursion in ProcessCallOrConstruct was
not quite right: for example, it overwrote the accumulator hints in
each recursion.
With this CL the Octane raytrace score for --concurrent-inlining is
back to the default configuration's score.
Bug: v8:7790
Change-Id: I501c9cc0b0c8de04520742b9c6b392a4a732bf78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921789
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65011}
Since WASM can generate direct calls to any function that it knows the
arity of and these can be any JS linkage builtin, we need to ensure that
CPP builtins also go into CODE_SPACE.
This moves 276 builtins (~25KiB) from RO_SPACE back to CODE_SPACE.
Bug: chromium:1022695, v8:7464
Change-Id: I4cda8b68ddf6a5ddad09c6e7d4e6a08c8e6c2ccb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916600
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65004}
This makes sure that the {WasmGraphBuilder} properly detects the
presence of Simd128 loads and store opcodes and triggers then scalar
lowering of the graph on architectures that don't support Simd128.
R=clemensb@chromium.org
TEST=mjsunit/wasm/exceptions-simd
BUG=v8:9973
Change-Id: I118f72135ddc9011efa3f75aaf120bb67e708d8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916605
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64964}
... that started failing on AIX where the allocation of a huge
ArrayBuffer succeeds.
Bug: v8:4153
Change-Id: I322c71e01edccb254a523f7f85817971b6c68242
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914561
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64960}
This is a reland of 837556be7f
Original change's description:
> [wasm] Improve test coverage of s128 exception handling.
>
> This adds test coverage for the encoding and decoding of s128 values as
> part of an exception package. The encoding within an exception package
> is not specified (and not observable), but the full bit-pattern needs to
> survive an encoding/decoding round trip.
>
> R=clemensb@chromium.org
> TEST=mjsunit/wasm/exceptions-simd
> BUG=v8:8091
>
> Change-Id: I4cf6c1f00c64757512f66d068640a7e772eb0127
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1905769
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64932}
Bug: v8:8091,v8:9973
Change-Id: I7daf17a0cbc6904e7130ec4e50b12a829b1b1d34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916203
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64951}
This reverts commit 837556be7f.
Reason for revert: Breaks V8 Linux https://cr-buildbucket.appspot.com/build/8896896548394462912
Original change's description:
> [wasm] Improve test coverage of s128 exception handling.
>
> This adds test coverage for the encoding and decoding of s128 values as
> part of an exception package. The encoding within an exception package
> is not specified (and not observable), but the full bit-pattern needs to
> survive an encoding/decoding round trip.
>
> R=clemensb@chromium.org
> TEST=mjsunit/wasm/exceptions-simd
> BUG=v8:8091
>
> Change-Id: I4cf6c1f00c64757512f66d068640a7e772eb0127
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1905769
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64932}
TBR=mstarzinger@chromium.org,clemensb@chromium.org
Change-Id: I9276c6f6600a0f4e8a06dd1a7907cac25c761577
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8091
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914211
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64935}
This adds test coverage for the encoding and decoding of s128 values as
part of an exception package. The encoding within an exception package
is not specified (and not observable), but the full bit-pattern needs to
survive an encoding/decoding round trip.
R=clemensb@chromium.org
TEST=mjsunit/wasm/exceptions-simd
BUG=v8:8091
Change-Id: I4cf6c1f00c64757512f66d068640a7e772eb0127
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1905769
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64932}
When simulating bytecode, we store the current environment at the
site of the appropriate catch handler when entering a try range.
If the start of the try range is dead, we don't bother to store
an environment. However, generators can create alive regions
inside the try range. At such moments, we should recognize
we're in a try range and store the environment for the handler.
Bug: chromium:1017159
Change-Id: Icccc2ccf530895099bc62b97d9aaec8b97d5f4e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879247
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64929}
This allows the tests to continue running on the gc fuzzers while
staying compatible with the --force-slow-path flag being passed
randomly.
When run in slow_path variants these tests are no-ops, but that's
negligible as the tests are also fast without slow_path.
Change-Id: I461c47b669b163e1e1594ea1a941f63e90f2221e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910947
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64914}
... even with ptr-compr.
Although full uintptr-sized TypedArrays are not supported yet
we may already start using uint32-sized typed arrays as we no
longer rely on TypedArray length to be a Smi.
Bug: v8:4153
Change-Id: If179541ad4f02c4ec7de9d1f3836138fe526d8a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1905847
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64897}
The function-entry stack check should dominate all other
instructions in a function. Prior to this CL it was possible to create
paths not including a stack check due to SwitchOnGeneratorState: the
generator-creation branch had a stack check, while generator-resume
branches did not.
0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 }
4 : 27 fe fa Mov <closure>, r1
7 : 27 02 f9 Mov <this>, r2
10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2
14 : 26 fb Star r0
16 : a7 StackCheck
17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0]
22 : b1 fb fb 01 ResumeGenerator r0, r0-r0
[... no stack check here ...]
This CL moves the stack check to the beginning of the bytecode array,
i.e. before SwitchOnGeneratorState.
Bug: chromium:1020031
Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64888}
When the serializer encounters a JSConstruct, it now serializes the
initial map of the new_target to enable further opitmizations in
JSNativeContextSpecialization.
Add regression tests as well.
Bug: v8:7790
Change-Id: Ifab2b58c64a341744e833ed063e9695d74a5cdce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900457
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64886}
In the presence of default arguments, the body of the function gets
wrapped into another block. This caused our trailing-range-after-return
optimization to not apply, because the wrapper block had no source
range assigned. This CL correctly assignes a source range to that block,
which allows already present code to handle it correctly.
Note that this is not a real coverage bug; we've just been reporting
whitespace as uncovered. We're fixing it for consistency.
Originally reported on github.com/bcoe/c8/issues/66
Bug: v8:9952
Change-Id: Iab3905f558eb99126e0dad8072d03d0a312fdcd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903430
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64836}
When --always-promote-young-mc is enabled, this test becomes more
flaky. Increase old space size, such that objects fit into the
old generation during mark-compact.
Bug: v8:9192
Change-Id: Iad3b914c7d5b7bafa752f3b6178684a137bd8dad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1890101
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64830}
Runtime of this test has improved since we initially skipped it. Let's
attempt unskipping on all non-debug builds.
Bug: v8:8411
Change-Id: I5d409f7359532e3d7d18f5b0a77765165478d44a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903426
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64825}
The (age, context) pair has to be added atomically in to the weak
array of detached contexts. Otherwise, GC may happen after insertion
of age and observe inconsistent state.
Bug: chromium:1016703
Change-Id: Icb20bed4359904b2d976986a236558542e314bbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895573
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64820}
The bug is due to an unexpected opcode. To avoid similar issues in the future, we fallback to CheckContextExtensionSlowPath. This was the default behaviour before the CL (https://chromium-review.googlesource.com/c/v8/v8/+/1876051).
Bug: chromium:1020983
Change-Id: Ia7f0f2986ec0008d1128ad3856efbb5d9e52dfc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1899989
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64794}
Currently there are two ways wasm locations are represented in the
inspector. This remains unchanged for now. Also, currently there are
multiple ways location is represented within V8, with the line number
sometimes being a function index and sometimes being 0, and the column
number being a byte offset which is sometimes function relative and
sometimes module relative. With this change, the line number is never
used within V8 (it is always 0), and the column number is always a
byte offset from the beginning of the module. This simplifies
translation logic and keeps it in one place, and will simplify future
changes to wasm location representation in the inspector API.
Bug: chromium:1013527
Change-Id: I8813d47c881988f9ab49d7529fb81fe10dbbccff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886915
Commit-Queue: Eric Leese <leese@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64774}
This reverts commit d4574d186f.
Reason for revert: In addition to the earlier octane regression, this cl also created a regression in desktop browsing
Bug: chromium:1019601
Original change's description:
> Reland "[regexp] Clone match info for match indices."
>
> This reverts commit d7793c0684.
>
> Reason for revert: This cl *will* cause regexp regressions. We are trying to gauge the real world impact.
>
> Original change's description:
> > Revert "[regexp] Clone match info for match indices."
> >
> > This reverts commit dfd9ceb984.
> >
> > Reason for revert: Regressions https://chromeperf.appspot.com/group_report?rev=64356https://crbug.com/1015749
> >
> > Original change's description:
> > > [regexp] Clone match info for match indices.
> > >
> > > The current behavior for generating match indices simply stashes a
> > > pointer to the match info and then constructs the indices lazily.
> > > However, it turns out the match info object used to create the result
> > > object is the regexp_last_match_info living on native context, and thus
> > > it can change between the creation of the result object and the generation
> > > of indices. This cl clones the match info which will be safer.
> > >
> > > Bug: v8:9548
> > > Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585
> > > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#64356}
> >
> > TBR=jgruber@chromium.org,joshualitt@chromium.org
> >
> > # Not skipping CQ checks because original CL landed > 1 day ago.
> >
> > Bug: v8:9548, chromium:1015749
> > Change-Id: I9c30b8fb459cf2aa89d920bf061614441250844d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870236
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#64407}
>
> TBR=jgruber@chromium.org,joshualitt@chromium.org
>
>
> Bug: v8:9548, chromium:1015749
> Change-Id: I151511307e3d8752fdbde4b8247514031b141b08
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879587
> Reviewed-by: Joshua Litt <joshualitt@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64587}
TBR=jgruber@chromium.org,joshualitt@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9548, chromium:1015749
Change-Id: Ie5a8e55338728aae33102d82e60a188f6440e8f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898030
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64749}
This issue was fixed in https://chromium-review.googlesource.com/c/v8/v8/+/1873692
Bug: chromium:1016450
Change-Id: I56e1c504ae6876283568a88a9aa7d24af3ba6474
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876057
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64738}
Changing the target of JSCall nodes (e.g. while lowering higher order calls)
now preserves feedback and speculation mode to allow further (speculative)
optimizations. A flag is introduced to mark feedback unrelated to the call
target after such a transformation. This flag is used to prevent access to
the feedback without the need to invalidate it.
Bug: v8:9702
Change-Id: I311d3a4b1b22d6f65e5837a23b0b7585c8d75eed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844788
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64733}
Currently atomic operations are only allowed on shared WebAssembly.memory.
An attempt to use atomic operations otherwise is a validation failure, there
is an ongoing attempt to allow Wasm atomic operations on any memory object.
https://github.com/WebAssembly/threads/issues/144
This CL adds experimental support for allowing atomic operations on all
memory objects behind the --wasm-atomics-on-non-shared-memory flag. Note
that Wait/Notify may not work as expected as they have additional checks
to ensure that the memory is a SAB.
Bug: v8:9921
Change-Id: Ia65b1a4a96ec026430fcce028465423f600adacd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895703
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64716}
This reverts commit b8ac4eb4dc.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1020533
Original change's description:
> [runtime] Correctly handle global stores when global object has proxies
>
> When global object has proxies we should first call hasProperty and
> then call SetProperty if has property returns true. This cl fixes both
> StoreGlobal and StoreLookupGlobal to correctly handle these cases.
>
> Bug: chromium:1018871
> Change-Id: I140514e2119c6bab2125abcdc1b19d46526be5ff
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889885
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64687}
TBR=mythria@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1018871
Change-Id: I5abbf9275cba17576e1b1e492abd36d6bc1ca1bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893194
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64714}
Previously only Builtins declared TFJ or CPP in builtins-definitions.h
were converted to direct calls in ReduceJSCall. This allows all
builtins with JS linkage to be converted. To facilitate this, it adds
Builtins::HasJSLinkage(id) that returns true for any builtins with
JSTrampolineDescriptor as their call descriptor.
It also ensures that any JS functions installed by the bootstrapper are
also required to have JS linkage to catch early errors.
Change-Id: I2fddca41f9ab1c7c9633aa0ab4847a5c108e2bb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883549
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64698}
