This function was functionnaly equivalent to FreeList::TryFindNodeIn.
They probably were different when FindNodeIn was iterating through
the empty FreeListCategories, but since CL 1648476, FreeListCategories
in the FreeList can't be empty, and there was therefore never more than
a single iteration of FindNodeIn's while loop.
Bug: v8:9329
Change-Id: Ief7275ef55edb46b8bb35bce0783fbfd28534925
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660615
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62233}
This CL allows CsaLoadElimination to retain some information in the presence of StoreToObject nodes. Two stores to an object don't alias if either the objects or the offsets don't alias. The analysis approximates either of these two conditions conservatively as follows:
- Freshly allocated, distinct objects cannot alias.
- Two objects cannot alias if one of is freshly allocated and the other was passed as a parameter or is a heap constant.
- Two offsets cannot alias if they are both constant and distinct from each other.
R=jarin@chromium.org, tebbi@chromium.org
Change-Id: Ibec81913b413f81a3f7cbd40544a22d3711e6e5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660626
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62232}
This reverts commit 0c5479df6d.
Reason for revert: Turns out there is a simpler way to do this.
Original change's description:
> [Turbofan] Make JSCallReducer::ReducePromiseConstructor concurrent
>
> The only piece missing at this point was to serialize the code
> objects for the resolve and reject handlers.
>
> Bug: v8:7790
> Change-Id: If636f9d74dfc9606cf5f45c4f02dd118fb5d8f00
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662295
> Commit-Queue: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62215}
TBR=mvstanton@chromium.org,jarin@chromium.org
Change-Id: Ie67326c850623eede8a63b50c5705682db784212
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664052
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62231}
Rolling v8/build: 8ef7aaa..be684b6
Rolling v8/buildtools: 6ae683b..6f3775a
Rolling v8/buildtools/linux64: git_revision:8c7f49102234f4f4b9349dcb258554675475e596..git_revision:81ee1967d3fcbc829bac1c005c3da59739c88df9
Rolling v8/third_party/android_sdk/public: ki7EDQRAiZAUYlnTWR1XmI6cJTk65fJ-DNZUU1zrtS8C..xhyuoquVvBTcJelgRjMKZeoBVSQRjB7pLVJPt5C9saIC
Rolling v8/third_party/android_sdk/public: iIwhhDox5E-mHgwUhCz8JACWQCpUjdqt5KTY9VLugKQC..ppQ4TnqDvBHQ3lXx5KPq97egzF5X2FFyOrVHkGmiTMQC
Rolling v8/third_party/android_sdk/public: 4Y2Cb2LGzoc-qt-oIUIlhySotJaKeE3ELFedSVe6Uk8C..MSnxgXN7IurL-MQs1RrTkSFSb8Xd1UtZjLArI8Ty1FgC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2e4b470..f6c289d
Rolling v8/third_party/depot_tools: bc23ca1..2313020
Rolling v8/third_party/googletest/src: 076b7f7..d700357TBR=machenbach@chromium.org,sergiyb@chromium.org,tmrts@chromium.org
Change-Id: Ibee14c27a78dbb0c30494bdac8d663a61dc9535d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662979
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#62230}
This change removes the special case in the Torque compiler for types
that descend from JSObject: they will no longer get implicit
"| Undefined" appended to their types for verification purposes. It
removes any additional custom verification steps in objects-debug that
are made redundant by that change.
In order to do so safely, I categorized all cases where we were
implicitly adding "| Undefined" to the field type, as follows:
1. Classes that aren't using the generated verifier function (we should
probably revisit these, but for now we at least know they're safe):
- JSGlobalObject
- JSFinalizationGroup
- JSFinalizationGroupCleanupIterator
2. Classes where the existing verifier is already at least as strict as
what we would get after removing the implicit "| Undefined":
- JSDate
- JSPromise
- JSRegExp
- JSRegExpStringIterator
- WasmMemoryObject
- JSWeakRef
- JSStringIterator
- WasmExceptionObject
- JSListFormat (fixed in part 1)
- JSPluralRules (fixed in part 1)
- JSRelativeTimeFormat (fixed in part 1)
- JSSegmenter (fixed in part 1)
- JSArrayBufferView (fixed in part 1)
- JSTypedArray (fixed in part 1)
3. Classes where, to the best of my knowledge based on code inspection,
we already initialize the object correctly to pass the new stricter
generated verifier:
- JSFunction
- JSArrayIterator
- JSMessageObject
- JSBoundFunction
- JSAsyncFromSyncIterator
- WasmModuleObject
- JSAsyncFunctionObject
4. Classes that needed some adjustment to their initialization order to
avoid exposing uninitialized state to the GC:
- JSArray (only in Factory::NewJSArray; Runtime_NewArray and
CodeStubAssembler::AllocateJSArray already behave fine)
- WasmTableObject
- JSDateTimeFormat
- JSNumberFormat
- JSCollator
- JSV8BreakIterator
- JSLocale
- JSSegmentIterator
- JSModuleNamespace
5. Classes that had incorrect type definitions in Torque:
- WasmGlobalObject (category 4 after correction)
6. Classes that weren't fully initialized due to bugs:
- JSGeneratorObject
- JSAsyncGeneratorObject
Bug: v8:9311
Change-Id: I99ab303d3352423f50a3d0abb6eb0c9b463e7552
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654980
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62228}
This in in preparation for generic (off-heap/on-heap) bytecode
array accessor.
Bug: v8:7790
Change-Id: Ib419831ba1db95ab938179723ef5f130f01ae0d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635895
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62222}
which was probably added by mistake.
Change-Id: Iba265309710115aae8d9a0b7c0ede7e0160a662a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662302
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62220}
Extract tests related to array buffers and typed arrays to their own
.cc files.
R=mstarzinger@chromium.org
Change-Id: Ic80205d02b62db1565670ecf2bb4c0dbe52fab49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662301
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62219}
This further reduces the number of things declared in the public
regexp API file, currently still named jsregexp.h.
* Move JSRegExp::Flags convenience functions to regexp-compiler.h.
* Set RegExpImpl methods private if possible (these will later be
moved to a new hidden impl class).
* Merge RegExpEngine::CompilationResult into RegExpCompileData.
* Move remaining RegExpEngine methods to RegExpImpl and delete
RegExpEngine.
* Extract RegExpGlobalCache.
* Document a few data structures.
Upcoming CLs will rename RegExpImpl to RegExp and jsregexp.h to
regexp.h. This should then be the only header included from other
directories.
Bug: v8:9359
Change-Id: I78c8f4cca495a2b95735a48b6181583bc3310bdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662294
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62218}
Rename LargeObjectIterator to LargeObjectSpaceObjectIterator.
Rename SemiSpaceIterator to SemiSpaceObjectIterator.
Rename CombinedHeapIterator to CombinedHeapObjectIterator.
Rename ReadOnlyHeapIterator to ReadOnlyHeapObjectIterator.
Rename HeapIterator to HeapObjectIterator.
Rename HeapObjectIterator to PagedSpaceObjectIterator.
Rename PagedSpaces to PagedSpaceIterator.
Bug: v8:9183
Change-Id: If4bd65d81e50bb45d207a897baaca8b723e4f10b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645914
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Cr-Commit-Position: refs/heads/master@{#62217}
The only piece missing at this point was to serialize the code
objects for the resolve and reject handlers.
Bug: v8:7790
Change-Id: If636f9d74dfc9606cf5f45c4f02dd118fb5d8f00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662295
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62215}
Previously only AssemblerOptions created by AssemblerOptions::Default()
could have inline_offheap_trampolines set to true.
This fixes OutOfLineTruncateDoubleToI from generating calls via the
DoubleToI trampoline.
Bug: v8:9338
Change-Id: Ia4638cd185e9041c7c69996783d0ce5600e9723a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662288
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62213}
We have too many dupes in the no-ic comparisons. We'll increase the
experiment size again once bugs are fixed.
TBR=jarin@chromium.org
NOTRY=true
Bug: chromium:961709
Change-Id: Ic946100b45fd73e1bee59f188a766384836bcdcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660624
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62212}
This reverts commit ac79b539ec.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/18611
Original change's description:
> [arm64] Refactor constant pool implementation
>
> This refactors the constant pool handling for arm64. The immediate goal
> is to allow 32bit compressed pointers in the pool. The mediate goal is
> to unify the implementation with the arm constant pool, which will be
> done in a follow-up CL.
>
> Bug: v8:8054
> Change-Id: I74db4245e5e1025f2e4de4144090fa4ce25883ab
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645316
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62209}
TBR=mstarzinger@chromium.org,sigurds@chromium.org,jgruber@chromium.org,georgia.kouveli@arm.com
Change-Id: Iff03e81a2e70d125ef2c06b6ff3aff8d0e3688ef
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8054
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662293
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62211}
This adds preliminary support for storing constructed WebAssembly
functions in tables. Note that for now only tables at index #0 are
supported, extending it to other tables indexes will be done as a
follow-up.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I9aa07813e07f0ceb4eafe37af412b45c7d235722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1640209
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62210}
This refactors the constant pool handling for arm64. The immediate goal
is to allow 32bit compressed pointers in the pool. The mediate goal is
to unify the implementation with the arm constant pool, which will be
done in a follow-up CL.
Bug: v8:8054
Change-Id: I74db4245e5e1025f2e4de4144090fa4ce25883ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645316
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62209}
The functions
* JSCallReducer::ReducePromisePrototypeThen
* JSCallReducer::ReducePromisePrototypeFinally
* JSCallReducer::ReducePromisePrototypeCatch
need the prototype for all receiver maps to be serialized in order
to take effect. We can do this by processing our receiver hints
when processing a builtin call in the serializer.
Bug: v8:7790
Change-Id: I3d9144924cf6926cfcd93b60ac703cfba2d3d93a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660623
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62208}
In the existing code, whenever unreachable control instructions needed
values from the stack which were not available, values of type kWasmVar
were put on the stack. When these values were type-checked the first
time, the expected type was assigned to them for later validation. This
behavior has several draw-backs:
* In an unobservable way, this implementation does not match the
requirements of the spec. With the anyref proposal, this difference
becomes observable.
* Type checking functions were not read-only anymore, because if
unreachable code was validated, the stack got manipulated in these
functions.
With the refactoring, I pulled out the handling of unreachable code
out of the type checking functions. These checking functions can be
validation-only functions.
For type checking unreachable code, I start by popping values of the
expected types off the stack. Thereby all available values on the stack
get type-checked. Afterwards, I push all values again on the stack with
the expected type if needed. This allows to continue the expected type
checking for later instructions.
R=clemensh@chromium.org
Bug: v8:7581
Change-Id: Ib98e70a44bf9780626d4aa8a3e5fe8c2f230b787
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645328
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62203}
RegExp assertions (e.g.: '^', '$', '\b', ...) sequences have certain
properties that this rewriter exploits:
1. They are zero-width and order-independent, thus one can remove all
duplicate assertions.
2. If a subsequence is guaranteed to fail, the entire sequence fails.
Any sequence always known to fail (e.g. containing both '\b' and '\B')
can be rewritten to a single node that triggers failure.
This CL generalizes the previous optimization for repeated assertions
to be order-independent, i.e. assertions only have to be in the same
sequence but not next to each other.
Bug: v8:6515, v8:6126
Change-Id: I3f92f081ce8a55ad8c34c269a09a6686e3b008f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657925
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62201}
Port 7b48dd55https://crrev.com/c/1648155
Original Commit Message:
This changes Generate_ContinueToBuiltinHelper to generate code to load
the builtin address directly from the builtins table rather than going
via the executable code in the trampoline's code object.
The set up for Generate_ContinueToBuiltinHelper is changed so that the
builtin index is stored on the stack in place of the builtin Code
object which is no longer needed.
Change-Id: I1c8a5a18ac998b16d84556f08637b32d758f44da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1659992
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Yu Yin <xwafish@gmail.com>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62199}
New revision: 83b1154a9661d22bba9a368d368214cc20880419
This updates the usages of the protocol types to the new
definitions, using std::vector-based implementations
of protocol::Array.
Change-Id: Ibb095862fed7db23f1a0b4b5b726bddbe1e2585e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654091
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62194}
In the JSCallReducer, we need to serialize prototypes of receiver
maps in order to verify that they are the promise prototype.
Bug: v8:7790
Change-Id: Ie9817e531b7faaa3f11dae61a120b46ef5c49847
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660487
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62191}
... since decompression customization for MapWord is already
handled by HeapObject::MapField.
Bug: v8:9353, v8:9183
Change-Id: I009cdbbf8fc7e72029e1b9be54a0f0b73050e738
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660475
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62188}
Port 7b48dd55e1
Original Commit Message:
This changes Generate_ContinueToBuiltinHelper to generate code to load
the builtin address directly from the builtins table rather than going
via the executable code in the trampoline's code object.
The set up for Generate_ContinueToBuiltinHelper is changed so that the
builtin index is stored on the stack in place of the builtin Code
object which is no longer needed.
R=delphick@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ie696468685517333515bf4b0b78fdd7d8c4e7763
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660628
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#62187}
This extends the existing Isolate::SetAllowCodeGenerationFromStringsCallback
mechanism, by adding SetModifyCodeGenerationFromStringCallback, which
can also modify the eval argument (it could e.g. add escaping).
Bug: chromium:940927
Change-Id: I2b72ec2e3b77a5a33f428a0db5cef3f9f8ed6ba2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593336
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62185}
