For arm64 decompressing a TaggedSigned results in a 64-bit value, with
the top 32 bits zeroed and the lower 32 bits being the SMI. This patch,
with the --debug-code flag enabled, will corrupt the top 32 bits to try
and catch places that are using 64-bit operations instead of 32-bit operations.
Change-Id: I3d3048c4f4b87f3bce26d0c7eb41789ec6b99f5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917099
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Joey Gouly <joey.gouly@arm.com>
Cr-Commit-Position: refs/heads/master@{#65035}
The optimization behavior in these configurations is strange, I'm
still trying to understand what exactly is going on.
Bug: v8:9945, v8:9983
Change-Id: I52782b9e73decb9f3b2439cddd5e23068faebdf4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924349
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65032}
Former CL 352bbb1https://crrev.com/c/1893192 made an optimization that move non-JS
linkage builtins code objects into RO_SPACE, but caused v8 crash on mips platform,
so temporarily disable the change on mips platform.
Change-Id: Iffba1a35985ccf6688e29e35db20602d69a496e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1919442
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65031}
Drive-by: For more flexibility (e.g. for future IsNull methods), remove
'Constant' from names in the list of constants.
Bug: v8:9972
Change-Id: I66ec64c30cb397641d77cd26b514e8ac52763e16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924348
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65030}
In most cases where we bail out to TurboFan, we actually have a fallback
that just calls a C function instead. This fallback did not exist
initially, but was added later for other platforms (see e.g.
https://crrev.com/c/1044187).
By reusing that fallback on intel, we remove another portion of function
that could not be compiled in Liftoff on specific CPUs.
R=ahaas@chromium.org
Bug: v8:9919
Change-Id: I151000c004dc330362337bf7ddeaec68390c3467
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921986
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65029}
... by disallowing checkpoint elimination across function boundaries.
See the comment in checkpoint-elimination.cc and the tests for details.
Bug: v8:9945
Change-Id: Ibf4ab6f0e4e709e26d3c4428a082ef45dcbeb8b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1906208
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65027}
Individual frames of a stack frame in the frame cache might point
to the JSFunction of that corresponding stack frame. It is illegal to
serialize JSFunction objects in the isolate snapshot, so the attempt
to serialize the stack frame cache results in a crash. This can happen
when a warmup script is run, before a snapshot is created.
This CL fixes the crash by not utilizing the stack frame cache in case
the serializer is enabled.
Change-Id: I8b79a06b8cff36e1f54b54d3d8e5397b07ba52e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923068
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65026}
We recently extended function-entry stack checks by an offset
representing the difference in optimized and unoptimized frame sizes,
with the intent of avoiding stack overflows during deopts. Although
the generated code is very efficient (just a single additional
register subtraction, executed exactly once per call), perf impact
is measurable.
To avoid the overhead in most cases, this CL adds a stack slack,
currently set to 256 bytes, by which deopts are allowed to exceed the
real V8 stack limit. For function-entry stack checks with an offset
less than stack slack, the offset is not applied and the more
efficient version of the stack check is emitted.
The V8 limit is chosen to be smaller than OS stack size (assumed to
be at least 1 MB). This guarantee is upheld even with slack.
Bug: chromium:1020989,v8:9534
Change-Id: Idee2e7ad1fa7810bf086a9f72ce00a9717010310
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910099
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65025}
1bc19352..3682ddd7
3682ddd Add tests for String#replaceAll (#2423) by Leo Balter · 7 hours ago master
7040938 Fix tests for AggregateError (#2419) by Leo Balter · 3 days ago
43b0c76 Update tests for FinalizationGroup#register (#2424) by Jon Coppeard · 4 days ago
aa9ba4b Add tests for Intl.DisplayNames#resolvedOptions (#2405) by Leo Balter · 5 days ago
8f8b337 Merge pull request #2420 from shvaikalesh/improve-json-parse-coverage by Leo Balter · 6 days ago
8544b06 Merge pull request #2418 from leobalter/remote-aggregateerror-tostring by Leo Balter · 6 days ago
3433399 tag subclass tests with WeakSet and WeakMap (#2421) by Gus Caplan · 7 days ago
5728e1b Add reviver prototype chain lookup tests by Alexey Shvayka · 7 days ago
80a99f7 Add reviver object with non-configurable property tests by Alexey Shvayka · 7 days ago
027cc0c Add reviver array with non-configurable property tests by Alexey Shvayka · 7 days ago
64ce046 Add reviver wrapper test by Alexey Shvayka · 7 days ago
da9612d Add some more Proxy/ownKeys invariants tests (#2413) by Alexey Shvayka · 7 days ago
600245f Add integer index tests for Proxy "set" and "has" traps (#2412) by Alexey Shvayka · 7 days ago
13016eb Merge pull request #2416 from devsnek/fix-newlines by Leo Balter · 7 days ago
206c0cb Merge branch 'master' into fix-newlines by Leo Balter · 7 days ago
9bb90d1 Fix failure phase in coalesce tests (#2415) by Gus Caplan · 7 days ago
02bdf77 Add test for AggregateError's toString by Leo Balter · 7 days ago
90231ad Remote tests for AggregateError.prototype.toString by Leo Balter · 7 days ago
a53f43e add missing newlines in tests by Gus Caplan · 8 days ago
8338258 add lint check for newline at end of file by Gus Caplan · 8 days ago
Bug: v8:7834
Change-Id: I929f4f52fdb962d40b3314f50c98bb13f53f43fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1919955
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65022}
We detect a stepping in Wasm from Javascript into Wasm then prepare
the target function for debugging.
The trick is redirect the target to interpreter and set a 'fake'
breakpoint in the first instruction. Currently we don't need to clear
this 'fake' breakpoint since it won't notify unless user intend to
step in.
Change-Id: Ibe1f9ba31dc6c7919895d3fe31967e9c4699ef63
Bug: chromium:1019606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1902259
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65020}
Port 63dc55568b
Original Commit Message:
A window is a Blink concept. This API marks the context as backing
a detached window. This doesn't necessarily mean that the context is
detached.
Every time a JS function is called within a context that has a non-zero
DetachedWindowReason, Runtime::kReportDetachedWindowAccess is invoked,
which will report this call to Blink via a callback, which in turn can
report number of such calls via UKM metrics.
R=bartekn@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I2243898115287e103ba5700499b9547fe155dceb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1919954
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#65018}
This implements the rest of the load extend instructions:
- i32x4.load16x4_s
- i32x4.load16x4_u
- i64x2.load32x2_s
- i64x2.load32x2_u
Bug: v8:9886
Change-Id: I4649f77bae5224042a1628d9f0498c050b1e599d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903812
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65017}
As one of several steps involved in supporting struct-valued fields
within classes, this CL generates type verification code for the data
contained in those structs.
In order to generate verification code, Torque needs to know about
struct field offsets and the total size of structs. Those calculations
are added to StructType itself and the function TypeVisitor::ComputeType
which initializes the StructType. I repurposed the Field::offset value
to behave in structs more like it does in classes (it had previously
indicated the index of a field within a struct, but nobody used that
value). Overall this works okay, and I think it's less confusing to have
Field::offset mean the same thing everywhere. However, some struct
fields have types with unknown size (Field::GetFieldSizeInformation
fails), so those fields are now marked with offset Field::kInvalidOffset
to indicate that the structs containing them should not be used within
class fields or anywhere else that requires packed layout.
Bug: v8:7793
Change-Id: If2677c8c81efc85e63b4bfb831d818a748427e18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897247
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65016}
Having had these would have saved me quite a bit of time :)
Change-Id: I36a04cc89db9ceaa786a146d01a6b0f4444f5729
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914214
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65015}
At least under some circumstances (GCC 6 with x64 Linux for me),
the code in `serializer-for-background-compilation.cc` guarded by
`ENABLE_SLOW_DCHECKS` attempts to use `std::iterator_traits` on the
`FunctionalList`, which previously failed compilation because
the standard iterator member types were unavailable.
This adds these members.
Refs: https://chromium-review.googlesource.com/c/v8/v8/+/1800578
Change-Id: Ifece423fce31d98777c6a65ef442623c321ecba3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921800
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65014}
For many subclasses of JSObject, we used kSize instead of kHeaderSize
even though they can contain in-object properties. In fact, kSize
was very much used as the header size, as can be seen in many examples
in this CL.
This change is a preparation for a for a cleanup of how Torque
generates field offsets.
TBR=hpayer@chromium.org
Change-Id: I350e996057cd66c427381334080f8ac93de88597
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917141
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65013}
The serialization of Construct was accidentally using the wrong hints
for the receiver. Also, the recursion in ProcessCallOrConstruct was
not quite right: for example, it overwrote the accumulator hints in
each recursion.
With this CL the Octane raytrace score for --concurrent-inlining is
back to the default configuration's score.
Bug: v8:7790
Change-Id: I501c9cc0b0c8de04520742b9c6b392a4a732bf78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921789
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65011}
That warning about missing data was sometimes printed even
when nothing was missing.
(Also drop an outdated TODO.)
Bug: v8:7790
Change-Id: I9550b3237c87b7b0e59f740c34b13d3e38d8d36e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917153
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65010}
This CL adds one undeclared "torque_base" header, as well as two
headers that are generated by the Torque compiler itself.
R=tebbi@chromium.org
Bug: v8:9810
Change-Id: I76c552d897da08b47c03efba959b348f0c2e5843
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918256
Auto-Submit: Simon Zünd <szuend@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65009}
Since WASM can generate direct calls to any function that it knows the
arity of and these can be any JS linkage builtin, we need to ensure that
CPP builtins also go into CODE_SPACE.
This moves 276 builtins (~25KiB) from RO_SPACE back to CODE_SPACE.
Bug: chromium:1022695, v8:7464
Change-Id: I4cda8b68ddf6a5ddad09c6e7d4e6a08c8e6c2ccb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916600
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65004}
The DCHECK in the lookup method compares the stashed length of the backing store
and the byte_length queried on lookup. These two are not guaranteed to be equal
as there can be grow calls that update the lenght of the buffer between the
length being stashed and the equality check.
Bug: chromium:1010272
Change-Id: I754fa0a9ab676cd838e893d12ef6b13fc7d335e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1911490
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65003}
This makes sure that the {WasmGraphBuilder} properly detects the
presence of Simd128 global.get and global.set opcodes and triggers
scalar lowering on architectures without Simd128 support.
R=clemensb@chromium.org
TEST=cctest/test-run-wasm-simd/RunWasm_S128Globals
BUG=v8:9973
Change-Id: I1538bd1d3fea40cc78e82b125d4f113842faf68a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917148
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65002}
This reverts commit 80caf2cf53.
Reason for revert: Breaks gpu tests:
https://ci.chromium.org/p/v8/builders/ci/Win%20V8%20FYI%20Release%20(NVIDIA)/5570
# Debug check failed: !possibly_empty_buckets->Contains(bucket_index).
Original change's description:
> [heap] Reduce size of possibly empty buckets
>
> Before this CL a byte was used per bucket to store whether the bucket
> is possibly empty or not. This CL changes this such that each bucket
> only needs a single bit.
>
> PossiblyEmptyBuckets is now a word in the page header. If more bits
> are needed than fit into a single word, an external bitmap is
> allocated using AlignedAlloc. Storing this on the page header, allows
> to remove initial_buckets from the SlotSet. The SlotSet allocation is
> then again a power-of-2 in release mode.
>
> Change-Id: If61fd5cfa153f98757beeb444a530f6e2803fdb6
> Bug: chromium:1023139
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1906376
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64991}
TBR=ulan@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1023139
Change-Id: Ia90b07b9562af934dacba012da31e4f172f2922d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918258
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65001}
This reverts commit a9ea67d4bb.
Reason for revert: Regressions https://crbug.com/1025160.
Original change's description:
> Reland "[regalloc] Use an adaptive data structure for live sets"
>
> This is a reland of b3d748a282
>
> Original change's description:
> > [regalloc] Use an adaptive data structure for live sets
> >
> > Live sets represent sets of live virtual registers at block entry and
> > exit points. They are usually sparsely populated; for example, a sample
> > taken from Octane2 shows 80% of sampled live sets with a fill ratio of
> > 10% or less.
> >
> > Prior to this CL, live sets were implemented as a statically-sized bit
> > vector. This is fine for low-ish virtual register counts, but becomes
> > wasteful at higher numbers.
> >
> > This CL attempts to address this issue through an adaptive
> > implementation. Small live sets remain bit vectors, while larger sets
> > switch to a PersistentMap-based implementation. PersistentMap has very
> > memory-efficient add/remove/copy operations.
> >
> > Of course, with adaptive data structures we enter the territory of
> > parameter fiddling. In this case, two parameters are used:
> > kMaxSmallSetSize controls when to switch implementations, and
> > kMaxDeletionsBeforePrune controls when pruning (= managing the # of
> > deleted entries in the map) sets in.
> >
> > On the (degenerate) test case from the linked bug, the register
> > allocation zone shrinks from 1008MB to 475MB. For more realistic cases
> > I expect savings on the order of 10s of KB.
> >
> > Bug: v8:9574
> > Change-Id: Id903bbe23f030b418e8d887ef4839c8d65126c52
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1891693
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#64872}
>
> Bug: v8:9574
> Change-Id: I5a95d56c33a98cc5c6c58ff9308314e2eefa462c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910953
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64950}
TBR=jgruber@chromium.org,tebbi@chromium.org,thibaudm@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9574,chromium:1025160
Change-Id: I177d64eed588cd09c999e15b04d37630c2c6538b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918255
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64998}
Switch the parameter name src and dst.
Change-Id: I4bd07959dd9e9da3a32ebb8d4b61dd6b92e90592
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918094
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Jie Pan <jie.pan@intel.com>
Cr-Commit-Position: refs/heads/master@{#64996}
This reverts commit 0c3906f4dc.
Reason for revert: <broken compatibility with Python 3>
Original change's description:
> Fix an error caused by a bug in Python < 2.7.9
>
> There seems to be a bug in Python versions prior
> to 2.7.9 where running exec could produce the following error:
>
> SyntaxError: unqualified exec is not allowed in function
> '_ParsePythonTestTemplates' it contains a nested function
> with free variables (testcfg.py, line 71)
>
> https://bugs.python.org/issue21591
>
> It's causing an issue on all Ubuntu 14 and RHEL 7 machines.
>
> The proposed change is an equivalent syntax which doesn't
> produce an error:
> https://docs.python.org/2/reference/simple_stmts.html#the-exec-statement
>
>
> Change-Id: I159cc1be58ff375f313ae5c4fb814763704b880e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893647
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
> Cr-Commit-Position: refs/heads/master@{#64736}
TBR=machenbach@chromium.org,bmsdave@gmail.com,tmrts@chromium.org,miladfar@ca.ibm.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Ib62143645184d768f54272b7c2d7745f6b700369
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921171
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#64995}
Before this CL a byte was used per bucket to store whether the bucket
is possibly empty or not. This CL changes this such that each bucket
only needs a single bit.
PossiblyEmptyBuckets is now a word in the page header. If more bits
are needed than fit into a single word, an external bitmap is
allocated using AlignedAlloc. Storing this on the page header, allows
to remove initial_buckets from the SlotSet. The SlotSet allocation is
then again a power-of-2 in release mode.
Change-Id: If61fd5cfa153f98757beeb444a530f6e2803fdb6
Bug: chromium:1023139
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1906376
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64991}
This reverts commit 1ec2ca266f.
Reason for revert: Preparing for re-enabling pointer compression.
Original change's description:
> [ptr-compr] Temporarily enable double fields unboxing
>
> We are not shipping ptr-compr in M79 on x64 because chromium:1009439
> blocks 31-bit Smis on 64-bit architectures, so these's no point in
> disabling double fields unboxing.
>
> This CL will be reverted after the M79 branch point.
>
> Bug: v8:9799, chromium:1009439
> Change-Id: I28d0013d3ab06ce41d5028ba4f66c9b249de52d7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862556
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64288}
Bug: v8:9799, chromium:1009439
Change-Id: I18e22422725777ad8bfbb19243158228f3559c32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1919320
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64990}
It was perhaps incorrectly not declared inline while still appearing in
the main header file and then appearing in the -inl.h. MSVC doesn't like
it being declared inline however, so just inline it directly into the
main header.
Bug: v8:8510
Change-Id: I16106b91b3b4dff31e70382f2e66aa4f42fb290b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918249
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64988}
Currently it's pretty easy to write Torque code that generates an error
in some common generic function such as Convert<To: type, From: type>,
and unless your change is very small, it can be hard to figure out what
part of it caused that macro specialization. This CL updates the Torque
compiler to emit some extra information about the stack of code
positions that caused a specialization of a macro or builtin, similar to
what Clang does for C++ templates. Obviously there might be multiple
places that require a particular specialization, but we only report the
first one that caused the specialization to be created.
Bug: v8:7793
Change-Id: I4c0fbf1fd437d0eb0d7d5002baef7a5361aea5ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1911019
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64987}
The constructor taking an Isolate and HeapObject never uses the
HeapObject value and just calls through to the Isolate constructor.
Bug: v8:9810
Change-Id: Ia2553b4d1f31cf24549980dbb5c2bfa38fe91f8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918247
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64986}
