This might help reduce flaky test results caused by too high memory
consumption due to the large Float32Array in regress-crbug-1057653.js.
Bug: v8:10333
Change-Id: Id99ebb67ebe5a7a730e44cd8967ebbea905ccdc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108547
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66836}
... to make it work from any location.
Bug: v8:10155
Change-Id: I4b949ed6fde0b38a92c1c1ab57eba0cf0f007b6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116034
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66835}
"By my deeds I honor him. V8."
- Add basic build files for library and unittests.
- Integrate unittests also in existing V8 unittests for simplicity.
The CL also adds FinalizerTrait and unittests to allow building a
testing target that executes code.
FinalizerTrait is used to determine how managed C++ types are
finalized. The trait should not be overridable by users but needs to
be exposed on API-level to avoid including library-internal headers.
Bug: chromium:1056170
Change-Id: I64d91053410a17a7835e50547f58990625d2da28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108549
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66834}
We previously could not OSR a frame paused in a breakpoint with another
frame in which the same breakpoint was removed, because the latter was
missing the source position.
This change fixes this by iterating the stack to collect frame
positions, and emitting the corresponding source positions in Liftoff.
R=clemensb@chromium.org
Bug: v8:10321,v8:10147
Change-Id: I5a7950d5ce6e3cd5a0648b861db75f4f3dafa644
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2115433
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66830}
Close WasmCodeRefScope before we potentially free the native module in
UpdateNativeModuleCache.
R=clemensb@chromium.org
Bug: chromium:1062868
Change-Id: I7cd11fd2283a2cc399d05e32c609ff1af07e2706
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113380
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66829}
The behaviour was clarified in the spec:
https://github.com/WebAssembly/exception-handling/pull/97
br_on_exn (and also rethrow, which will be added in another CL) should
trap on nullptr. This CL implements this by an explicit check on each
br_on_exn (within {GetExceptionTag}). This check will be redundant if
several br_on_exn follow each other. Since also the runtime call for
{GetExceptionTag} is redundant, and also the fact that we do a runtime
call is suboptimal, I consider the whole implementation prototypical for
now anyway.
R=jkummerow@chromium.orgCC=aheejin@chromium.org
Bug: v8:10128
Change-Id: I234c3183f93fe0884aadd2ab6dbd6c2b7a07c660
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113381
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66826}
Don't use deprecated HTML Imports, directly fetch the template files from
html instead.
Bug: v8:10155
Change-Id: Ic85a8b2cf227231fc6abf5adca6f1f144bf728f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113371
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66825}
During off-thread space merge, we free the linear allocation area in the
off-thread space. Since the off-thread space isn't marked, we have to
make sure that we don't try to compensate for black allocated live bytes.
Bug: chromium:1011762
Change-Id: Id2eb2212dc25e78952f817482abcdb4b49f3a373
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111224
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66823}
Remove unused breakpoints as we hit them. OSR in this case does not work
properly yet, because we are missing the source position for the removed
breakpoint in the new code.
R=clemensb@chromium.org
Bug: v8:10321
Change-Id: I908546c1b37ca044166b24b4900126ab79f117ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111216
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66821}
On Linux, Perfetto translates the builtin "ts" timestamp in trace event
from CLOCK_MONOTONIC to CLOCK_BOOTTIME, before passing them to devtools.
Devtools therefore implicitly operates on timestamps that are in
CLOCK_BOOTTIME.
However, additional timestamps sent in trace event payload arguments
will not be converted to CLOCK_BOOTTIME by Perfetto, raising the
possibility of devtools using timestamps from multiple clock domains
incorrectly.
Since trace events sent by CpuProfile also include the builtin "ts"
trace timestamp (sampled from CLOCK_MONOTONIC nearly at the same time by
the tracing framework), sending "data.startTime" and "data.endTime" is
essentially redundant. devtools-frontend:2113957 stops the use of the
value of these timestamps in the payload of Profile and ProfileChunk
events. Devtools continue to use the presence of these arguments to
indentify start and end profile events.
ProfileChunk events also include "timeDeltas" which are relative
timestamps. They are also in CLOCK_MONOTONIC and are not translated by
Perfetto. devtools-frontend:2113957 computes absolute CLOCK_BOOTTIME
timestamps from timeDeltas by adding them to "ts" in the "Profile" event
(previously, "data.startTime" was used). This is only valid if the
system is not suspended/resumed during profiling. Providing support for
suspend/resume in the middle of profiling will likely involve having
Perfetto convert "timeDeltas" directly to CLOCK_BOOTTIME.
This CL introduces no code changes and only adds comments to explain
the above.
BUG=chromium:1055871
Change-Id: I649dfcce8ea1a100c0ecfe03f843c7cb1fdd6f33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2114001
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66820}
Port a447a44f31
Original Commit Message:
Since now the IterationBody StackChecks are implicit within JumpLoops,
we are able to eagerly deopt in them. If we do that, whenever we advance
to the next bytecode we don't have to advance to the next literal
bytecode, but instead "advance" in the sense of doing the JumpLoop.
Adding tests that test this advancing for wide and extra wide JumpLoops.
Also, marking JumpLoop as needing source positions since now it has
the ability of causing an interrupt.
R=solanes@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I5bec2212d040801d67426a8639d20fe96035d813
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111832
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66814}
Introduces a new macro BUILD_V (v is for vector) that pushes bytes into
a vector (instead of directly in an array initializer, see BUILD). This
has the positive effect of being able to handle opcodes of multiple
bytes (e.g. SIMD opcodes bigger that 0xfd80). Because of this "API"
change, our helper macros in test-run-wasm-simd.cc and wasm-run-utils.h
need to change too. So, we introduce new macros (suffixed by _V), that
will call the appropriate lambdas defined in BUILD_V, that knows how to
push bytes into the vector, and also can handle multi-byte opcodes.
This design has a bit of duplication and ugliness, but was chosen to
reduce the impact of existing tests. No restructuring of test code is
required, we only need to add suffix _V.
Note that we do not have multi-byte opcodes yet (in wasm-opcodes.h),
this change will be breaking, and requires all the tests to be updated
to use _V macros first.
Bug: v8:10258
Change-Id: I86638a548fe2f9714c1cfb3bd691fb7b49bfd652
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2107650
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66812}
Now that it is implicit in function entry and loop iteration, there is
no need for an explicit bytecode.
Also updated tests that used explicit bytecodes.
Bug: v8:10149, v8:9960
Change-Id: I3ca582f276829bd54feb35e6d4ea656a32efbd54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093507
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66811}
This CL provides a generic way to prepare a builtin call: The
{PrepareBuiltinCall} takes the builtin signature for 64-bit systems,
the CallDescriptor, and a Vector of VarStates for the parameters, and
moves all parameters to their correct place, which is either in a
register or on the stack.
To test the new code this CL adjusts the implementation of AtomicWait
to use PrepareBuiltinCall. Thereby AtomicWait is now also supported
on 32-bit platforms, including ia32.
R=clemensb@chromium.org
Bug: v8:10108, v8:10281
Change-Id: Ia8589166310ea2e8442531b4ed20db62d7b4aff0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108554
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66810}
Since now the IterationBody StackChecks are implicit within JumpLoops,
we are able to eagerly deopt in them. If we do that, whenever we advance
to the next bytecode we don't have to advance to the next literal
bytecode, but instead "advance" in the sense of doing the JumpLoop.
Adding tests that test this advancing for wide and extra wide JumpLoops.
Also, marking JumpLoop as needing source positions since now it has
the ability of causing an interrupt.
Bug: v8:10149, v8:9960
Fixes: v8:10149
Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66809}
When spill a range without register uses inside a loop, it is beneficial to spill the range ealier at the loop header to reduce memory moves from the back edges.
The changes to FindOptimalSpillingPos are motivated as follows:
- Change “next_use->pos() < pos” to “next_use->pos() <= pos”.
The former version causes a crash of mksnapshot in debug build,
because it is possible that a UsePosition at a split point gets split
to the previous range according to “DetachAt”. For example, we
have a live range with:
UseIntervals: [1, 20[
UsePosition: 10
When split the live range at position 10, we will get:
Range 0:0: UseInterval: [1, 10[
UsePosition: 10
Range 0:1: UseInterval: [10, 20[
- Change “NextUsePositionRegisterIsBenefitial” to
“NextRegisterPosition”, because there’s always a
“Define” use position at the loop header for those phis
that do not require a register. Using the original check
will hence not apply the optimization.
Change-Id: I3b0bb3687ba572f1d3fc1892cefae7e866d99baa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2094964
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Yolanda Chen <yolanda.chen@intel.com>
Cr-Commit-Position: refs/heads/master@{#66806}
The FpRegister size was miswritten as kSimd128Size like x64, while it
should be kDoubleSize on mips.
Change-Id: Iac4c5687e398a87ec0508fb99042a487c41ddf8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110891
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66804}
I'm unable to produce an issue with this test locally, so let's
try to enable it again.
Big: v8:6587
Change-Id: Ida834ac4ccf8c25d8f5c1e09fc57479db46a1873
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108722
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66803}
The src register needs to be different from the temporary Simd128
register since in the codegen we modify tmp before using tmp and src.
Bug: chromium:1063006
Change-Id: I8b4b2d23d8f090ea37041e82cac97470bcf0d833
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111110
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66799}
This is a reland of e80ca24c80
Original change's description:
> [regexp] Rewrite error handling
>
> This patch modifies irregexp's error handling. Instead of representing
> errors as C strings, they are represented as an enumeration value
> (RegExpError), and only converted to strings when throwing the error
> object in regexp.cc. This makes it significantly easier to integrate
> into SpiderMonkey. A few notes:
>
> 1. Depending on whether the stack overflows during parsing or
> analysis, the stack overflow message can vary ("Stack overflow" or
> "Maximum call stack size exceeded"). I kept that behaviour in this
> patch, under the assumption that stack overflow messages are
> (sadly) the sorts of things that real world code ends up depending
> on.
>
> 2. Depending on the point in code where the error was identified,
> invalid unicode escapes could be reported as "Invalid Unicode
> escape", "Invalid unicode escape", or "Invalid Unicode escape
> sequence". I fervently hope that nobody depends on the specific
> wording of a syntax error, so I standardized on the first one. (It
> was both the most common, and the most consistent with other
> "Invalid X escape" messages.)
>
> 3. In addition to changing the representation, this patch also adds an
> error_pos field to RegExpParser and RegExpCompileData, which stores
> the position at which an error occurred. This is used by
> SpiderMonkey to provide more helpful messages about where a syntax
> error occurred in large regular expressions.
>
> 4. This model is closer to V8's existing MessageTemplate
> infrastructure. I considered trying to integrate it more closely
> with MessageTemplate, but since one of our stated goals for this
> project was to make it easier to use irregexp outside of V8, I
> decided to hold off.
>
> R=jgruber@chromium.org
>
> Bug: v8:10303
> Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66784}
R=jgruber@chromium.org
Bug: v8:10303
Change-Id: Iad1f11a0e0b9e525d7499aacb56c27eff9e7c7b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109952
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66798}
This CL introduces a CSA builtin for the TableCopy instruction. This
builtin allows to generate smaller code for both TurboFan and Liftoff,
and easier code generation from Liftoff.
The smaller code size comes from:
* Parameters are passed through registers, not the stack.
* Lower number of parameters: the call target, number of parameters, and
context are not passed as parameters.
* No int to smi conversion in generated code.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: I4734b94c8a2aff08a5938504e3e36d0d2424f8ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110010
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66797}
Chrome uses the new version now.
Bug: v8:8116
Change-Id: I59af8d2c6a897a852acd6de3a7938a4b8d3943e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110015
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66796}
Implement i8x16.bitmask, i16x8.bitmask, i32x4.bitmask on interpreter and
arm64.
These operations are behind wasm_simd_post_mvp flag, as we are only
prototyping to evaluate performance. The codegen is based on guidance at
https://github.com/WebAssembly/simd/pull/201.
Bug: v8:10308
Change-Id: I835aa8a23e677a00ee7897c1c31a028850e238a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099451
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66793}
This CL introduces a CSA builtin for the TableInit instruction. This
builtin allows to generate smaller code for both TurboFan and Liftoff,
and easier code generation from Liftoff.
The smaller code size comes from:
* Parameters are passed through registers, not the stack.
* Lower number of parameters: the call target, number of parameters, and
context are not passed as parameters.
* No int to smi conversion in generated code.
The CL also introduces a small CSA function which takes an uint32 value
and a max value as parameters and returns a Smi of the minimum of these
two.
R=clemensb@chromium.org, ishell@chromium.org
Bug: v8:10281
Change-Id: I40f248c20ec76e6ae9483a5e2907a68f42f2cb04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106201
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66792}
Add some more code comments for code snippets that are not obvious,
especially if debug code is enabled.
The comments help when looking at Liftoff code for debugging code
generation issues.
R=thibaudm@chromium.org
Change-Id: I566bf2b05a454fb8addc030359969d36cb2cb707
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108557
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66791}
