Since the compile job can always be reused after creation (even if it
runs out of work), we do not need the logic to (re-)initialize it. In
fact, it will always only be initialized once already.
This allows us to initialize it once during construction of the
compilation state (or right after the initialization), and then access
it without locks later.
In addition, this CL
1) renames "current_compile_job_" to "compile_job_", since there will
always only be one now;
2) removes the {ScheduleCompileJobForNewUnits} method, and just does a
{compile_job_->NotifyConcurrencyIncrease()} instead;
3) removes the {has_priority_} field and just directly does a
{compile_job_->UpdatePriority} call.
The streaming test platform needed to be fixed to avoid calling {Join}
on the job handle, which would invalidate the handle afterwards.
Instead, we just run all tasks as long as there are any.
R=thibaudm@chromium.orgCC=etiennep@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: I7094231e86d5f54cfca5e971b96fd81e994c874a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584946
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71757}
Codegen is identical to x64.
Tweaked a macro definition to do a dst == src1 check when AVX is not
supported, and updated a single caller in LiftOff.
Bug: v8:11086
Change-Id: Ic9645f3d1bf1c26a1aa6db6bc2fa67fc991f8bbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579928
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71756}
Code like:
x = wasm_v32x4_shuffle(x, x, 1, 2, 3, 0);
is currently matched by S8x16Concat, which lowers to two instructions:
movapd xmm_dst, xmm_src
palignr xmm_dst, xmm_src, 0x4
There is a special case after a S8x16Concat is matched:.
- is_swizzle, the inputs are the same
- it is a 32x4 shuffle (offset % 4 == 0)
Which can have a better codegen:
- (dst == src) shufps dst, src, 0b00111001
- (dst != src) pshufd dst, src, 0b00111001
Add a new simd shuffle matcher which will match 32x4 rotate, and
construct the appropriate indices referring to the 32x4 elements.
pshufd for the given example. However, this matching happens after
S8x16Concat, so we get the palignr first. We could move the pattern
matching cases around, but it will lead to some cases where
where it would have matched a S8x16Concat, but now matches a
S32x4shuffle instead, leading to worse codegen.
Note: we also pattern match on 32x4Swizzle, which correctly generates
Change-Id: Ie3aca53bbc06826be2cf49632de4c24ec73d0a9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589062
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71754}
pextrq + movq crosses register files twice, which is not efficient.
Optimize this by:
- checking if lane 0, do nothing if dst == src (macro-assembler helper)
- use vmovhlps on AVX, with src as the operands to avoid false
dependency on dst
- use movhlps otherwise, this is shorter than shufpd, and faster on
older system
Change-Id: I3486d87224c048b3229c2f92359b8b8e6d5fd025
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589056
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71751}
Change the codegen for f32x4.extract_lane from shufps to insertps. They
have the same performance, but shufps has a false dependency on dst (it
shuffles dst and src, but we don't care about dst at all).
We then merge the SSE and AVX opcode.
Bug: v8:11217
Change-Id: I7cdbf486573ce3a19881df84400a9c7e09c3ee48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2585259
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71748}
Change the codegen for f32x4.extract_lane from shufps to insertps when
AVX is supported. They have the same performance, but shufps has a false
dependency on dst (it shuffles dst and src, but we don't care about dst
at all).
Also for SSE, extractps + movd crosses register files, so change it to
use insertps as well.
Change-Id: Idf45849d37ac3499bf3371ba2fa6ae05829aa8a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589048
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71747}
This is the same as the original implementation in https://crrev.com/c/2567534
which was speculatively reverted due to flaky tests. Since then, there have
been some changes to fix those tests, so trying to get this in again.
Bug: v8:11002
Change-Id: I5bd0f63d3aec4cf6db403b35737f8b695b0f4e37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589063
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71746}
This CL implements Liftoff support for struct.get/set,
struct.new_with_rtt, rtt.canon, and ref.is_null, which
is enough to make the first testcase pass.
Bug: v8:7748
Change-Id: Id09e9872d2126127192c852b3cb6d57ff9417582
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584951
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71744}
The original implementation of matching was a RegExp on the source
which wasn't able to reliably distinguish between comments inside
of string literals and actual comments. For that reason, it had
a special rule to disallow quotes to remove false positives.
Original comment:
> Also, ['"] are excluded from allowed URLs to avoid matches
> against sources that invoke evals with sourceURL.
After the code was moved into the scanner, that shouldn't be an
issue anymore - the scanner knows that this is a real comment and
isn't part of a string literal.
Allowing quotes enables a slightly smaller encoding of source maps,
specifically in the case where there are no sourceContents:
Non-base64 source maps can get away with effectively no encoding
overhead (they typically don't contain whitespace).
Change-Id: Iffa5df28d80656fa56e603e7c0e57aa1f44d0014
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2576801
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Jan Krems <jankrems@google.com>
Commit-Queue: Jan Krems <jankrems@google.com>
Cr-Commit-Position: refs/heads/master@{#71742}
Only process each LiveRangeBundle once in AssignSpillSlots().
Previously we would try to merge a LiveRangeBundle as many times as
there are LiveRanges inside it. Even though the merge would only happen
once, we would still iterate over all LiveRanges and do expensive checks
for each iteration.
R=sigurds@chromium.org
Bug: v8:11237
Change-Id: I9e613aaf5e571d4c28486dd2c20154336c533563
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584956
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71741}
This reverts commit 8ffbf0d299.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1158322
Original change's description:
> [TurboFan] Move SFI and BytecodeArray to kNeverSerialized
>
> This CL moves SharedFunctionInfo and BytecodeArray to the
> kNeverSerialized classes, making them directly accessible from the
> background thread.
>
> To resolve the dependence on HeapNumber and BigInt objects stored in
> the BytecodeArray's constant pool, this CL introduces a new
> ObjectDataKind::kPossiblyBackgroundSerializedHeapObject, which allows
> for objects to be serialized lazily from the background thread where
> we know that this is safe (e.g. because they are constant). BigInt and
> HeapNumber are the first members of this new group of objects.
>
> Bug: v8:7790
> Change-Id: I1d962d1cb7c36cc3f5baeb9603d5298f32af3363
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567705
> Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71716}
TBR=neis@chromium.org,nicohartmann@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7790
Change-Id: Ice35d7c1c4d7e96be887a0aa26fbfa69db627022
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589734
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71738}
Simd128Registers::names_ is also removed as the stringification
will be done by DEFINE_REGISTER_NAMES.
PPC FP and Vector Register (VR and VSR) Layou:
VR0 is VSR32 and goes all the way to VSR63 which is used by V8 Vector
operations.
VSR[0]0 - FPR[0] VSR[0]128
|
|
|
VSR[31] - FPR[31]
VSR[32] - VR[0] VR[0]128
|
|
|
V
VSR[63] - VR[31]
Change-Id: Ied2a530b08d1eb40af59ce44f848d638f2a6dc9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2587356
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71735}
Switch from an array of supported types to a switch over
type kinds, in preparation for user-defined reference types.
Bug: v8:7748
Change-Id: I17a0a71184ee0937748f07f22c1fd545a057fb6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584950
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71733}
Associate DeoptLogEntry with both, the function's source position and
the deopt location's source position.
Also fixes the list-panel click handler to support all clickable entry
types.
Bug: v8:10644, v8:10754
Change-Id: If10272a926d5dad10b29322e237610900715b9dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584955
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71732}
Drive-by cleanup: IWYU for macro-assembler-ia32.cc.
IWYU added src/heap/basic-memory-chunk.h which failed a presubmit, so I
updated src/DEPS to allow for including it.
Bug: v8:11217,v8:7490
Change-Id: I63662bfb2b34e354e94f6052edfcb92f1341da58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2583675
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71729}
Drive-by cleanup: IWYU for macro-assembler-ia32.h and
instruction-selector-ia32.cc
Ran using `iwyu_tool.py -p out/ia32.debug <filename>`, with a local
build of llvm and iwyu.
Bug: v8:11217,v8:7490
Change-Id: I4f8e95fa9be2f51f6764c994bb4da9ae86854c4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2583671
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71728}
PPC has a set of 64 Vector Registers called VSX.
The lower 32 of them are shared with Floating Point register (only
64 bit of the registers are used for FP operations).
The upper 32 registers are VR registers which are only used for
VMX Vector operations.
VSX Vector operations have the option to use the lower 32 or upper
32 registers using the TX bit set on the instructions. VMX operations
only use the upper 32 registers.
In V8 we always set the VSX TX bit to "1" to make sure all the vector
operations take place on the upper 32 registers.
Change-Id: Ib3ea03254cbdc9547c3b698fe19c0c6b28138741
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2585260
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71722}
This flag disables the implicit fallback to Turbofan when
Liftoff bails out due to an unsupported instruction/type.
Instead, Liftoff bailouts are treated as fatal errors.
This is meant for testing; it is not (yet?) a configuration
we support in production.
Change-Id: I04e2045f1976e202e65da0ba8e8d660c47859bf4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584949
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71721}
The rest of the code base was already migrated last year in
https://crrev.com/c/1631409. In the API we have to be more careful to
not break embedders. According to the standard there is no semantic
difference between typedef and using ([decl.typedef#2]):
A typedef-name can also be introduced by an alias-declaration. The
identifier following the using keyword becomes a typedef-name and the
optional attribute-specifier-seq following the identifier appertains
to that typedef-name. Such a typedef-name has the same semantics as if
it were introduced by the typedef specifier.
Thus this CL replaces all typedefs in include/v8.h by the equivalent
using declaration. This improves readability, especially for function
pointer types.
R=ulan@chromium.orgCC=leszeks@chromium.org
Bug: v8:11074
Change-Id: Id917b6aa5c8cd289c60bda5da1e3667e747936e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563880
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71719}
The name has very few uses. I found at least one where the current
value does not make sense (on js-to-wasm wrappers in profiling), but I
found zero uses that were actually useful.
Hence this CL removes the name, i.e. just sets none on wasm scripts.
R=thibaudm@chromium.org, yangguo@chromium.org
Bug: chromium:1125986
Change-Id: I2f793986a3da905980132cd09349dd6a1d787957
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584245
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71718}
This CL moves SharedFunctionInfo and BytecodeArray to the
kNeverSerialized classes, making them directly accessible from the
background thread.
To resolve the dependence on HeapNumber and BigInt objects stored in
the BytecodeArray's constant pool, this CL introduces a new
ObjectDataKind::kPossiblyBackgroundSerializedHeapObject, which allows
for objects to be serialized lazily from the background thread where
we know that this is safe (e.g. because they are constant). BigInt and
HeapNumber are the first members of this new group of objects.
Bug: v8:7790
Change-Id: I1d962d1cb7c36cc3f5baeb9603d5298f32af3363
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567705
Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71716}
I think this was likely fixed by one of the other bugfixes in the
meantime. It doesn't flake with 50k runs locally.
Fixed: v8:2008
Change-Id: I9e6f1e7f75cf20c52d49937d980aafacaa23b401
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584945
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71715}
The issue is with this pattern, assuming disjoint uses for all vregs:
phi: v1 = v0 ...
phi: v2 = v0 ...
phi: v3 = v0 ...
...
phi: vN = v0 ...
For every phi, BuildBundles proceeds as follows:
- Create a new bundle for the output
- Merge the input bundle into the output bundle
Since the bundle gets bigger at every iteration, the merges become more
and more expensive and consume Zone memory that is immediately thrown
away at the next iteration.
A simple fix is to check the size of the bundles before merging and
always copy the smallest one into the biggest. In the pattern above this
should always copy the single-range output bundle into the large input
bundle.
R=sigurds@chromium.org
Bug: v8:11237
Change-Id: I6ad9152035da698d94b02b5b41802545ba149307
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584879
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71714}
When Liftoff bails out, the function ExecuteLiftoffCompilation performs
an early return before updating the "counters" data structure with the
bailout reason. The early return was introduced in
https://chromium-review.googlesource.com/c/v8/v8/+/2423710.
We should just drop it again, as there is another
"if (did_bailout()) return" right after updating the counters.
Bug: v8:11259
Change-Id: Ia7f72c3a7eda4252a5a4450646427edb26130996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584880
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71713}
The gc_in_progress flag was reset to false only after sweeping was done.
As a result, if we call CollectGarbage during an incremental GC and
after marking has finished, the we will observe that a gc is still in
progress but will not have a marker and crash.
The immediate solution is to move resetting the gc_in_progress flag such
that it indicates whether we didn't have the atomic pause yet. That
means we could have gc_in_progress==false and incremental sweeping still
running, which semantically negates the meaning of gc_in_progress.
Observing that gc_in_progress essentially becomes equivalent to having a
marker, this CL removes the gc_in_progress flag and replaces checks on
it with checks on marker.
Bug: chromium:1156170
Change-Id: Ic4b441ec248b5f7e222e988870e46d5166dd4dcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584875
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71712}
Using the config of one of the builders that catched the chromium:1138115 issue; compile only.
Bug: chromium:1142484
Change-Id: I4ad19a7c32819a3a8306fa169d3c8ec0ffb47a8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584874
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71711}
Add a method that returns the microtask queue that is being used
by the `v8::Context`.
This is helpful in non-monolithic embedders like Node.js, which
accept Contexts created by its own embedders like Electron, or
for native Node.js addons. In particular, it enables:
1. Making sure that “nested” `Context`s use the correct microtask
queue, i.e. the one from the outer Context.
2. Enqueueing microtasks into the correct microtask queue.
Previously, these things only worked when the microtask queue for
a given Context was the Isolate’s default queue.
As an alternative, I considered adding a way to make new `Context`s
inherit the queue from the `Context` that was entered at the time
of their creation, but that seemed a bit more “magic”, less flexible,
and didn’t take care of concern 2 listed above.
Change-Id: I15ed796df90f23c97a545a8e1b30a3bf4a5c4320
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579914
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71710}
next_enumeration_index is the next free index available to store a
property. ObjectDescriptor tracks this field while instantiating the
literal and updates the next_enumeration_index when finalizing the
instantiation. When adding new properties (named / computed) we were
updating this value to the current value that is being used instead
of next free index. This cl fixes it.
Bug: chromium:1152231
Change-Id: Ica8c36dcabf035db559e29d4573ecd5e53d6062a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2577463
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71709}
movd/movq moves from/to 32/64 bit operand to xmm, the disasm was
incorrect printing both operands as xmm.
Was: "movd xmm2,xmm10"
Now: "movd xmm2,r10"
Change-Id: I4061257da763efd3493a3fd5875dc116296e1737
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2585258
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71708}
