This reverts commit c79a63e634.
Reason for revert: Needs addtl test skips: https://chromium-review.googlesource.com/c/1470124
Original change's description:
> [nojit] Don't expose wasm in jitless mode
>
> Wasm currently still creates executable memory even in
> interpreter-only mode, and is thus unsupported in jitless mode. This
> hides wasm completely, which will help e.g. fuzzers that attempt to
> run wasm code (and currently crash on the CHECK in AddOwnedCode).
>
> Bug: v8:7777,chromium:931068
> Change-Id: Iee692cb947d482ba16fb0f4da32490d42d5daef8
> Reviewed-on: https://chromium-review.googlesource.com/c/1470124
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59561}
TBR=mstarzinger@chromium.org,jgruber@chromium.org
Change-Id: Ic242db3efe73ef362e0f0c3efde90682db6de4a8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7777, chromium:931068
Reviewed-on: https://chromium-review.googlesource.com/c/1470131
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59570}
We'll let the bytecode compiler and optimizing compilers deal with dead code,
rather than the ast visitors. The problem is that the visitors previously
disagreed upon what was dead. That's bad if necessary visitors omit parts of
the code that the bytecode generator will actually visit.
I did consider removing the AST nodes immediately in the parser, but that
adds overhead and actually broke code coverage. Since dead code shouldn't be
shipped to the browser anyway (and we can still omit it later in the bytecode
generator), I opted for keeping the nodes instead.
Change-Id: Ib02fa9031b17556d2e1d46af6648356486f8433d
Reviewed-on: https://chromium-review.googlesource.com/c/1470108
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59569}
They did the same thing.
Change-Id: I6b63762352dae2dce58fb3a6182af52cd0aadef6
Reviewed-on: https://chromium-review.googlesource.com/c/1470126
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59566}
When an error occurs when storing the properties we either need to
throw or ignore the error depending on the language mode. We used
to infer the language mode from the type feedback vector. This cl
instead falls back to runtime to check and throw an error when
needed.
Bug: v8:8580
Change-Id: Iebeb3ca86d753157329dc1b5cfd1c07af2ff3dcd
Reviewed-on: https://chromium-review.googlesource.com/c/1458220
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59563}
Port c142e0a2b1
Original Commit Message:
Refactor the CallApiCallback builtin to
- pass the context as with other stubs, and
- pass holder and call data in registers.
This avoids having to place holder and call data onto the stack, and
thus makes it possible to easily call the CallApiCallback builtin from
other builtins while just forwarding the (stack) arguments. The idea
is to use this in the future to optimize the general case of calling
into any API method via a FunctionTemplateInfo and doing appropriate
security and/or interface checks upfront as necessary (eventually making
the HandleApiCall C++ builtin obsolete at some point).
R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ic6c246bb28a6affa6fe015c1207c773b375a2b30
Reviewed-on: https://chromium-review.googlesource.com/c/1470443
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59562}
Wasm currently still creates executable memory even in
interpreter-only mode, and is thus unsupported in jitless mode. This
hides wasm completely, which will help e.g. fuzzers that attempt to
run wasm code (and currently crash on the CHECK in AddOwnedCode).
Bug: v8:7777,chromium:931068
Change-Id: Iee692cb947d482ba16fb0f4da32490d42d5daef8
Reviewed-on: https://chromium-review.googlesource.com/c/1470124
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59561}
Since that condition doesn't depend on anything other than the SFI,
the IsInlineable method is the right place for checking it. This also
has the benefit that the condition will get checked earlier so that we
might avoid unnecessary work.
Bug: v8:7790
Change-Id: Ie92d4b72c6c524c5e8412701b88e88c9d73fa5bd
Reviewed-on: https://chromium-review.googlesource.com/c/1470061
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59559}
For macros expanding to function definitions, I removed the spurious ; after
macro invocations. For macros expandign to function declarations, I made the ;
required and consistently inserted it.
No behavior change.
Bug: chromium:926235
Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549
Reviewed-on: https://chromium-review.googlesource.com/c/1467545
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59558}
This removes most macros from the function body decoder unittest. It
makes the {Validate} method (and the new {ExpectValidates} and
{ExpectFailure}) templates, to receive the code in different formats.
Drive-by: Rename "verify" to "validate".
R=titzer@chromium.org
Bug: v8:8562
Change-Id: I89e6125b52cf40a9539317bf16189208cd0592ab
Reviewed-on: https://chromium-review.googlesource.com/c/1458956
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59557}
...by moving a special case into a separate method.
Change-Id: I880768ed6fbb7d29b94588435c9da65b01f07fde
Reviewed-on: https://chromium-review.googlesource.com/c/1462960
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59555}
Change-Id: I7716dab4d6d0ff582acdffb988a05429bccab2ad
Reviewed-on: https://chromium-review.googlesource.com/c/1462006
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59554}
We should just always get an Object in rather than both Object and Object*
where the former is dealt with through operator->.
Change-Id: I2d2542f37a357d4c410cc5f07c8e3563e66660b7
Reviewed-on: https://chromium-review.googlesource.com/c/1470104
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59553}
They didn't take the new premonomorphic state into account. My bad.
Bug: chromium:931424
Change-Id: I74ad1f0f8ce0eb764d63c2a3527e597962baca6d
Reviewed-on: https://chromium-review.googlesource.com/c/1470125
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59552}
Refactor the CallApiCallback builtin to
- pass the context as with other stubs, and
- pass holder and call data in registers.
This avoids having to place holder and call data onto the stack, and
thus makes it possible to easily call the CallApiCallback builtin from
other builtins while just forwarding the (stack) arguments. The idea
is to use this in the future to optimize the general case of calling
into any API method via a FunctionTemplateInfo and doing appropriate
security and/or interface checks upfront as necessary (eventually making
the HandleApiCall C++ builtin obsolete at some point).
Bug: v8:8820, chromium:913553
Change-Id: I10c0065016df4d0c24bac3d46945ea597b65ed02
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/1469821
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59551}
...mainly by moving two big chunks into separate methods.
Change-Id: I048a8d27c28bc171559190a915616efbebdfe6cc
Reviewed-on: https://chromium-review.googlesource.com/c/1462957
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59550}
Each page has a `live_byte_count_` field in its header and it is always accessed
with atomic operations. However, apart from one corner case, this field is only
accessed by the main thread so let's remove the atomicity by default.
To summarise, this changes the MarkingState accessors in the following way:
- IncrementalMarkingState:
Accesses of live_byte_count_ are now non-atomic. Concurrent marking uses local
maps of live bytes per page so we have exclusive access to the field when using
this.
- MajorAtomicMarkingState:
This accessor does not guarantee exclusive access to live_byte_count_ so we need
to keep the access atomic. This is used by the scavenger when migrating an
object that was marked black, since marking an object black will implicitly
increment the live_byte_count_.
Additionally, the live_bytes() and SetLiveBytes() accessor methods were not used
so remove them.
- MajorNonAtomicMarkingState:
Accesses of live_byte_count_ are not actually non-atomic.
- MinorNonAtomicMarkingState:
The `young_generation_live_byte_count_` field is atomic so we can set the memory
order manual to relax accesses.
Change-Id: I4c6457843783157ca878540e34ad50878afee20c
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1456095
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#59548}
- const return type on Full{,Maybe,Heap}ObjectSlot::operator*
- Removed stale friend declarations
- Moved a method to the right section
Bug: v8:8557
Change-Id: I0bd3efdb96a7d997b4404d3a247bea55b083d611
Reviewed-on: https://chromium-review.googlesource.com/c/1467781
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59546}
Sets an atomic field on each sampler when it requests a sample, to be
checked when the SIGPROF handler is executed. A counter is not used
since signals may be coalesced.
Prior to this change, all samplers attached to an isolate received
samples when other samplers sent SIGPROF to the VM thread. This change
alters the behaviour of different CpuProfiler instances on the same
isolate to be in line with the Windows / Fuchsia behaviour.
Bug: v8:8835
Change-Id: I0caaa845b596efc9d8b1cd7716c067d9a6359c57
Reviewed-on: https://chromium-review.googlesource.com/c/1468941
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59545}
The StackTraceFrame object will be used in a future CL to replace
StackFrameInfo as the object returned by the inspector API, as well
as the object used in the stack_frame_cache.
The object itself is a simple wrapper around a reference to a
FrameArray plus an index, as well as a reference to a
StackFrameInfo object that will get lazily initialized.
This is the first step towards unifying stack trace representation
and collection.
R=jgruber@chromium.org
Bug: v8:8742
Change-Id: Iefc7d734fd274ffd164ddf6f43c226531aa26d4c
Reviewed-on: https://chromium-review.googlesource.com/c/1458017
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59544}
This updates the type of contexts to NativeContext instead of Context,
namely on GetFunctionRealm(), GetCreationContext(), and
JSGlobalObject::native_context.
They should be semantically NativeContexts, but the return type hides
the underlying NativeContext, and causes its user to cast the context
to native.
Change-Id: I2f234b0df8c2dcaeab25cb543e09d80d12ca7369
Reviewed-on: https://chromium-review.googlesource.com/c/1469541
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59543}
This CL reuses the logic to determine if out of bounds loads should be allowed
to determine whether in bounds hole loads should be converted to undefined or
handled as IC misses.
bug: v8:8561
Change-Id: I1da859aba082cf21c67e7202b1e308ac4614b64a
Reviewed-on: https://chromium-review.googlesource.com/c/1465182
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59540}
Using test generators meant that we had to remove the progress indicator since
the total number of tests weren't known before-hand.
This CL implements a progress indicator using test number estimations.
cctest and unittests progress indicator is accurate, however estimating
means the progress will terminate over 100% in big test suites and sometimes
under 100%.
R=machenbach@chromium.org
CC=sergiyb@chromium.org,yangguo@chromium.org
Bug: v8:8769
Change-Id: I40ca5b40f9b1223376d33707f0945900ea98cea3
Reviewed-on: https://chromium-review.googlesource.com/c/1460471
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59538}
The previous change to JSCallReducer::ReduceCallApiFunction regressed
the case a bit where the optimized graph has some knowledge about the
receiver already, but the API callback didn't need any receiver checks,
as in that case we unnecessarily added a ConvertReceiver node. This
change refactors the code to first see if there's information in the
graph about the receiver, and only if none is found, introduce the
ConvertReceiver node.
It also removes the unnecessary context load from the target function,
since the API callback doesn't care about the concrete context, and
we never inline cross native contexts, so using whatever incoming
context we have is perfectly fine (and saves us from unnecessarily
materializing the target just to load the native context off of it).
Drive-by-fix: Remove bogus comment about CallApiCallbackStub parameters.
Bug: v8:8820
Change-Id: Ide1b283d9e448c3f0ae8f2daf4b1ad0202eae09e
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/1466881
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59536}
Testrunner test-suite doesn't have automated tests for the Fuzzer. A significant
change for the testrunner may break the fuzzers. We don't have a way to catch
even the syntax errors for the fuzzer before landing CLs.
This CL creates a rudimentary test-suite that runs the fuzzer without any tests
to see if APIs still work as intended.
R=machenbach@chromium.orgCC=yangguo@chromium.org,sergiyb@chromium.org
No-Try: true
Bug: v8:8763
Change-Id: Ib4519ca093de2af5279964edd164cee04aae77a8
Reviewed-on: https://chromium-review.googlesource.com/c/1466301
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59535}
Implemented branching and merging of Environments to facilitate handling of
conditional and unconditional jumps in the SerializerForBackgroundCompilation.
Added tests and printing helpers for the Environment. The internal structure
of the hints was changed to ZoneSet to support avoiding of duplicates.
Alternative implementation considerations were documented here:
https://docs.google.com/document/d/1vCQYhtFPqXafSMweSnGD8l0TKEIB6cPV5UGMHJtpy8k/edit?ts=5bf7d341#heading=h.jx4br0df5qzmR=neis@chromium.org
Bug: v8:7790
Change-Id: Ib929c75ddb7f7fb290a5ca28d4422680a1514a4f
Reviewed-on: https://chromium-review.googlesource.com/c/1451847
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59534}
... as there's no search involved and there are never multiple names.
Change-Id: Ice88c4d98195e74f6540926b0a1199df62b42da2
Reviewed-on: https://chromium-review.googlesource.com/c/1466645
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59532}
TypedArrayElementsInfo now represents an element's size as a log 2 and typed as
uintptr. This simplifies and speeds up (avoids possible HeapNumber allocations) a
number of calculations:
- Number of Elements (length) -> Byte Length - is now a WordShl
- Byte Length -> Number of Elements (length) - is now a WordShr
- Testing alignment (byte offset or length) - is now a WordAnd
These element/byte length related calculations are encapsulated in
TypedArrayElementsInfo as struct methods.
This reduces the size of CreateTypedArray by 2.125 KB (24%) on Mac x64.release:
- Before: 9,088
- After: 6,896
This improves the performance of the following microbencmarks
- TypedArrays-ConstructWithBuffer: ~87%
- TypedArrays-SubarrayNoSpecies: ~28%
Bug: v8:7161
Change-Id: I2239fd0e0af9d3ad55cd52318088d3c7c913ae44
Reviewed-on: https://chromium-review.googlesource.com/c/1456299
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59531}
Testrunner runs variants of a test sequentially without taking sharding into
account. A slow test with slow variants slows down the whole test run no matter
the sharding configuration.
This CL implements a test hashing algorithm and variant sharding for test
variants.
R=machenbach@chromium.orgCC=yangguo@chromium.org,sergiyb@chromium.org
Bug: v8:8174
Change-Id: I15f8c547fa2f361fb6c53bf8d5df055d3df38d3e
Reviewed-on: https://chromium-review.googlesource.com/c/1458016
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59530}
This CL contains the following changes:
(1) Allocate memory for WasmTables in the WasmInstance.
- We extend the WasmInstance by a FixedArray which stores
references to the WasmTables.
(2) Rename the name of the backing store of WasmTables from `functions`
to `elements`.
- The name `functions` just does not fit anyref tables.
(3) Generate code with TurboFan for table.get and table.set.
(4) Extend wasm-module-builder.js to be able to generate modules with
multiple tables.
(5) Add mjsunit tests to test table.get and table.set.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I44af4838ee7a37b394841a2f673ecae5734a4d1c
Reviewed-on: https://chromium-review.googlesource.com/c/1463519
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59529}
This reverts commit d8a457cbb7.
Reason for revert: I suspect that this caused the recent spike in the crashes on Canary. So, speculatively reverting this to see if things improve. More details on this bug: chromium:931181
Original change's description:
> [global-handles] Do not clear finalization callback on moving
>
> Bug: chromium:923361
> Change-Id: Id4a0f6515f6b17cec2732df561c1e82080dc29c8
> Reviewed-on: https://chromium-review.googlesource.com/c/1462963
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59498}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: Id4d2f49be2a6a913f51f35db9877c5b098f9e20a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:923361, chromium:931181
Reviewed-on: https://chromium-review.googlesource.com/c/1466646
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59527}
When calling API functions (i.e. Blink C++ DOM methods and accessors)
directly from TurboFan we currently only optimize that to a fast call
via the CallApiCallback builtin when TurboFan is able to find reliable
map information about the receiver in the graph. This is usually only
the case when the call is preceeded by a monomorphic or polymorphic
property access on the receiver, i.e. something like
```js
element.hasAttribute("bar");
```
will work, since the call to the `hasAttribute` method is immediately
preceeded by a `CheckMaps(element)` in the monomorphic/polymorphic case.
However this no longer works when the responsible LOAD_IC was
megamorphic or the method is called via `Function#call()` for example:
```js
const hasAttribute = Element.prototype.hasAttribute;
// ...
hasAttribute.call(element, "bar");
```
This change allows for more optimizations in two cases:
1. When the method accepts any receiver (i.e. no signature type and no
access checks needed), and
2. when we find information about the receiver in the graph, but that
information is not reliable.
For the first case, when the API method accepts any receiver and doesn't
limit it to specific types of receivers (aka no compatible receiver
check is required), we just insert a ConvertReceiver receiver and pass
the result as both the receiver and the holder to the API callback.
For the second case, we lift the current restriction of only supporting
reliable, stable receiver map information, because we only need to know
two things:
a. The Map::constructor field on the root map satisfies the compatible
receiver check.
b. If the receiver is a JSObject, then the "access check needed" bit
is not set (or the API method accepts any receiver).
Both of these cannot change with map transitions. So if at some point in
the past we knew that this held for a given receiver (by looking into
the TurboFan graph), we definitely know that it's still going to hold at
any later point.
Bug: v8:8820
Change-Id: I2316e8a4e2b3b7560e5c5d2b7d1569ebe1d3a1c8
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/1466562
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59526}
Most of the users of InNewSpace actually mean InYoungGeneration.
Subsequent CL will remove InNewSpace to avoid confusion.
Bug: chromium:852420
Tbr: mlippautz@chromium.org
Change-Id: I6234d162d51c215787972e7ada1cd5b804b60fda
Reviewed-on: https://chromium-review.googlesource.com/c/1463521
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59523}
This avoids confusion with the code that is being generated.
R=sigurds@chromium.org
Change-Id: Icb5bd417ca8502553af201654cca1419b9eac87d
Reviewed-on: https://chromium-review.googlesource.com/c/1462001
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59522}
containing smi value and untags it.
This CL finishes up the parity with x64 with regards to
(https://chromium-review.googlesource.com/c/v8/v8/+/1382740)
Bug: v8:7703
Change-Id: I3c88fbbfd3e47e944a6891171d6555f330cd5fd2
Reviewed-on: https://chromium-review.googlesource.com/c/1463523
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59521}
