We don't use StatsCounters anymore for heap work, and this particular
counter causes issues for OffThreadSpace, as it can trigger a
non-thread-safe counter callback.
We could instead make this a thread-safe counter, but since it's unused
we may as well just remove it entirely.
Bug: chromium:1011762
Change-Id: I5af5ec5c408691ebfb762d87334ec4af54b1c0e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126914
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67340}
This change allows Torque code to initialize bitfield structs, using the
same syntax as struct initialization. It also moves the definition of
the JSPromise flags to Torque as an example usage.
Bug: v8:7793
Change-Id: I3d5e49aa22139ffb4b8ea9f308dd36a2d22b2c1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148176
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67338}
Introduce an OffThreadTransferHandle (and OffThreadTransferMaybeHandle),
which points to a piece of storage known to (and owned by) the
OffThreadIsolate. On Publish, the OffThreadIsolate converts this storage
stub from a raw pointer to an off-thread object into a main-thread
Handle.
This allows users of an OffThreadIsolate to not have to worry (as much)
about the dance of saving raw object pointers before off-thread finishes
and converting those to Handles before it off-thread isolate is
published.
Bug: chromium:1011762
Change-Id: I7ceb4ed85e770bd6e1867649188597bbcaedb32d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161066
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67337}
This CL handlifies the result of the Wait method to avoid possible
pointer invalidation caused by a call to RunAtomicsWaitCallback.
Bug: v8:9986
Change-Id: Iafb5d84ce372df3d75e408cfec73153b9f552493
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161069
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67336}
Now that PartialSerializer/Deserializer/etc have been renamed to
ContextSerializer/ContextDeserializer/etc, the files can now be renamed
hopefully leaving the full history available in code search.
Bug: v8:10416
Change-Id: I266c915f6d01a7e2913c4d34d9913fa551046dc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144061
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67333}
Make --stress-background-compile a V8 flag rather than a d8 flag, so
that it also tests unittests/cctests.
Now, with this flag, every top-level script compile (that fulfills a
couple of restrictions) will be both main-thread and background-thread
compiled, taking the result of the background compile. In the future,
we'll probably want to verify that the two results are equivalent.
One of the necessary changes to allow tests to pass was to introduce a
concept of a "temporary" script (with a temporary script id), which
doesn't get added to the script list. This is to avoid the main-thread
compile part of the stress-test having a debugger-visible side-effect,
e.g. in tests that enumerate scripts. We can't just create new ids for
such scripts, as then script-id expectation files no longer match.
Bug: chromium:1011762
Change-Id: I500bbf2cabea762e69aca3dbae247daae71192cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120541
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67332}
Move the persistent compilation state and Isolate inputs (such as the
allocator, shared AST constants, hash seed, logger, etc.) which survives
across both parse and compile, out of ParseInfo and into a new
UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState
for per-thread state such as stack limit and RCS.
In particular, this new state survives the ParseInfo being destructed,
which means it is available after off-thread finalization. This allows a
followup to access the PendingCompilationErrorHandler after finalization
and report errors on merge.
Bug: v8:10314
Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67329}
Before ES2015, the ES spec had a [[Class]] internal slot for all
objects, which Object.prototype.toString() would use to figure the
returned string. Post-ES2015, the [[Class]] slot was removed in spec for
all objects, with the @@toStringTag well-known symbol the proper way to
change Object.prototype.toString() output.
At the time, spec-identical handling without the use of [[Class]] was
implemented in V8 for all objects other than API objects, where issues
with the Web IDL spec [1] prevented Blink, and hence V8, to totally
migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
@@toStringTag on API class prototypes to manage the
Object.prototype.toString() output, so the legacy [[Class]] handling in
V8 has not been necessary for the past couple of years.
This CL removes the remaining legacy [[Class]] handling in
Object.prototype.toString(), JSReceiver::class_name(), and
GetConstructorName(). However, it does not remove the class_name field
in FunctionTemplateInfo, as it is still used for the `name` property of
created functions.
This CL also cleans up other places in the codebase that still reference
[[Class]].
This change should have minimal impact on web-compatibility. For the
change to be observable, a script must do one of the following:
1. delete APIConstructor.prototype[Symbol.toStringTag];
2. Object.setPrototypeOf(apiObject, somethingElse);
Before this CL, these changes will not change the apiObject.toString()
output. But after this CL, they will make apiObject.toString() show
"[object Object]" (in the first case) or the @@toStringTag of the other
prototype (in the latter case).
However, both are deemed unlikely. @@toStringTag is not well-known
feature of JavaScript, nor does it get tampered much on API
constructors. In the second case, setting the prototype of an API object
would effectly render the object useless, as all its methods (including
property getters/setters) would no longer be accessible.
Currently, @@toStringTag-based API object branding is not yet
implemented by other browsers. This V8 bug in particular has been an
impediment to standardizing toString behavior. Fixing this bug will
unblock [3] and lead to a better Web IDL spec, and better toString()
compatibility for all.
[1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
[2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
[3]: https://github.com/heycam/webidl/pull/357
Bug: chromium:793406
Cq-Include-Trybots: luci.chromium.try:linux-rel
Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67327}
Load splat opcodes are currently multi-byte, but were not passing the
right lengths for decoding of immediates.
Bug: v8:10258
Change-Id: I2c93c3f915eaa43a74722cf0285f161d16ef0ff6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154769
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67326}
The multi-value repository was removed from the list of repositories we
pull in update-wasm-spec-tests.sh. But the tarball still contains some
multi-value tests which should be removed.
R=ahaas@chromium.org
Change-Id: Ifb96a105c95d09f202a0f23ba50cddaa7ced494b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161074
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67323}
Test needs to be removed as discussed under
https://crrev.com/c/2099445.
Change-Id: If026b54ba5d27aea23cb62fe11688d86bcee9df2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161388
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67322}
There's no reason for it to be a JSArray; it's an internal data member.
We only have a slow version for constructing a FixedArray from an
Iterable, but since this is not a performance critical code path,
it's fine.
BUG=v8:9808
Change-Id: I5bcfac4cc545880966421a96d3aa3d899bbf6cd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157371
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67321}
We are getting the following error due to int overflow:
test/cctest/test-code-stub-assembler.cc:3868:28: warning: integer overflow in expression [-Woverflow]
factory->NewNumber(2 * kSmiMaxValue),
~~^~~~~~~~~~~~~~
Change-Id: I85b14a5c500b977febcfe7921bea9b25631a9912
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2160355
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67320}
These are almost unused, except for 1 case of Bit, which is probably
incorrect. These static helpers can cause subtle error, e.g.
instr->Bit(1, 3) does not get you bits 1 to 3, but rather calls the
static method Bit(Instr, int).
An example of this bug was fixed in https://crrev.com/c/2157799.
Change-Id: I98c4464c4315af48b9d36472ffd6f16aa74aa18b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158824
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67315}
read_prefixed_opcode() can fail; we must check for that case
before using the value it returned.
Bug: chromium:1073356
Change-Id: Ic213bd296e9c50dbffd5df8bc94ef0e7695d75a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161068
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67314}
The multi-value proposal is now merged in the main spec repository, so:
- Remove everything that references the multi-value spec repository
- Add --experimental-wasm-mv to the default flags
R=ahaas@chromium.org
Change-Id: I9f809c21404bb5c1d21eb330748ea51a15688546
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153219
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67313}
- implemented as a single-linked list with head and tail
pointers. The tail pointer is needed for freelist appending;
- stores entries in buckets, where bucket[log2(size)] stores
entries >= size;
- implements worst fit allocation to amortize free list call;
- ported from Blink: https://bit.ly/2yC8XKJ.
Bug: chromium:1056170
Change-Id: I26cf62c948c95a7cbfecd5f7f22ad975e6b8c732
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157376
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67310}
This is a reland of e1b93a4ff5
which was a reland of 313d4844d9
which was a reland of 0a59e0cb08
which was a reland of 146f5375da
which was a reland of d91679bf3a
Give up on using C++ bitfields, go back to having base::BitField and
getters/setters.
Original change's description:
> [parser] Introduce UnoptimizedCompileFlags
>
> UnoptimizedCompileFlags defines the input flags shared between parse and
> compile (currently parse-only). It is set initially with some values, and
> is immutable after being passed to ParseInfo (ParseInfo still has getters
> for the fields, but no setters).
>
> Since a few of the existing flags were output flags, ParseInfo now has a
> new output_flags field, which will eventually migrate to a ParseOutputs
> structure.
>
> Bug: v8:10314
> Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66782}
TBR=ulan@chromium.org,szuend@chromium.org
Bug: v8:10314
Change-Id: I54bcd107a0e85cf1a2ddeef0759100547eb65652
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157378
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67309}
If multiple compilation threads want to publish their generated code,
they currently block on each other. This can cause multiple background
threads to be blocked for several hundred milliseconds in the worst
case.
This CL changes this such that instead of blocking, the threads just
put the code in a queue from where it is picked up by the thread that
is currently publishing. Instead of blocking, the threads can then
continue compiling more code already.
This change might produce regressions, because there is now more
TurboFan tier-up compilation happening while Liftoff code is being
published. This might delay the completion of baseline compilation. It
can also happen that we publish (more) TurboFan code before finishing
baseline compilation, which would also regress compile scores.
Let's see what the perf bots have to say about this CL. We might need to
adapt certain things (like delaying TurboFan compilation until all
Liftoff code finished), or we might just accept slight delays in Liftoff
compilation, because tier-up will finish sooner after this CL, giving us
peak performance earlier.
R=ahaas@chromium.org
Bug: v8:10330
Change-Id: I2f5c15810a0a9fc18461f9cbf4e436ab36aa559d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154200
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67308}
The existing code supports overlapping LiftoffRegisters in I64Binops by
allocating a scratch register. Overlapping LiftoffRegisters means that
the low register of one LiftoffRegister is the high register of another
LiftoffRegister. When I64Binop is used in the implementation of atomic
instructions, no scratch register is available, so overlapping
LiftoffRegisters cannot be supported. As LiftoffRegisters are
not supposed to overlap anyways, this CL removes this special handling.
R=clemensb@chromium.org
Bug: v8:10108
Change-Id: I9ce2143b0930688bc2e6dd56e151f47fba00ec87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151351
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67307}
The partial snapshot/serializer/deserializer are renamed to context *,
while the partial snapshot cache is renamed to startup object cache in
line with the read-only object cache (as this better reflects where it
lives and what it does).
To avoid a gap in the file history due to renaming both the files and
identifiers simulataneously, this leaves all the partial-*.* files in
place. They will be renamed in a follow-up CL.
Bug: v8:10416
Change-Id: I5ef41cad751aaa24b35ee2b3c72bd0295832f2c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144115
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67306}
This is a reland of 80843eda31
Original change's description:
> [torque] Allow storing to bitfield structs that are stored in Smis
>
> This change:
> 1. Updates the Torque compiler to allow direct access to bitfields that
> are packed within Smi values, which previously would have required a
> separate untagging step,
> 2. Updates JSRegExpStringIterator to represent its flags in Torque,
> 3. Adds reduction cases in MachineOperatorReducer for when the input to
> a branch or the left-hand side of a Word32Equals is based on a 64-bit
> shift-and-mask operation which has been truncated to 32 bits, as is
> the case in the code generated by step 1, and
> 4. Adds a reduction case in MachineOperatorReducer to remove an extra
> Word64And operation added by step 1.
>
> Bug: v8:7793
> Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67290}
Bug: v8:7793
Change-Id: I783b6ec080042fec0e922927f6675dede458a072
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159731
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67305}
When compiling modules with many functions, the list of regions in the
{DisjointAllocationPool} can become quite large if the functions die in
a random order (which they typically do, since the order of Liftoff
compilation is different than the order to TurboFan compilation; which
work stealing, both are nondeterministic).
Iterating the list of regions in the {DisjointAllocationPool} was thus
linear in the number of regions, which is linear in the number of
functions of the module. Since we insert new regions one by one, overall
runtime was quadratic.
This CL fixes this by switching from a linked list to a std::set.
Merging a new region is thus logarithmic instead of linear, and overall
we are {n*log(n)} instead of {n^2}.
Note: For {AllocateInRegion} we still need to linearly iterate all
regions that overlap the requested region, but this has not shown to be
a problem so far.
R=ahaas@chromium.org
Bug: v8:10432
Change-Id: I193e56c2abab782e386194fbe64dadfa250916f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154797
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67303}
With this CL we reuse the implementation of AtomicStore to implement
AtomicBinops. The implementation is parametrised by an optional result
Liftoff register, and by an operation that is applied on the value
stored in the memory location.
R=clemensb@chromium.org, v8-arm-ports@googlegroups.com
Bug: v8:10108
Change-Id: I71ff5bf1632d860462d66b43c34515400eae2979
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151349
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67302}
This patch is to avoid spilling the phi at the loop header if there is a back-edge with an input for the phi that interferes with the phi's value, because in case that input gets spilled it might introduce a stack-to-stack move at the back-edge.
Bug: chromium:1063831
Change-Id: Ie7129f10fb573cc799c588e6639b5ad486ea520d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152002
Commit-Queue: Yolanda Chen <yolanda.chen@intel.com>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67299}
- Reworks the builtins WasmTableGet and WasmTableSet to do the fast
path, instead of generating this inline in wasm-compiler.
Change-Id: I0a47c09d6f4f6d81c7b362f6f45e95b19e3edf86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135864
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67296}
Use the InstallFunction helper to create the initial map and prototypes
instead of manually doing so. WeakRef is currently creating an unused
Map tied to JS_WEAK_REF_TYPE that would cause the various LogMaps
cctests to fail when the feature ships.
Bug: v8:8179
Change-Id: Ic1b35ebe5da722fa030af336099fff6153b4baed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158488
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67294}
Provide a stub `third_party_heap::Heap` implementation to work around
linker erors with Visual Studio.
cl.exe in debug mode seems to eliminate dead code not as aggressively
as clang or gcc, resulting in references to `third_party_heap::Heap`
remaining in unreachable code paths.
Refs: https://github.com/bnoordhuis/v8-cmake/issues/10
Bug: v8:10427
Change-Id: I61fde11697adc663b182f60c132eda435a7f11bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159490
Commit-Queue: Ben Noordhuis <info@bnoordhuis.nl>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67293}
- Adds builtins to convert between Int32/Float64 and JS Number.
- WasmInt32ToHeapNumber (bypass SMI test)
- WasmFloat64ToNumber
- Adds builtins to convert between Tagged and Int32/Float64.
- WasmTaggedNonSmiToInt32 (bypass SMI test)
- WasmTaggedToFloat64
- Uses these builtins in Wasm import and export wrappers instead of
generating the equivalent code inline.
Results of running Wasm/import-export-wrappers.js Benchmark:
https://docs.google.com/document/d/1QIB0xnqdJFRsOJKQYZ8DZgzWn4WysybgugbcO0sYcQA/edit?usp=sharing
NOTE: CL will need to be rebased after linkage fix lands.
Bug: v8:10070
Change-Id: Ib34507fcd18bdf80938b5707310a5a4f76cdec72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099445
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67292}
This reverts commit 80843eda31.
Reason for revert: Causes compilation failure on macs
https://ci.chromium.org/p/v8/builders/ci/Mac%20V8%20FYI%20Release%20(Intel)/8934?
Original change's description:
> [torque] Allow storing to bitfield structs that are stored in Smis
>
> This change:
> 1. Updates the Torque compiler to allow direct access to bitfields that
> are packed within Smi values, which previously would have required a
> separate untagging step,
> 2. Updates JSRegExpStringIterator to represent its flags in Torque,
> 3. Adds reduction cases in MachineOperatorReducer for when the input to
> a branch or the left-hand side of a Word32Equals is based on a 64-bit
> shift-and-mask operation which has been truncated to 32 bits, as is
> the case in the code generated by step 1, and
> 4. Adds a reduction case in MachineOperatorReducer to remove an extra
> Word64And operation added by step 1.
>
> Bug: v8:7793
> Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67290}
TBR=tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org
Change-Id: Ifa683c92631291c9437438682b6efb2e12862682
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159730
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67291}
