Windows ARM64 does cross build for V8 and runs snapshot tool on build host
under simulator. Simulator is built with LLP64 data model so 0xFFFFL is 32-bit
long by default. It causes problem for the expression "0xFFFFL << shift" when
shift is 32, which actually does nothing on x64 because 0xFFFFL is only 32-bit.
The issue happens for instruction "movk rd, NUM lsl 32" which is simulated in
Simulator::VisitMoveWideImmediate. "0xFFFL << shift" acts as mask to clear bits
32-47 of the orignal value in rd. Under LLP64, the mask happens unexpectedly to
the lowest 16 bits of rd register and corrupts the result of rd. Specify 0xFFFFL
as 64 bit as 0xFFFFLL fixes this problem.
Bug: chromium:893460
Change-Id: Ibd911ce595e83637432a3e1f79a9bf28fcbe09f6
Reviewed-on: https://chromium-review.googlesource.com/c/1475330
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59778}
This should recover the regression from constant field tracking
in Speedometer/angular.
Bug: chromium:930680
Change-Id: I9ccbcbdaf11556596ed5df5c08829b7ae329cab7
Reviewed-on: https://chromium-review.googlesource.com/c/1480383
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59775}
With 32-bit kTaggedSize string data address may not be kSystemPointerSize
aligned.
Bug: v8:7703
Change-Id: I243e6844bed62d96f8b07328fffe23e83512e8e5
Reviewed-on: https://chromium-review.googlesource.com/c/1481217
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59772}
This adds special prining for the different spill kinds.
Change-Id: Ib03da8e46b98c62b83c686ee90ae24c9052ddb39
Reviewed-on: https://chromium-review.googlesource.com/c/1477743
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59771}
With 32-bit kTaggedSize small strings may be not externalizable.
Bug: v8:7703
Change-Id: I34002568214742dadb2358fca97dfb4b92a5342a
Reviewed-on: https://chromium-review.googlesource.com/c/1480373
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59770}
It's only used in tests, and for some reason v8 refers to a macro defined
in src.git, so I need to remove this in v8 first before I can remove it
in Chromium.
Bug: chromium:934255
Change-Id: I31ea32aa43cf7a5f518def7b91dce99dcb268709
Reviewed-on: https://chromium-review.googlesource.com/c/1480911
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59769}
Port adb7e37b28
Original Commit Message:
In the Crankshaft days we (mis)used the Representation to also express
the various internal representations that the compiler understands. But
with TurboFan we now have proper MachineRepresentation and MachineType,
which do that independently. So there's no need to have this in the
Representation class anymore, and instead the Representation class only
needs to deal with the field representations.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ie3c8062786d5fd42872e22be01cea45d719ea0a4
Reviewed-on: https://chromium-review.googlesource.com/c/1479972
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59767}
This makes the asm.js validator reject source with trailing expressions
after the module exporting return statement. Most of the time trailing
statements would not affect semantics, since they are unreachable. In
some cases we might hide an expected ReferenceError tough.
R=leszeks@chromium.org
TEST=mjsunit/regress/regress-crbug-934138
BUG=chromium:934138
Change-Id: I790366204f5e9c943715a065b5229f2442e2c86e
Reviewed-on: https://chromium-review.googlesource.com/c/1481216
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59766}
This change adds two spilling modes: SpillAtDefinition and SpillDeferred.
The former is the known spilling mode where we spill at definition. The
latter spills only in deferred code regions. This is implemented based on
control flow aware allocation and its invariants.
The effect is mostly the same as splintering with the exception of
forward looking allocation decisions still being impacted by register
constraints in deferred code.
Change-Id: Ia708e5765dd095196a8127deb2d8bec950d37e04
Reviewed-on: https://chromium-review.googlesource.com/c/1437118
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59759}
This merges the "do-nothing" case with the "done" case as the former
is no longer useful. This also fixes a bug where the idle time handler
would not make progress by always returning "do-nothing".
Change-Id: Ibdd3189e4fd35acc5405aa82a13ea8ee2fd74cc6
Reviewed-on: https://chromium-review.googlesource.com/c/1478695
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59758}
This cl moves the valid feeback vector checks to the builtins and uses
fast paths runtime when possible even whithout a valid feedback vector.
For LoadNamedProperty it calls LoadIC_Uninitialized which does not need
any type feedback and for LoadKeyedProperty it follows the megamorphic path
but doesnot use the stub cache.
Bug: v8:8293
Change-Id: I6ef9653e3f43c15cb882cbf82c3c2f63fb705a81
Reviewed-on: https://chromium-review.googlesource.com/c/1475393
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59755}
The DCHECK verified capacity just before the call to EnsureCapacity()
(which extends capacity if needed). This DCHECK can just be removed
since FixedArray::set() already checks the given index is in-bounds.
Drive-by: Remove similar duplicate DCHECKs in FixedArrayBuilder.
Bug: chromium:933776
Change-Id: I9f058548063a170ea6dce112a3877792887efcca
Reviewed-on: https://chromium-review.googlesource.com/c/1479955
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59753}
The default TracingController (used by d8 and Node) has some concurrency
issues. The new test flushes these out, when a second thread logs trace
events while the main thread calls StopTracing().
- Use an acquire load in UpdateCategoryGroupEnabledFlags() because this
was racing with GetCategoryGroupEnabled() where a new category is
added in the slow path. g_category_groups is append-only, but
reads/writes to g_category_index need to be correctly ordered so that
new categories are added and only then is the change to the index
visible. The relaxed load ignored this and caused unsynchronized
read/write.
- Use a relaxed load in ~ScopedTracer() to access category_group_enabled
as this previously used a non-atomic operation which caused a race
with UpdateCategoryGroupEnabledFlag() which does a relaxed store.
- Replace TracingController::mode_ with an atomic bool as read/writes to
mode_ were not synchronized and caused TSAN errors. It only has two
states and it doesn't seem like we will extend this so just convert it
to bool.
- Take the lock around calling trace_object->Initialize in
AddTraceEvent(), and around trace_buffer_->Flush() in StopTracing().
These two raced previously as the underlying TraceBufferRingBuffer
passes out pointers to TraceObjects in a synchronized way, but the
caller (AddTraceEvent) then writes into the object without
synchronization. This leads to races when Flush() is called, at which
time TraceBufferRingBuffer assumes that all the pointers it handed out
are to valid, initialized TraceObjects - which is not true because
AddTraceEvent may still be calling Initialize on them. This could be
the cause of issues in Node.js where the last line of tracing/logging
sometimes gets cut off. This is kind of a band-aid solution - access
to the TraceObjects handed out by the ring buffer really needs proper
synchronization which at this point would require redesign. It's quite
likely we will replace this with Perfetto in the near future so not
much point investing in this code right now.
- Enable TracingCpuProfiler test which was flaky due to these bugs.
Bug: v8:8821
Change-Id: I141296800c6906ac0e7f3f21dd16d861b07dae62
Reviewed-on: https://chromium-review.googlesource.com/c/1477283
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#59752}
In the Crankshaft days we (mis)used the Representation to also express
the various internal representations that the compiler understands. But
with TurboFan we now have proper MachineRepresentation and MachineType,
which do that independently. So there's no need to have this in the
Representation class anymore, and instead the Representation class only
needs to deal with the field representations.
Bug: v8:8749, v8:8834, v8:8865
Change-Id: I34ea9558b5fdf20d6c7939b52762eaffd4316b06
Reviewed-on: https://chromium-review.googlesource.com/c/1479954
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59750}
This is a reland of 1fdf64059d
Original change's description:
> Make format torque tools work on win
>
> Reformatting Torque file is required to upload a CL
> but it can only work on POSIX
>
> Change-Id: I51283e3f6b29abf492be7efb5b8f10454d09fb37
> Reviewed-on: https://chromium-review.googlesource.com/c/1475919
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Commit-Queue: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59719}
Change-Id: I09a19a9989091205eb413fd60b2e8bec289092fd
Reviewed-on: https://chromium-review.googlesource.com/c/1479530
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59748}
New tests added for these calls:
* evaluateOnCallFrame
* setAsyncCallStackDepth
* setBreakpoint
* setVariableValue
For setAsyncCallStackDepth, this change updates the test to manufacture async callstacks in a different way so that there is more than one. The previous promise chain method was broken by f61facf.
Change-Id: I9083b0b1c08849d4c7ebb5349cfa4489f551aa39
Reviewed-on: https://chromium-review.googlesource.com/c/1465118
Commit-Queue: Jeff Fisher <jeffish@microsoft.com>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59745}
Currently, it is possible to make the Torque compiler emit uncompilable
C++ code if a 'generates' clause is missing. Rather than making the
developer spelunk through generated code to find out what went wrong,
we can catch this error earlier and print a useful message.
Bug: v8:7793
Change-Id: I49fabc1d39f398bf322523901941494b8dab0506
Reviewed-on: https://chromium-review.googlesource.com/c/1477964
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59744}
I missed this one in my previous CL.
R=jarin@chromium.org
Change-Id: Ie4b912ee7e3367da48c0d4b092ad09e3f81de788
Reviewed-on: https://chromium-review.googlesource.com/c/1477677
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59743}
This extends the "test-jump-table-assembler" stress test to supported
architectures. Note that on both PPC and S390 the tests flushes out the
race during jump table patching pretty reliably. Fixing this issue is
outside the scope of this change, this just ensures test coverage exists
but keeps the test in question disabled.
R=clemensh@chromium.org
TEST=cctest/test-jump-table-assembler
BUG=v8:8018
Change-Id: Ia299ed2a42f9858019627270a25026b53f3628d3
Reviewed-on: https://chromium-review.googlesource.com/c/1478200
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59738}
Those shard configs should stay in sync with master builders.
NOTRY=true
TBR=sergiyb@chromium.org
Change-Id: I083a4eed8ded884ad8345ba65153f424c9f0ef2f
Reviewed-on: https://chromium-review.googlesource.com/c/1475536
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59737}
This reverts commit 1fdf64059d.
Reason for revert: Alters behavior on linux; we need to investigate
Original change's description:
> Make format torque tools work on win
>
> Reformatting Torque file is required to upload a CL
> but it can only work on POSIX
>
> Change-Id: I51283e3f6b29abf492be7efb5b8f10454d09fb37
> Reviewed-on: https://chromium-review.googlesource.com/c/1475919
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Commit-Queue: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59719}
TBR=mvstanton@chromium.org,bmsdave@gmail.com,duongn@microsoft.com
Change-Id: I8845fa1d1ddf5ce841a84ef59c9572673e4a2510
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1478199
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59736}
