During a C call, a previous value of the stack pointer is stored in a
platform specific callee saved register. Loading the out argument of the
C call might overwrite the value in that register, if the destination
register collides with the platform specific register. Hence, do first
use that register to restore the previous stack pointer, and only then
load the out argument.
Similarly, when pushing arguments to the stack, do first push all
values and then set the platform specific register in order to avoid
overwriting an argument value held in that register.
Drive-by: Fix offset computations for parameters pushed to the stack
for c calls.
R=titzer@chromium.org
Bug: chromium:820802,chromium:820896,chromium:820807,v8:6600
Change-Id: If4567467b7912454f0bd2cad5927233c98894b03
Reviewed-on: https://chromium-review.googlesource.com/959064
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51916}
Since f32 and f64 constants are loaded into registers right away, we
never need to spill them as constants later.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I7da91bb995e5127b0a9cb1a12a0fcd6566ed98ff
Reviewed-on: https://chromium-review.googlesource.com/960943
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51915}
Runtime.terminateExecution terminates current or next JavaScript
call. Termination flag is automatically reset as soon as v8 call
or microtasks are completed.
R=pfeldman@chromium.org
Bug: chromium:820640
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ie21c123be3a61fe25cf6e04c38a8b6c664622ed7
Reviewed-on: https://chromium-review.googlesource.com/957386
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51912}
While deserializing a BigInt with the --harmony-bigint flag off is
harmless in itself, trying to wrap one as an Object (either during
deserialization of a JSValue or later from user code) requires the
BigInt constructor to be available. Since there's no strong reason
to support deserialization of BigInts without the flag, this patch
simply disallows it, which fixes the problem.
Bug: chromium:820819
Change-Id: I024a4f13715bbe95ee8eb6e1710e8f47ca227644
Reviewed-on: https://chromium-review.googlesource.com/959802
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51911}
Function names are optional in wasm and might not be present for most
functions. Instead of storing an empty name with each function, this
change loads names, if present, on first access of the name.
This also fixes an inconsistency with streaming compilation. Under
streaming compilation, functions are compiled before parsing the name
section. Hence, they always received an empty name. With this change,
assignment of names is typically deferred until the whole module was
parsed.
Bug: chromium:820291
Change-Id: I86d76aa40b7c45897d152725547795c8b6b9b9ba
Reviewed-on: https://chromium-review.googlesource.com/955647
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51909}
This can protect against refactoring bugs when adding fields to an
aggregate-initialized struct.
Change-Id: Id2e9824a1adb8bf5dbdc3775dc59ee9f18c43412
Reviewed-on: https://chromium-review.googlesource.com/960324
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51907}
This allows to enable -Wmissing-field-initializers in a future CL.
Change-Id: I67ac828be97bf4f283e97486981adebaf8e4ebf9
Reviewed-on: https://chromium-review.googlesource.com/957731
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51904}
BuildHoleCheckAndThrow in the bytecode graph builder did not
insert a loop exit; this defeated loop peeling, so we missed
out on performance. This CL inserts the LoopExit in that place,
and inserts two TODOs at places where additional loop exits might
be needed.
Bug: v8:7099
Change-Id: I08c08103cf125d505e37d3aa29a79aaff63a2d61
Reviewed-on: https://chromium-review.googlesource.com/960123
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51903}
When Promise.all is called with something which violates the iterable
contract, the resulting error should be provided by returning a rejected
promise, not by throwing.
Bug: v8:7553
Change-Id: I2769b09b49c9b80ef380419489416fc0fabff51b
Reviewed-on: https://chromium-review.googlesource.com/959599
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51902}
We were attempting to assemble code into the MacroAssembler buffer after
executing it, without resetting the permissions. As a result, tests that
are using START/END multiple times were failing.
Change-Id: Id84c6a07212a869f98edbd33d86ff70ee6c819db
Reviewed-on: https://chromium-review.googlesource.com/939388
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#51901}
Keep track of RelocInfo::Mode for ConstantPoolEntries in the assembler,
so that ARM's constant pool de-duping does not accidentally dedupe
constants with the same value but different reloc modes (e.g. the first
Code object in the builtins table as a CODE_TARGET vs. the builtin table
itself as an EXTERNAL_REFERENCE).
Change-Id: I15fad5b83bb99688726e66e0e290149025c6c059
Reviewed-on: https://chromium-review.googlesource.com/958864
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51900}
Now that wasm code lives in its own native heap, we no longer need to
switch protection for the js code space. Hence, remove a left-over
CodeSpaceMemoryModificationScope.
Change-Id: I80830bc4b0eee672c9e5c7ba0088ffcbc5b2da57
Bug: v8:7549
Reviewed-on: https://chromium-review.googlesource.com/960002
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51899}
This removes the last use of %AppendElement (and the function itself),
which was in the pattern rewriter's code for destructuring assignment
with an array rest pattern. In its place, it introduces a
StoreInArrayLiteral AST node that corresponds to the StoreInArrayLiteral
bytecode (which in turn corresponds to the StoreInArrayLiteral IC).
Change-Id: I1d212407b025cf0919263d119f6f47c88bd9a71e
Reviewed-on: https://chromium-review.googlesource.com/955307
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51898}
Implement instructions for stack operations.
Also, fix some issues that came up after implementing them.
Bug: v8:6600
Change-Id: I83dfe621b123081f9ae4d234605358c9ce81420f
Reviewed-on: https://chromium-review.googlesource.com/956072
Commit-Queue: Sreten Kovacevic <sreten.kovacevic@mips.com>
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51897}
The IterableToList helper builtin can return the input JSArray unchanged
if the fast-path detection decides that it doesn't need to iterate the
elements, which means we can also get a JSArray with an elements kind
that is not PACKED_ELEMENTS as a result of IterableToList.
Bug: chromium:821159, v8:7310
Change-Id: I93a886e6b7f1e1a58dd05affa46fea7501cc5a81
Reviewed-on: https://chromium-review.googlesource.com/959323
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51893}
Depending on visitation order the LoadElimination might be find memoized
nodes in its state tables that were killed by other reducers in the mean
time. The LoadElimination must just ignore those stale entries.
Bug: chromium:820820
Change-Id: Ia62e401ff77da547ed215a14074e70aeb5c3a766
Reviewed-on: https://chromium-review.googlesource.com/958843
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51892}
The lifetime of the collator is handled by the JavaScript heap. At the
moment this is implemented with a weak GlobalHandle. With this CL I
change the implementation to use a Managed object instead. In addition I
did some code cleanup.
The main reason for using a Managed is an lsan problem. The final GC in
d8 is triggered before all pending WebAssembly compilations get
canceled. Via the native context, WebAssembly compilation can keep the
Collator wrapper alive, and therefore the collator is never deallocated.
Managed, however, get processed at isolate teardown, independent of the
reachability of the Managed.
TEST=mjsunit/regress/regress-813440
Bug: chromium:813440
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie727eb1aff2144586eb36426cc44a32357c0f822
Reviewed-on: https://chromium-review.googlesource.com/956069
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51886}
The feature in question has been enabled by default for a while and we
no longer need to maintain a configuration without it enabled. Note that
this change only removes the mechanical pieces. Further cleanup enabled
by this will be done as follow-ups.
R=clemensh@chromium.org
BUG=v8:7549
Change-Id: I90e5bcddabe74a18a4d2a88132e8dc93317bcff4
Reviewed-on: https://chromium-review.googlesource.com/958424
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51883}
This is to increase test coverage (ClusterFuzz and such).
Bug: chromium:798964
Change-Id: I4923fb62b52b79636bfc24b76f9642135335c96c
Reviewed-on: https://chromium-review.googlesource.com/958463
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51878}
This CL now uses StringCharCodeAt + StringFromCharCode to replace
StringCharAt. Optimizations are easier to implement if we have both
operators; however, if this tanks performance a lot we have to revert.
R=bmeurer@chromium.org
Bug: v8:7531
Change-Id: I75590cc8b8db57715bc2de9f5b98d0878d62a394
Reviewed-on: https://chromium-review.googlesource.com/956134
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51877}
Add support for f32.demote/f64 and f64.promote/f32.
Both are straight forward to implement on ia32 and x64.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I75213ddf5f422d0aa1d5d9a3bbc90ac32f6950f5
Reviewed-on: https://chromium-review.googlesource.com/955849
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51872}
The single argument version of String.fromCharCode had an unneccessary
runtime call in it; this CL removes it.
Bug: v8:7531
Change-Id: Ieeb7d8aaffb0eabf814a52c51eaff50cb57d87c9
Reviewed-on: https://chromium-review.googlesource.com/955646
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51870}
