Now that embedded builtins are enabled everywhere*, lazy
deserialization can be turned off and removed.
* Except nosnap builds, on aix and in msvc builds.
Bug: v8:6666, v8:6624, v8:7990
Change-Id: Ib5fefe10e7ff35b13a1eb803fbc3736b8851b22b
Reviewed-on: https://chromium-review.googlesource.com/c/1288638
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57064}
This is a reland of fcbb023b0e
Original change's description:
> Add Windows ARM64 ABI support to V8
>
> This change added Windows ARM64 ABI support, major things are:
> 1. Excluding x18 register from any usage because it is reserved as
> platform register. Preserve alignment after the change.
> 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is
> still LLP64.
> 3. Stack guard page probe for large allocation on stack.
>
> Reference:
> Windows ARM64 ABI:
> https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017
>
> Bug: chromium:893460
> Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e
> Reviewed-on: https://chromium-review.googlesource.com/c/1285129
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56881}
CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_arm64_dbg_recipe
TBR=mlippautz@chromium.org
Bug: chromium:893460
Change-Id: Icc45fd091c33f7df805842a70236b79b14756f52
Reviewed-on: https://chromium-review.googlesource.com/c/1297300
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56965}
This changes the ReceiverOrOddball feedback on JSStrictEqual to
ReceiverOrNullOrUndefined feedback, which can also safely be
consumed by JSEqual (we cannot generally accept any oddball here
since booleans trigger implicit conversions, unfortunately).
Thus we replace the previously introduced CheckReceiverOrOddball
with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since
we will no longer collect Oddball feedback separately.
TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into
a sequence like this:
```
left = CheckReceiverOrNullOrUndefined(left);
right = CheckReceiverOrNullOrUndefined(right);
result = if ObjectIsUndetectable(left) then
ObjectIsUndetectable(right)
else
ReferenceEqual(left, right);
```
This significantly improves the peak performance of abstract equality
with Receiver, Null or Undefined inputs. On the test case outlined in
http://crbug.com/v8/8356 we go from
naive: 2946 ms.
tenary: 2134 ms.
to
naive: 2230 ms.
tenary: 2250 ms.
which corresponds to a 25% improvement on the abstract equality case.
For regular code this will probably yield more performance, since we
get rid of the JSEqual operator, which might have arbitrary side
effects and thus blocks all kinds of TurboFan optimizations. The
JSStrictEqual case is slightly slower now, since it has to rule out
booleans as well (even though that's not strictly necessary, but
consistency is key here).
This way developers can safely use `a == b` instead of doing a dance
like `a == null ? b == null : a === b` (which is what dart2js does
right now) when both `a` and `b` are known to be Receiver, Null or
Undefined. The abstract equality is not only faster to parse than
the tenary, but also generates a shorter bytecode sequence. In the
test case referenced in http://crbug.com/v8/8356 the bytecode for
`naive` is
```
StackCheck
Ldar a1
TestEqual a0, [0]
JumpIfFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```
which is 14 bytes, whereas the `tenary` function generates
```
StackCheck
Ldar a0
TestUndetectable
JumpIfFalse [7]
Ldar a1
TestUndetectable
Jump [7]
Ldar a1
TestEqualStrict a0, [0]
JumpIfToBooleanFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```
which is 24 bytes. So the `naive` version is 40% smaller and requires
fewer bytecode dispatches.
Bug: chromium:898455, v8:8356
Change-Id: If3961b2518b4438700706b3bd6071d546305e233
Reviewed-on: https://chromium-review.googlesource.com/c/1297315
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56948}
This CL introduces proper Oddball and ReceiverOrOddball states for the
CompareOperationFeedback, and updates the StrictEqual IC to collect this
feedback as well. Previously it would not collect Oddball feedback, not
even in the sense of NumberOrOddball, since that's not usable for the
SpeculativeNumberEqual.
The new feedback is handled via newly introduced CheckReceiverOrOddball
and CheckOddball operators in TurboFan, introduced by JSTypedLowering.
Just like with the Receiver feedback, it's enough to check one side and
do a ReferenceEqual afterwards, since strict equal can only yield true
if both sides refer to the same instance.
This improves the benchmark mentioned in http://crbug.com/v8/8356 from
naive: 2950 ms.
tenary: 2456 ms.
to around
naive: 2996 ms.
tenary: 2192 ms.
which corresponds to a roughly 10% improvement in the case for the
tenary pattern, which is currently used by dart2js. In real world
scenarios this will probably help even more, since TurboFan is able
to optimize across the strict equality, i.e. there's no longer a stub
call forcibly spilling all registers that are live across the call.
This new feedback will be used as a basis for the JSEqual support for
ReceiverOrOddball, which will allow dart2js switching to the shorter
a==b form, at the same peak performance.
Bug: v8:8356
Change-Id: Iafbf5d64fcc9312f9e575b54c32c631ce9b572b2
Reviewed-on: https://chromium-review.googlesource.com/c/1297309
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56925}
This reverts commit fcbb023b0e.
Reason for revert: blocks roll https://chromium-review.googlesource.com/c/chromium/src/+/1296315
Original change's description:
> Add Windows ARM64 ABI support to V8
>
> This change added Windows ARM64 ABI support, major things are:
> 1. Excluding x18 register from any usage because it is reserved as
> platform register. Preserve alignment after the change.
> 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is
> still LLP64.
> 3. Stack guard page probe for large allocation on stack.
>
> Reference:
> Windows ARM64 ABI:
> https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017
>
> Bug: chromium:893460
> Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e
> Reviewed-on: https://chromium-review.googlesource.com/c/1285129
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56881}
TBR=bbudge@chromium.org,ulan@chromium.org,machenbach@chromium.org,hpayer@chromium.org,brucedawson@chromium.org,mlippautz@chromium.org,ahaas@chromium.org,bmeurer@chromium.org,Tom.Tan@microsoft.com
Change-Id: I0b804af6dfca9409a655194fa6e5407f209be2dc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:893460
Reviewed-on: https://chromium-review.googlesource.com/c/1296460
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56912}
This change added Windows ARM64 ABI support, major things are:
1. Excluding x18 register from any usage because it is reserved as
platform register. Preserve alignment after the change.
2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is
still LLP64.
3. Stack guard page probe for large allocation on stack.
Reference:
Windows ARM64 ABI:
https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017
Bug: chromium:893460
Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e
Reviewed-on: https://chromium-review.googlesource.com/c/1285129
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56881}
The InstructionSelector on x64 was missing the ability to properly match
comparisons of memory operands with zero, i.e. it used to turn something
like
Word32Equal(Load[Uint8](o, i), Int32Constant(0))
into
movzbl reg, [o,i]
cmp 0, reg
even requiring a temporary register. Now with this change it generates
the proper
cmpb [o,i], 0
sequence.
R=sigurds@chromium.org
Bug: v8:8238
Change-Id: I52a71bbf95c85e11cb275f0f4a5726a6873cde95
Reviewed-on: https://chromium-review.googlesource.com/c/1281342
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56677}
There's no ambiguity and the shorter name makes things easier to read.
Bug: v8:7790
Change-Id: Ibcf3fd7f38a91e26a83cd335fad0ec80a5fe9be1
Reviewed-on: https://chromium-review.googlesource.com/c/1278392
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@{#56623}
For now, all it does is control when the heap broker starts
serializing. Eventually it will do what its name suggests.
I'm also renaming --concurrent-compiler-frontend to the more
accurate --concurrent-typed-lowering. Note that it's forceably
implied by --concurrent-inlining.
Bug: v8:7790
Change-Id: I55c1d8f1538146e89f3e166cb9165f6f38447146
Reviewed-on: https://chromium-review.googlesource.com/c/1270839
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56557}
... containing RootsTable, ExternalReferenceTable, builtins array and
potentially some other data that can be accessed via the RootRegister.
This is a preliminary step before adding support for pointer-compression
friendly heap layout.
Bug: v8:8182
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2899f657aaff1351a5304afa0b1a4c5ae4cfc31d
Reviewed-on: https://chromium-review.googlesource.com/c/1245426
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56551}
As identified in the web-tooling-benchmark, there are specific code
patterns involving array indexed property accesses and subsequent
comparisons of those indices that lead to repeated Smi checks in the
optimized code, which in turn leads to high register pressure and
generally bad register allocation. An example of this pattern is
code like this:
```js
function f(a, n) {
const i = a[n];
if (n >= 1) return i;
}
```
The `a[n]` property access introduces a CheckBounds on `n`, which
later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`,
however the `n >= 1` comparison has collected `SignedSmall` feedback
and so it introduces a `CheckedTaggedToTaggedSigned` operation. This
second Smi check is redundant and cannot easily be combined with the
earlier tagged->int32 conversion, since that also deals with heap
numbers and even truncates -0 to 0.
So we teach the RedundancyElimination to look at the inputs of these
speculative number comparisons and if there's a leading bounds check
on either of these inputs, we change the input to the result of the
bounds check. This avoids the redundant Smi checks later and generally
allows the SimplifiedLowering to do a significantly better job on the
number comparisons. We only do this in case of SignedSmall feedback
and only for inputs that are not already known to be in UnsignedSmall
range, to avoid doing too many (unnecessary) expensive lookups during
RedundancyElimination.
All of this is safe despite the fact that CheckBounds truncates -0
to 0, since the regular number comparisons in JavaScript identify
0 and -0 (unlike Object.is()). This also adds appropriate tests,
especially for the interesting cases where -0 is used only after
the code was optimized.
Bug: v8:6936, v8:7094
Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07
Reviewed-on: https://chromium-review.googlesource.com/c/1246181
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56428}
This reverts commit 4fd92b252b.
Reason for revert: Significant tankage on the no-mitigations bots (bad timing on the regular bots)
Original change's description:
> [turbofan] Do not consume SignedSmall feedback in TurboFan anymore.
>
> This changes TurboFan to treat SignedSmall feedback similar to Signed32
> feedback for binary and compare operations, in order to simplify and
> unify the machinery.
>
> This is an experiment. If this turns out to tank performance, we will
> need to revisit and ideally revert this change.
>
> Bug: v8:7094
> Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1
> Reviewed-on: https://chromium-review.googlesource.com/c/1261442
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56411}
TBR=jarin@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7094
Change-Id: I9fff3b40e6dc0ceb7611b55e1ca9940089470404
Reviewed-on: https://chromium-review.googlesource.com/c/1267175
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56427}
This changes TurboFan to treat SignedSmall feedback similar to Signed32
feedback for binary and compare operations, in order to simplify and
unify the machinery.
This is an experiment. If this turns out to tank performance, we will
need to revisit and ideally revert this change.
Bug: v8:7094
Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1
Reviewed-on: https://chromium-review.googlesource.com/c/1261442
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56411}
The root register is not available in JS-to-Wasm functions, and
this was not reflected in the linkage. Similarily, it is not
available in C-to-Wasm functions.
Change-Id: I2dbfd06ef99d6f9b9940e9489f563441d9ebfabd
Bug: v8:6666
Reviewed-on: https://chromium-review.googlesource.com/1256766
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56346}
Picking a few low-hanging fruits.
Bug: v8:7790
Change-Id: I798d579b1f1a08fab821e159d08f453d2dad89c1
Reviewed-on: https://chromium-review.googlesource.com/1254124
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56320}
- Add a new broker mode kRetired, in which the heap can
again be accessed.
- Change the way modes work. We now always start in kDisabled.
If FLAG_concurrent_compiler_frontend is on, we eventually move
to kSerializing, then to kSerialized, then to kRetired.
- Add an ObjectDataKind to ObjectData that indicates whether the
data is just a dummy (i.e. created while broker was in kDisabled
mode).
This also happens to fix a bug found by clusterfuzz.
Bug: v8:7790, chromium:889722
Change-Id: I38833fe7ad26d2d3efb15ba560576defb82f673a
Reviewed-on: https://chromium-review.googlesource.com/1245425
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56260}
This is just a cleanup.
Bug: v8:7790
Change-Id: Ic0114451159b8c504f527f3cf3bdaed6a8cc8741
Reviewed-on: https://chromium-review.googlesource.com/1243103
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56206}
... if FLAG_concurrent_compiler_frontend is enabled.
Bug: v8:7790
Change-Id: I448560b21d54c8907e8cbf68bdaf8bbdf2b034df
Reviewed-on: https://chromium-review.googlesource.com/1241959
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56205}
The JSToInteger operator is not used anywhere in TurboFan nowadays, so
no point in keeping the dead code in the tree.
Bug: v8:8015
Change-Id: If03ba63c4b932ba0aac60b9bbc89fee3909a93c6
Reviewed-on: https://chromium-review.googlesource.com/1238238
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56126}
Handlers were recently moved to the builtins table, and we never added
full support for this flag. It doesn't add much value and lazy
deserialization is scheduled for mid-term removal anyways, so let's
just delete it.
--lazy-deserialization now controls both builtin- and
handler-deserialization behavior.
Bug: v8:6624
Change-Id: Iffb7286a00157966abf99158ba629ce4765536d6
Reviewed-on: https://chromium-review.googlesource.com/1238235
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56117}
Remove the NumberConstant right hand side limitation for the speculative
number operation optimization, and extend the logic to also deal with
SpeculativeToNumber, which is common when dealing with postfix increment
and array operations.
Also add appropriate tests for all the relevant cases, specifically we
mjsunit tests to increase the general coverage for the various cases
here (in addition to dedicated unittests).
Bug: v8:8015
Change-Id: I8c92f98490c63b07eb19686efd404322979e57c4
Reviewed-on: https://chromium-review.googlesource.com/1235919
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56072}
Make the RedundancyElimination handle all simplified operators that are
listed in the SIMPLIFIED_CHECKED_OP_LIST, and fix a couple of bugs and
oversights in the code. This also adds a lot of test coverage for all
the cases that we care about in RedundancyElimination (with respect to
Check/Checked simplified operators).
Bug: v8:8015
Change-Id: I57d29113389841b09abcd013313bf5dd1c67735f
Reviewed-on: https://chromium-review.googlesource.com/1233655
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56032}
... as well as ScopeInfo::ContextLength.
Bug: v8:7790
Change-Id: I3ca8b6f252d96b21d0990f8fc08e076eeeea4176
Reviewed-on: https://chromium-review.googlesource.com/1226973
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55939}
This change introduces the necessary conversion operators to convert
from Word64 to other representations (Tagged, Word32, Float64, etc.),
and plugs in the Word64 representation for NumberAdd/NumberSubtract,
such that TurboFan will go to Int64Add/Sub on 64-bit architectures
when the inputs and the output of the operation is in safe integer
range. This includes the necessary changes to the Deoptimizer to be
able to rematerialize Int64 values as Smi/HeapNumber when going back
to Ignition later.
This change might affect performance, although measurements indicate
that there should be no noticable performance impact.
The goal is to have TurboFan support Word64 representation to a degree
that changing the TypedArray length to an uint64_t (for 64-bit archs)
becomes viable and doesn't have any negative performance implications.
Independent of that we might get performance improvements in other areas
such as for crypto code later.
Bug: v8:4153, v8:7881, v8:8171, v8:8178
Design-Document: bit.ly/turbofan-word64
Change-Id: I29d56e2a31c1bae61d04a89d29ea73f21fd49c59
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1225709
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55937}
While investigating crbug.com/878742 I found that somehow the
MachineOperatorReducer lacks the ability to constant-fold
comparisons of Float64 constants, which obviously leads to
pretty weird code.
Bug: v8:8015
Change-Id: I7e18ce10e9d5c87f131fb083ccd3e1e336189dae
Reviewed-on: https://chromium-review.googlesource.com/1226132
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55935}
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
We had an optimization in Crankshaft where we would call into the
megamorphic handler stub directly if an inline cache was already
found to be megamorphic when it hit the optimizing compiler. This
way we could avoid the dispatch overhead when we know that there's
no point in checking for the other states anyways. However we somehow
missed to port this optimization to TurboFan.
Now this change introduces support to call into LoadIC_Megamorphic and
KeyedLoadIC_Megamorphic directly (plus the trampoline versions), which
saves quite a lot of overhead for the cases where the map/name pair is
found in the megamorphic stub cache, and it's quite a simple change. We
can later extend this to also handle the StoreIC and KeyedStoreIC cases
if that turns out to be beneficial.
This improves the score on the Octane/TypeScript test by around ~2%
and the TypeScript test in the web-tooling-benchmark by around ~4%. On
the ARES-6 Air test the steady state mean improves by 2-4%, and on the
ARES-6 ML test the steady state mean seems to also improve by 1-2%, but
that might be within noise.
On a micro-benchmark that just runs `o.x` in a hot loop on a set of 9
different objects, which all have `x` as the first property and are
all in fast mode, we improve by around ~30%, and are now almost on par
with JavaScriptCore.
Bug: v8:6344, v8:6936
Change-Id: Iaa4c6e34c37e78da217ee75f32f6acc95a834250
Reviewed-on: https://chromium-review.googlesource.com/1215623
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55803}
This replaces the previous CheckStringAdd operator which deopts in case
the combined length overflows with a dedicated pure StringConcat operator.
This operator is similar to NewConsString in that it takes the resulting
length plus the two input strings. The operator relies on the length
being checked explicitly by the surrounding code instead of baking the
check into the operator itself. This way TurboFan can eliminate
redundant/unnecessary StringConcat operations, since they are pure now.
This also unifies the treatment of string addition in JSTypedLowering,
and generalizes the StringLength constant-folding to apply to more cases
not just the JSAdd cases inside JSTypedLowering.
Bug: v8:7902, v8:8015
Change-Id: I987ec39815a9464fd5fd9c4f7b26b709f94f2b3f
Reviewed-on: https://chromium-review.googlesource.com/1213205
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55725}
The new node is introduced for literal string addition and calling
String.prototype.concat in the typed lowering phase. It later might get optimized
away during redundancy elimination, keeping the performance of already existing
benchmarks with string addition. In case the operation is about to throw
(due to too long string being constructed) we just deoptimize, reusing
the interpreter logic for creating the error.
Modify relevant mjsunit and unit tests for string concatenation.
Bug: v8:7902
Change-Id: Ie97d39534df4480fa8d4fe3ba276d02ed5e750e3
Reviewed-on: https://chromium-review.googlesource.com/1193342
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55482}
This allows to replace redundant LoadField's whose type doesn't match
the type of the replacement, by just turning those LoadField's into
TypeGuard's.
Bug: v8:8070
Change-Id: Ia329bb536f8829be27e070e90e9eaae0618dac7a
Reviewed-on: https://chromium-review.googlesource.com/1188131
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55407}
This is useful even if there are other uses of the
arithmetic result, because it moves dependencies further back.
Change-Id: I6136a657b547198cb4ec92f38b89ddf5df334124
Reviewed-on: https://chromium-review.googlesource.com/1179662
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Bogdan Lazarescu <bogdan.lazarescu@arm.com>
Cr-Commit-Position: refs/heads/master@{#55292}
This adds support for unaligned load/store access to the DataView
backing store and uses byteswap operations to fix up the endianess
when necessary. This changes the Word32ReverseBytes operator to be
a required operator and adds the missing support on the Intel and
ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
is also mandatory now).
This further improves the performance on the dataviewperf.js test
mentioned in the tracking bug by up to 40%, and at the same time
reduces the code complexity in the EffectControlLinearizer.
Bug: chromium:225811
Change-Id: I7c1ec826faf46a144a5a9068f8f815a5fd040997
Reviewed-on: https://chromium-review.googlesource.com/1174252
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55111}
This reverts commit c46915b931.
Reason for revert: Disasm failures https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/21727
Original change's description:
> [turbofan] Further optimize DataView accesses.
>
> This adds support for unaligned load/store access to the DataView
> backing store and uses byteswap operations to fix up the endianess
> when necessary. This changes the Word32ReverseBytes operator to be
> a required operator and adds the missing support on the Intel and
> ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
> is also mandatory now).
>
> This further improves the performance on the dataviewperf.js test
> mentioned in the tracking bug by up to 40%, and at the same time
> reduces the code complexity in the EffectControlLinearizer.
>
> Bug: chromium:225811
> Change-Id: I296170b828c2ccc1c317ed37840b564aa14cdec2
> Reviewed-on: https://chromium-review.googlesource.com/1172777
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55099}
TBR=sigurds@chromium.org,bmeurer@chromium.org
Change-Id: If7a62e3a1a4ad26823fcbd2ab6eb4c053ad11c49
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:225811
Reviewed-on: https://chromium-review.googlesource.com/1174171
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55107}
This adds support for unaligned load/store access to the DataView
backing store and uses byteswap operations to fix up the endianess
when necessary. This changes the Word32ReverseBytes operator to be
a required operator and adds the missing support on the Intel and
ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
is also mandatory now).
This further improves the performance on the dataviewperf.js test
mentioned in the tracking bug by up to 40%, and at the same time
reduces the code complexity in the EffectControlLinearizer.
Bug: chromium:225811
Change-Id: I296170b828c2ccc1c317ed37840b564aa14cdec2
Reviewed-on: https://chromium-review.googlesource.com/1172777
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55099}
This should make the uses of binary vs. bitwise not very clear:
- Word32BinaryNot for logical negation
- Word32BitwiseNot for bitwise negation
Change-Id: I3345913111da0dbdae6fdf285f090b67eb3f3afc
Reviewed-on: https://chromium-review.googlesource.com/1169205
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55091}
MIPSr1 doesn't support SEB and SEH instructions and this
causes test InstructionSelectorTest.Word32SarWithWord32Shl to fail.
This CL disables this test on MIPSr1.
TEST=unittests/InstructionSelectorTest.Word32SarWithWord32Shl
Change-Id: I284a85210bd0d38374ca339671643560e8a305e2
Reviewed-on: https://chromium-review.googlesource.com/1164363
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#54939}
The heap broker expects that handles get canonicalized.
R=jarin@chromium.org
Bug: v8:7790
Change-Id: If6162316bb2a256e783a8175ac7d4172d040b28b
Reviewed-on: https://chromium-review.googlesource.com/1155123
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54823}
MIPS team has moved to new @wavecomp.com e-mail addresses.
This CL is not actually changing owners, it only renames the
owners to the new email addresses.
No-Presubmit: true
Change-Id: Ic334defa06a36d974de87e99ed6c30bdf021958f
Reviewed-on: https://chromium-review.googlesource.com/1151349
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54732}
