- Perform lane checks using FP compare instead of reinterpret casts. 0 and -0
will be different under I32 compare.
- Some arithmetic operations can generate NaN results, such as adding -Inf
and +Inf. Skip these tests until we have a way to do more sophisticated
FP comparisons in the SIMD tests.
- Eliminate a redundant F32x4 parameter for FP SIMD vector checking. We will only have this one FP type.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2594043002
Cr-Original-Commit-Position: refs/heads/master@{#42154}
Committed: 5560bbb498
Review-Url: https://codereview.chromium.org/2594043002
Cr-Commit-Position: refs/heads/master@{#43528}
Reason for revert:
Breaks tree, i.e. https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/18928/steps/Check/logs/grow-memory
Original issue's description:
> [wasm] Initial signal handler
>
> This is basically the minimum viable signal handler for Wasm bounds checks.
> It includes the TLS check and the fine grained instructions checks. These
> two checks provide most of the safety for the signal handler. Future CLs will
> add code range and data range checks for more robustness.
>
> The trap handling code and data structures are all in src/trap-handler, with
> the code that actually runs in the signal handler confined to
> src/trap-handler/signal-handler.cc.
>
> This changes adds a new V8 API that the embedder should call from a signal
> handler that will give V8 the chance to handle the fault first. For hosts that
> do not want to implement their own signal handler, we include the option to
> install a simple one. This simple handler is also used for the tests.
>
> When a Wasm module is instantiated, information about each function is passed
> to the trap handler, which is used to classify faults. These are removed during
> the instance finalizer.
>
> Several future enhancements are planned before turning this on by default.
> Obviously, the additional checks will be added to MaybeHandleFault. We are
> also planning to add a two-level CodeObjectData table that is grouped by
> isolates to make cleanup easier and also reduce potential for contending on
> a single data structure.
>
> BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
>
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Commit-Position: refs/heads/master@{#43523}
> Committed: a5af7fe9eeTBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org,eholk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2723133003
Cr-Commit-Position: refs/heads/master@{#43525}
This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.
The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.
This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.
When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.
Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43523}
As of version 13, delegates do not need to worry about colliding tags with the
tags reserved by v8, since v8 inserts a "host object" prefix beforehand. Thus
the format is now suitable for more general use, without opting into the "legacy"
mode that had this caveat.
Review-Url: https://codereview.chromium.org/2722213002
Cr-Commit-Position: refs/heads/master@{#43521}
This reverts commit b23b2c107b.
Reason for revert: Makes Linux debug bot sad
Original change's description:
> [builtins] Port TypedArrayInitialize to CodeStubAssembler.
>
> Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
> because we always go to the C++ builtin. Port the builtin to CSA
> to improve performance, and to clean up the implementation, which is
> split across multiple files and pieces at the moment.
>
> This CL increases the performance with --future to roughly the same
> as with crankshaft.
>
> BUG=v8:5977
>
> Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
> Reviewed-on: https://chromium-review.googlesource.com/445717
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43518}
TBR=cbruni@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5977
Change-Id: I5d5bc8b4677a405c716d78e688af80ae9c737b4a
Reviewed-on: https://chromium-review.googlesource.com/448558
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43520}
Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
because we always go to the C++ builtin. Port the builtin to CSA
to improve performance, and to clean up the implementation, which is
split across multiple files and pieces at the moment.
This CL increases the performance with --future to roughly the same
as with crankshaft.
BUG=v8:5977
Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
Reviewed-on: https://chromium-review.googlesource.com/445717
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43518}
port 69747e2658f1de973ba75c60fe31b402bd6031a5(r42680)
original commit message:
We turn a JSCallFunction node for
f.apply(receiver, arguments)
into a JSCallForwardVarargs node, when the arguments refers to the
arguments of the outermost optimized code object, i.e. not an inlined
arguments, and the apply method refers to Function.prototype.apply,
and there's no other user of arguments except in frame states.
We also replace the arguments node in the graph with a marker for
the Deoptimizer similar to Crankshaft to make sure we don't materialize
unused arguments just for the sake of deoptimization. We plan to replace
this with a saner EscapeAnalysis based solution soon.
BUG=
Review-Url: https://codereview.chromium.org/2681783002
Cr-Commit-Position: refs/heads/master@{#43516}
This fixes a corner-case in the above predicate that was introduced to
allow fully disabling optimization using %NeverOptimizeFunction. This
property of a function is a transient property (i.e. changes over time),
whereas {UseTurboFan} is designed to be a static property (i.e. gives
same answer over time). Violating this led to cases where functions got
optimization disabled for other reasons would suddenly be baselined.
The correct place to check transient properties is when optimization is
requested.
R=jarin@chromium.org
TEST=mjsunit/never-baseline
Change-Id: I37eb0c70d2b39704be29fd4bda76975bfbede66b
Reviewed-on: https://chromium-review.googlesource.com/447937
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43514}
String::SlowFlatten assumed that ConsStrings with empty first parts have
flattened strings as their second part. TurboFan, however, can create
ConsStrings with empty first parts and arbitrary second parts. With
this CL we call String::Flatten on the second part of a ConsString if
the first part is empty, but only when String::Flatten would not call
String::SlowFlatten.
R=jkummerow@chromium.org
BUG=chromium:696651
Change-Id: I9acb681de1be695e1ec2f6f6d28b9e4dc4344e98
Reviewed-on: https://chromium-review.googlesource.com/448457
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43513}
This CL fixes unused lambda captures for big endian targets when Clang
is used for build V8.
TEST=
BUG=
Review-Url: https://codereview.chromium.org/2725613002
Cr-Commit-Position: refs/heads/master@{#43511}
This generally shouldn't hit since prototypes are supposed to be fast; but it makes it more uniform anyway.
This CL also drops the limitation not supporting keyed loads with normal access. There's no point in returning the slow stub there.
BUG=
Change-Id: I5578269f6c64762610e885740a692d1e91aa6aa2
Reviewed-on: https://chromium-review.googlesource.com/447698
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43508}
The maybe-assigned flag of the catch variable was not preserved.
BUG=v8:5636,chromium:696332
Change-Id: I9c55e1b1312bdebc53bc45bc3ca1c982bdbe9846
Reviewed-on: https://chromium-review.googlesource.com/447680
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43506}
This will be useful for sharing the implementation with
SharedArrayBuffer.prototype.slice.
BUG=v8:5897
Review-Url: https://codereview.chromium.org/2697013009
Cr-Commit-Position: refs/heads/master@{#43503}
BUG=
Change-Id: Id77205450d286be228b493deb69e1489a1e12895
Reviewed-on: https://chromium-review.googlesource.com/445906
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43501}
BUG=v8:6022
Change-Id: I54205cb3ecc2dd31ed62e55726f0ec5fcd202c30
Reviewed-on: https://chromium-review.googlesource.com/446349
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43500}
Previously, we over-approximated Scope::scope_calls_eval_ in
arrow functions: if either the outer scope or the arrow function
parameters had a direct eval call, we marked both scopes as calling
eval. This over-approximation kept getting us into trouble, though,
especially when eager or lazy parsing would disagree about the
"calls eval" bit.
This patch instead tracks eval calls accurately, using a boolean on
Scope::Snapshot that is reset as appropriately depending on whether
a particular AssignmentExpression turned out to be an arrow parameter
list or not.
BUG=chromium:691687
Change-Id: I527dc59b4d32a2797805ff26dc9f70b1311377b2
Reviewed-on: https://chromium-review.googlesource.com/446094
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43499}
This is more useful than always returning undefined.
BUG=v8:1569,v8:5978
Change-Id: Id10cf87f7865db1a85de412460eaead4e4bf3b62
Reviewed-on: https://chromium-review.googlesource.com/446846
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43498}
The order in which things were done wasn't quite correct and lead
to wrong behaviour for certain circular module graphs.
BUG=v8:1569,chromium:694566
Change-Id: I291186e261268c853a30ad891ff362904e0b28ef
Reviewed-on: https://chromium-review.googlesource.com/447399
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43497}
This is mostly prework to also support prototype chain checks using data handlers
BUG=
Change-Id: I70aac1e86e45c78dfdc9f02d06b7e821494a4c9c
Reviewed-on: https://chromium-review.googlesource.com/447679
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43495}
With the params (a, b, ...c) the param / variable declaration order used to be
"temp, temp, c, a, b". Now it is "temp, temp, a, b, c" as you'd expect. This
makes it easier for PreParser to match the parameter order of Parser.
R=verwaest@chromium.org
BUG=v8:5516
Change-Id: I79da04ef3f812bf52c032bed6263c009fecb7988
Reviewed-on: https://chromium-review.googlesource.com/447677
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43490}
Reason for revert:
With the Windows bots fixed in https://chromium-review.googlesource.com/445786 , this should be good to reland. Thanks, Michael!
Original issue's description:
> Revert of [test] Speculatively remove local-tests from archive (patchset #2 id:20001 of https://codereview.chromium.org/2643983002/ )
>
> Reason for revert:
> Breaks all windows bots:
> https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/6811
>
> Original issue's description:
> > [test] Remove local-tests from test262 archive and add to .isolate
> >
> > This might help fix the bots, which are broken in e.g.,
> > https://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel_ng_triggered/builds/14011
> >
> > The archive was added in order to transmit test262 tests more rapidly.
> > It doesn't serve much of a purpose for local-tests. I naively added
> > local-tests there out of symmetry. However, the BUILD.gn file does not
> > regenerate an archive when files are only deleted and not added or
> > changed. Since the performance concern is not present for the small
> > volume of local-tests, this patch reverts to the more normal mechanism
> > for sending over dependencies, with test262.isolate.
> >
> > R=adamk
> >
> > Review-Url: https://codereview.chromium.org/2643983002
> > Cr-Commit-Position: refs/heads/master@{#42485}
> > Committed: 9f545ea96f
>
> TBR=adamk@chromium.org,littledan@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Review-Url: https://codereview.chromium.org/2640223003
> Cr-Commit-Position: refs/heads/master@{#42491}
> Committed: 4ffe0850dbTBR=adamk@chromium.org,machenbach@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2725643002
Cr-Commit-Position: refs/heads/master@{#43488}
Unibrow is currently at Unicode version 7.0.0, which does not
include mongolian vowel separator (\u180E) as white space. In
order to appease test262 at the time however we kept it as a
whitespace.
Test262 has since then been updated. And while this is not an
update of unibrow, we are removing \u180E as white space here.
R=jshin@chromium.org, littledan@chromium.org
BUG=v8:5155
Review-Url: https://codereview.chromium.org/2720953003
Cr-Commit-Position: refs/heads/master@{#43485}
