- Removes workarounds in test-run-native_calls for ARM and
adds ARM 32-bit aliasing-aware register allocation.
- Uses wasm::LinkageAllocator instead of custom allocator to avoid
duplication of this logic.
- Fixes a problem in wasm::LinkageAllocator with high 16 VFP regs,
and makes member variable naming consistent.
Bug: v8:8015
Change-Id: Ie8bb8bad06bebce2cef3da0f6ad5c59d5f3b3b36
Reviewed-on: https://chromium-review.googlesource.com/1199907
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55696}
... like AllocatePage[s](), FreePages() and SetPermissions().
This CL also changes base::PageAllocator to cache AllocatePageSize and CommitPageSize
values returned by the OS.
This is a necessary cleanup before introducing BoundedPageAllocator.
Bug: v8:8096
Change-Id: Ifb7cdd2caa6a1b029ce0fca6545c61df9d281be2
Reviewed-on: https://chromium-review.googlesource.com/1209343
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55690}
Currently, neither IsSharedCrossOrigin nor IsOpaque is set for an empty
script. Hence an exception thrown from it (e.g., an exception thrown
from native promise implementation) is treated as an error with
blink::kNotSharableCrossOrigin. On the other hand, as the script is
empty, there is no meaningful URL attached, which means the
ExecutionContext's URL is used as the script's name in
blink::SourceLocation::FromMessage. In other words, it works virtually
as same as blink::kSharableCrossOrigin corresponding to
ScriptOriginOptions with IsSharedCrossOrigin set and IsOpaque unset.
With this CL, a ScriptOriginOptions with IsSharedCrossOrigin is set
and IsOpaque is not set is attached to the empty script, as a
preliminary step to deprecate kNotSharableCrossOrigin.
Bug: chromium:875153,chromium:876248
Change-Id: I39279a43994337329b8bd9d28b6ca29f0ac30d9c
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1201689
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55673}
This CL changes the call-site of SmiLexicographicCompare to a fast
c call instead of a runtime call. The runtime function is not deleted
as it is still used in InnerArraySort.
The test is also moved from mjsunit to cctest, to make removal of the
runtime function easier in the future.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: v8:7382
Change-Id: Ie961eeb094c13018e9ec28b68f7c444d7f889036
Reviewed-on: https://chromium-review.googlesource.com/1201587
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55642}
This is a reland of 1c48d52bb1.
It turned out that IterableToList doesn't always behave according to
the ES operation with the same name. Specifically, it allows holey arrays
to take its fast path, which produces an output array with holes where
actually "undefined" elements should appear.
This CL changes the version of IterableToList that is used for spreads
(IterableToListWithSymbolLookup) such that holey arrays take the slow path.
It also includes tests for such situations.
Original change's description:
> [interpreter] Add bytecode for leading array spreads.
>
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
>
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
>
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
>
> Bug: v8:7980
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}
Bug: v8:7980
Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1201882
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55639}
Corrected register calling syntax in assembler-s390.cc and
test-platform.cc.
Generate_CEntry in builtins-s390.cc expects return buffer to be
preserved in r2, but when built with clang r2 isn't preserved, which breaks
300+ tests. It is fixed by writing r2's value into r8 (preserved)
and loading the value back to r2 after the operation.
Change-Id: I184f0111944b6ad8c0ccc8b97407d702dd97d9d8
Reviewed-on: https://chromium-review.googlesource.com/1204530
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55631}
Since there is no `Value::IsInteger` method in the API, we in the
Node.js project are going to rely on what looks like an implementation
detail of the Integer class. It is currently possible to to call
`Integer::Value` on any Number and the value is cast to an integer.
This commit adds tests for this behavior.
Change-Id: I4de09e7c6e0beac7909e5477f7bfe2ed4c9415b9
Reviewed-on: https://chromium-review.googlesource.com/1200983
Commit-Queue: Michaël Zasso <mic.besace@gmail.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55629}
Utf*Characterstream caches the data pointer of ExternalStrings through
ExternalStringStream, so lock the strings in ExternalStringStream.
Bug: chromium:877044
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I241caaf64e109b33e2f9982573e11c514410509c
Reviewed-on: https://chromium-review.googlesource.com/1194003
Commit-Queue: Benoit L <lizeb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55613}
Also extend the API to reflect this new feature.
R=jgruber@chromium.org, szuend@google.com, ulan@chromium.org
Bug: v8:8125
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ic7a7604a8c663ba04b324eb8902ff325a25654e7
Reviewed-on: https://chromium-review.googlesource.com/1202087
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55604}
When v8_enable_embedded_bytecode_handlers is true, initialize the
bytecode dispatch table from the builtins table. Also stops creating
the handlers more than once as the SetupInterpreter will now always do
nothing even when not starting from a snapshot.
In the short term, with the flag enabled all the bytecode handlers are
eagerly deserialized.
Finally, the bytecode handlers are marked as non-isolate independent to
prevent them being embedded in the binary until they can be converted.
Bug: v8:8068
Change-Id: I9e5ef7f1dce1b2d11c7aa26526f06b53f8939697
Reviewed-on: https://chromium-review.googlesource.com/1188477
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55581}
This CL does two things: It adds a CSA helper to determine whether
the debug_execution_mode is kSideEffects. And it adds a runtime
function that exposes PerformSideEffectCheckForObject.
This will be needed for the Array.p.unshift Torque version.
R=jgruber@chromium.org
Change-Id: Idc1ae077956e0862e613a2c28af3f2cf4d5c3762
Reviewed-on: https://chromium-review.googlesource.com/1196362
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55577}
This reverts commit 1c48d52bb1.
Reason for revert: Clusterfuzz found something.
Original change's description:
> [interpreter] Add bytecode for leading array spreads.
>
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
>
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
>
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
>
> Bug: v8:7980
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}
TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com
Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7980
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1199303
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55544}
The %GetPrototype runtime function is not used anymore. Also remove the
cctests that were introduced to guard the Crankshaft optimizations for
the %_GetPrototype intrinsic.
Bug: v8:8015
Change-Id: I4b848f2c8d67209dae002d260a26867299d6b4a5
Reviewed-on: https://chromium-review.googlesource.com/1199106
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55541}
We have an API (GetCodeRange) which gives the location of V8 code on the
heap, but builtin code no longer lives on the heap.
The upcoming work on the V8 stack unwinder requires the embedder to
provide the code ranges for both the heap and builtins, so this API will
be used there.
Bug: v8:8116
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I15e900716e68256b9732be0ea1a5cda24878eccf
Reviewed-on: https://chromium-review.googlesource.com/1196551
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55532}
This CL improves the performance of creating [...a, b] or [...a].
If the array literal has a leading spread, this CL emits the bytecode
[CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
is implemented by [IterableToListDefault] builtin to create the initial
array for the leading spread. IterableToListDefault has a fast path to
clone efficiently if the spread is an actual array.
The bytecode generated is now shorter. Bytecode generation is refactored
into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
from this optimization also.
For now, turbofan also lowers the bytecode to the builtin.
The idiomatic use of [...a] to clone the array a now performs better
than a simple for-loop, but still does not match the performance of slice.
Bug: v8:7980
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
Reviewed-on: https://chromium-review.googlesource.com/1181024
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#55520}
The AtomicNarrow operations are currently used for wider 64-bit
operations, that only operate on 32-bits of data or less
(Ex:I64AtomicAdd8U). Removing these because this can be handled
in int64-lowering by zeroing the higher order node.
Explicitly zeroing these in code-gen is not
required because -
- The spec requires only the data exchange to be atomic, for narrow
ops this uses only the low word.
- The return values are not in memory, so are not visible to other
workers/threads
BUG:v8:6532
Change-Id: I90a795ab6c21c70cb096f59a137de653c9c6a178
Reviewed-on: https://chromium-review.googlesource.com/1194428
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55499}
This CL additionally uses IsInRange for token range checks. That only uses one
branch rather than two.
Change-Id: I52c6759ba195b55cb50c2ce9afbdc9b397495633
Reviewed-on: https://chromium-review.googlesource.com/1193875
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55494}
{ThreadInWasmScope} in only used in a single location, which is in a
test. It does not look like many more such places will show up.
R=titzer@chromium.org,
Bug: v8:8015
Change-Id: I89f6f7e2bd13e2882e65f7657d73ba59a6c71757
Reviewed-on: https://chromium-review.googlesource.com/1193446
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55486}
The SharedFeedbackSlot helper class allow bytecodes to share one feedback
slot. The helper will only create the slot on-demand, at the first-use.
This does not encapsulate the use-case of FeedbackSlotCache.
Change-Id: I22aec19d59e52e7395898fa2a59c5c1ec95abbe8
Reviewed-on: https://chromium-review.googlesource.com/1189904
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55452}
This CL re-implements Array.p.lastIndexOf in Torque. The implementation
consists of a generic baseline path and a fast-path for JSArrays with fast
ElementsKinds.
Sparse support for JSArrays was removed.
Bug: v8:7624
Change-Id: I6ae877aaf99fa97a91763b3d60a0ee05623ab085
Reviewed-on: https://chromium-review.googlesource.com/1190345
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55451}
Currently chunked and streaming character streams don't have cloning support as this
requires additional changes on the Blink side.
BUG=v8:8041
Change-Id: I167b3b1cd5ae1ac4038f3715b6a679d3e65d9a85
Reviewed-on: https://chromium-review.googlesource.com/1183429
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55444}
"short" external strings are not short, they mean that the external data
pointer is not cached. Rename the various classes and objects to align
with the actual meaning.
Bug: chromium:877044
Change-Id: Ie3d5baa9ad352ac6ca89f5ba1d066760825e4beb
Reviewed-on: https://chromium-review.googlesource.com/1185192
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Benoit L <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55432}
This patch disables the conditions that cause the test to flake, but
as a band-aid that doesn't fix the underlying issue.
Bug: v8:8084
Change-Id: I46380d0ce4f450c176583330ed760bc3b57b9edc
Reviewed-on: https://chromium-review.googlesource.com/1189822
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55426}
This CL changes a constant pool test to include tests for the marker
and the encoded pool size.
Change-Id: Ia5cfd173e5d523a02252fd3b14f302e5c8994881
Reviewed-on: https://chromium-review.googlesource.com/1186626
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55423}
- Implement all the I64Atomic operations on ARM
- Change assembler methods to use Registers instead of memory operands
- Move atomics64 test up be tested on all archs, disable tests on MIPS
BUG:v8:6532
Change-Id: I91bd42fa819f194be15c719266c36230f9c65db8
Reviewed-on: https://chromium-review.googlesource.com/1180211
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55416}
This method introduces an inherent race because it allows changing
global static flag variables from concurrently running Isolates (or
Workers). Since there are not too many use-cases left, the method in
question can be removed entirely.
R=hpayer@chromium.org
Change-Id: I9798730dd775b04f0bc83f18ed5982672e76e5d5
Reviewed-on: https://chromium-review.googlesource.com/1186731
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55392}
Add location information in heap snapshot for objects where the
constructor can be determined.
Bug: chromium:854097
Change-Id: Ieb2ab70a65809ecc9dfa0d73a33fa57add430465
Reviewed-on: https://chromium-review.googlesource.com/1179156
Commit-Queue: Dominik Inführ <dinfuehr@google.com>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55387}
Builtin functions were being logged via both LogCodeObjects and
LogCompiledFunctions. The latter assumes the code in question has a
Name and so would end up logging an unattributable entry. This patch
stops logging that entry.
Bug: v8:8061
Change-Id: Iebc9bfa9618986afdbf8b1b71b64bf17a1f4196a
Reviewed-on: https://chromium-review.googlesource.com/1184923
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55379}
This is a reland of b10a967f4b
Original change's description:
> [wasm] Add feature counter for threads and shared memory
>
> This adds a feature counter for WASM shared memory (i.e. the presence
> of the "shared" bit in a WASM module's memory section) and the usage
> of WASM threads opcodes (i.e. wake/wait and atomics).
>
> This CL also plumbs the WasmFeatures through the compilation pipeline
> to detect features as functions are being compiled.
>
> R=ahaas@chromium.org, ulan@chromium.org
> BUG=chromium:868844
>
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
> Change-Id: I854f932d3adb16e4fd87196fe2a193950295b856
> Reviewed-on: https://chromium-review.googlesource.com/1186329
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55337}
Bug: chromium:868844
Change-Id: Iac3a38d80fa71aadd7147704669a8fd671ecfae8
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1186343
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55363}
The WasmCompilationData was a struct that served as an input/output
mechanism for communicating with the code generator. In particular,
it contained a flag for enabling runtime exception for WASM in the code
generator and it also gathered the protected instruction info from
the code generator to be communicated to the WasmCodeManager.
This CL inlines the exception support flag into OptimizedCompilationInfo
and the protected instruction information into the code generator,
along the lines of other flags and data structures created by the
code generator.
R=mstarzinger@chromium.org
Change-Id: If436636067f1a829a095310a73045fe3301cb694
Reviewed-on: https://chromium-review.googlesource.com/1186409
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55358}
No need to create allocation site for array literals in oneshot code since
they are executed only once. The interpreter emits a runtime call to
CreateArrayLiteralWithoutAllocationSite for creating literals in
oneshot code instead.
Change-Id: I285879c84759ff9e2ce281e9548112f52ce5e7d1
Reviewed-on: https://chromium-review.googlesource.com/1167843
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#55349}
This reverts commit b10a967f4b.
Reason for revert: Breaks a TSAN bot - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/22122
Original change's description:
> [wasm] Add feature counter for threads and shared memory
>
> This adds a feature counter for WASM shared memory (i.e. the presence
> of the "shared" bit in a WASM module's memory section) and the usage
> of WASM threads opcodes (i.e. wake/wait and atomics).
>
> This CL also plumbs the WasmFeatures through the compilation pipeline
> to detect features as functions are being compiled.
>
> R=ahaas@chromium.org, ulan@chromium.org
> BUG=chromium:868844
>
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
> Change-Id: I854f932d3adb16e4fd87196fe2a193950295b856
> Reviewed-on: https://chromium-review.googlesource.com/1186329
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55337}
TBR=ulan@chromium.org,titzer@chromium.org,ahaas@chromium.org
Change-Id: Id011b6707b3359598621b315b87171644132b0ab
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:868844
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1186421
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55340}
This adds a feature counter for WASM shared memory (i.e. the presence
of the "shared" bit in a WASM module's memory section) and the usage
of WASM threads opcodes (i.e. wake/wait and atomics).
This CL also plumbs the WasmFeatures through the compilation pipeline
to detect features as functions are being compiled.
R=ahaas@chromium.org, ulan@chromium.org
BUG=chromium:868844
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I854f932d3adb16e4fd87196fe2a193950295b856
Reviewed-on: https://chromium-review.googlesource.com/1186329
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55337}
This reverts commit 7dc828b256.
Reason for revert: breaks no-i18n build:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20noi18n%20-%20debug/22340
Original change's description:
> Stop logging Builtin functions as LazyCompile.
>
> Builtin functions were being logged via both LogCodeObjects and
> LogCompiledFunctions. The latter assumes the code in question has a
> Name and so would end up logging an unattributable entry. This patch
> stops logging that entry.
>
> Bug: v8:8061
> Change-Id: I20e5a853b8a214a91191fa644083bac7af9dc2c4
> Reviewed-on: https://chromium-review.googlesource.com/1177759
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Bret Sepulveda <bsep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55302}
TBR=bsep@chromium.org,jgruber@chromium.org,petermarshall@chromium.org
Change-Id: I27e1ed75fea95914640f9618b1fd0c1fd7d8f6a7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8061
Reviewed-on: https://chromium-review.googlesource.com/1184981
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55305}
Builtin functions were being logged via both LogCodeObjects and
LogCompiledFunctions. The latter assumes the code in question has a
Name and so would end up logging an unattributable entry. This patch
stops logging that entry.
Bug: v8:8061
Change-Id: I20e5a853b8a214a91191fa644083bac7af9dc2c4
Reviewed-on: https://chromium-review.googlesource.com/1177759
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55302}
