The reason:
same as the CL #37371 (Issue 2111493002: X87: disable some sin/cos/expm1/tan test cases for x87.), please
refer https://codereview.chromium.org/2111493002 for more details.
For Acosh/ASinh test cases, the expected values are pre-defined double precision values, the results
generated by C++ function are extended double precision as the extended double precision is default for x87
Gcc compiler and std lib on linux platform. The comparison of different precisons caused some of those test
cases failed.
This CL disables Acosh/ASinh test cases for x87.
BUG=
Review-Url: https://codereview.chromium.org/2122593002
Cr-Commit-Position: refs/heads/master@{#37516}
The reason:
In CreateRandomOperand(), It used the register index 1 for ExplicitOperand(LocationOperand::REGISTER, rep,
GetRegisterCode(rep, 1)).
For x87 turbofan compiler, there's only 1 allocatable Float/Double register, i.e.: register index 0. the
GetRegisterCode(rep, 1) in ExplicitOperand() always return false when rep is MachineRepresentation::kFloat32/kFloat64.
It caused the test-gap-resolver/FuzzResolver failed at DCHECK_IMPLIES(kind == REGISTER && rep == MachineRepresentation::kFloat32,
FloatRegister::from_code(index).IsAllocatable(RegisterConfiguration::TURBOFAN)), src/compiler/instruction.cc, line 259, under
debug mode.
This CL disable test-gap-resolver/FuzzResolver test case for x87.
BUG=
Review-Url: https://codereview.chromium.org/2120203002
Cr-Commit-Position: refs/heads/master@{#37515}
Reason for revert:
[Sheriff] Breaks without i18n:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/8466
Original issue's description:
> [intrinsic] Drop the %_ValueOf intrinsic.
>
> This drops the %_ValueOf intrinsic, but keeps the runtime entry
> %ValueOf for now, by either migrating the functionality (mostly
> Debug mirror or toString/valueOf methods) to C++ or TurboFan
> builtins, or switching to the %ValueOf runtime call when it's
> not performance critical anyways.
>
> The %_ValueOf intrinsic was one of the last blockers for fixing
> the unsound machine operator typing in TurboFan.
>
> R=yangguo@chromium.org
> BUG=v8:5049
>
> Committed: https://crrev.com/293bd7882987f00e465710ce468bfb1eaa7d3fa2
> Cr-Commit-Position: refs/heads/master@{#37512}
TBR=yangguo@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2117273002
Cr-Commit-Position: refs/heads/master@{#37514}
This concerns formatting of calls to, e.g., Math.acos in stack traces,
in which the receiver is an object with an attached toString tag. If
such a tag exists, use it to format the receiver typename to ensure that
the stack trace includes 'Math.acos' instead of 'Object.acos'.
R=yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2110683007
Cr-Commit-Position: refs/heads/master@{#37513}
This drops the %_ValueOf intrinsic, but keeps the runtime entry
%ValueOf for now, by either migrating the functionality (mostly
Debug mirror or toString/valueOf methods) to C++ or TurboFan
builtins, or switching to the %ValueOf runtime call when it's
not performance critical anyways.
The %_ValueOf intrinsic was one of the last blockers for fixing
the unsound machine operator typing in TurboFan.
R=yangguo@chromium.org
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2126453002
Cr-Commit-Position: refs/heads/master@{#37512}
port f59a23356b (r37500)
original commit message:
Stack trace generation requires access to the receiver; and while the
receiver is already on the stack, we cannot determine its position
during stack trace generation (it's stored in argv[0], and argc is only
stored in a callee-saved register).
This patch grants access to the receiver by pushing argc onto builtin
exit frames as an extra argument. Compared to simply pushing the
receiver, this requires an additional dereference during stack trace
generation, but one fewer during builtin calls.
BUG=
Review-Url: https://codereview.chromium.org/2118413002
Cr-Commit-Position: refs/heads/master@{#37511}
Rolling v8/build to 536d6fe8a0df34c0c412da483375d71b9b931afa
Rolling v8/buildtools to d2664782a3855d5be8cbbfd3c23b6652926de8cc
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2124673002
Cr-Commit-Position: refs/heads/master@{#37509}
port bd0d9e7d87 (r37477)
original commit message:
This optimizes the passing of stack parameters in function calls.
For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
and this optimization isn't used at all.
Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.
The key aspect of this change is that adjustment to the stack pointer
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.
BUG=
Review-Url: https://codereview.chromium.org/2120413002
Cr-Commit-Position: refs/heads/master@{#37508}
If incremental GC starts before imports linking, and sees a wasm
function, it won't revisit that after the imports that function are linked.
As a result, the import code objects may be GC-ed. This change
addresses this issue.
BUG=
Review-Url: https://codereview.chromium.org/2113183002
Cr-Commit-Position: refs/heads/master@{#37507}
Currently there are two logic in Ticker, one is to try to request a
pre-allocated TickSample from CpuProfiler and then initialize it, and if the
request fails, it will initialize a local TickSample. The other is it will pass
an initialized TickSample to Profiler to log into v8.log.
This patch splits Ticker into two samplers, the first one remains in log.cc to
collect samples and pass to Profiler for logging, the second one will be called
by ProfilerEventsProcessor, and only use the circular queue only.
BUG=v8:4789
LOG=N
Review-Url: https://codereview.chromium.org/2108393002
Cr-Commit-Position: refs/heads/master@{#37506}
- Remove unused flags (SweepingParallelism, SweepingMode)
- Make them runtime parameters rather then template parameters
- Deduce skip list rebuilding from the page itself
BUG=
Review-Url: https://codereview.chromium.org/2124433002
Cr-Commit-Position: refs/heads/master@{#37502}
This is compatible with what Crankshaft does, and therefore should be
safe. The runtime doesn't perform any JavaScript-observable side
effects during the stack check.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2118253002
Cr-Commit-Position: refs/heads/master@{#37501}
Stack trace generation requires access to the receiver; and while the
receiver is already on the stack, we cannot determine its position
during stack trace generation (it's stored in argv[0], and argc is only
stored in a callee-saved register).
This patch grants access to the receiver by pushing argc onto builtin
exit frames as an extra argument. Compared to simply pushing the
receiver, this requires an additional dereference during stack trace
generation, but one fewer during builtin calls.
BUG=v8:4815
Review-Url: https://codereview.chromium.org/2106883003
Cr-Commit-Position: refs/heads/master@{#37500}
port 0a0fe8fb8b (r37476)
original commit message:
Import fdlibm versions of acos, acosh, asin and asinh, which are more
precise and produce the same result across platforms (we were using
libm versions for asin and acos so far, where both speed and precision
depended on the operating system so far). Introduce appropriate TurboFan
operators for these functions and use them both for inlining and for the
generic builtin.
Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
to ensure that their behavior is always exactly the same as the inlined
TurboFan version (i.e. C++ truncation semantics for double to float
don't necessarily meet the JavaScript semantics).
For completeness, also migrate Math.sign, which can even get some nice
love in TurboFan.
Drive-by-fix: Some alpha-sorting on the Math related functions, and
cleanup the list of Math intrinsics that we have to export via the
native context currently.
BUG=
Review-Url: https://codereview.chromium.org/2122643002
Cr-Commit-Position: refs/heads/master@{#37496}
The re-typer now only types a node if its inputs are all typed with the
exception of phi nodes. This works because all cycles in the graph have
to contain a phi node.
BUG=chromium:625558
Review-Url: https://codereview.chromium.org/2120243002
Cr-Commit-Position: refs/heads/master@{#37493}
port 5febc27b5d (r37416)
original commit message:
Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.
Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.
BUG=
Review-Url: https://codereview.chromium.org/2120873002
Cr-Commit-Position: refs/heads/master@{#37490}
Since python3 does not use the old print statement, it may not be able
to load gdb-v8-support.py script in gdb as below:
(gdb) source tools/gdb-v8-support.py
File "tools/gdb-v8-support.py", line 170
print result
^
SyntaxError: Missing parentheses in call to 'print'
This fixes print statement for both python2 and python3.
R=jochen@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2084163004
Cr-Commit-Position: refs/heads/master@{#37488}
Rolling v8/build to 76d9f8b4fcae07fb82f28295468cf92bade935bd
Rolling v8/buildtools to db6179b29f90d28026b0cb23ef71d56ec31b8bd6
Rolling v8/tools/clang to 775e2f874b9f53f0e82c4e7c61dc29f3cdcb3379
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2117993002
Cr-Commit-Position: refs/heads/master@{#37486}
This patch implements "immutable prototype exotic objects" from the ECMAScript
spec, which are objects whose __proto__ cannot be changed, but are not otherwise
frozen. They are introduced in order to prevent a Proxy from being introduced
to the prototype chain of the global object.
The API is extended by a SetImmutablePrototype() call in ObjectTemplate, which
can be used to vend new immutable prototype objects. Additionally, Object.prototype
is an immutable prototype object.
In the implementation, a new bit is added to Maps to say whether the prototype is
immutable, which is read by SetPrototype. Map transitions to the immutable prototype
state are not saved in the transition tree because the main use case is just for
the prototype chain of the global object, which there will be only one of per
Context, so no need to take up the extra word for a pointer in each full transition
tree.
BUG=v8:5149
Review-Url: https://codereview.chromium.org/2108203002
Cr-Commit-Position: refs/heads/master@{#37482}
Port b86ac0e05a
Original commit message:
Both of these were broken in different ways:
* On arm, the loop counter was passed as argc on the stack.
* On arm64, we passed argc + 1 instead of argc.
The result in both cases was an incorrect receiver for the builtin frame
when generating stack traces.
BUG=v8:4815
Review-Url: https://codereview.chromium.org/2120463002
Cr-Commit-Position: refs/heads/master@{#37481}
This makes the elimination of checkpoints flowing effect-wise into nodes
having the {Return} operator more permissive. We can cut out checkpoints
even when they are not wholly owned by the return. This also alleviates
a problem where TCO no longer applies.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-624747
BUG=chromium:624747
Review-Url: https://codereview.chromium.org/2118793002
Cr-Commit-Position: refs/heads/master@{#37480}
This optimizes the passing of stack parameters in function calls.
For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
and this optimization isn't used at all.
Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.
The key aspect of this change is that adjustment to the stack pointer
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.
Review-Url: https://codereview.chromium.org/2082263002
Cr-Commit-Position: refs/heads/master@{#37477}
Import fdlibm versions of acos, acosh, asin and asinh, which are more
precise and produce the same result across platforms (we were using
libm versions for asin and acos so far, where both speed and precision
depended on the operating system so far). Introduce appropriate TurboFan
operators for these functions and use them both for inlining and for the
generic builtin.
Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
to ensure that their behavior is always exactly the same as the inlined
TurboFan version (i.e. C++ truncation semantics for double to float
don't necessarily meet the JavaScript semantics).
For completeness, also migrate Math.sign, which can even get some nice
love in TurboFan.
Drive-by-fix: Some alpha-sorting on the Math related functions, and
cleanup the list of Math intrinsics that we have to export via the
native context currently.
BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
TBR=rossberg@chromium.orgR=franzih@chromium.org
Review-Url: https://codereview.chromium.org/2116753002
Cr-Commit-Position: refs/heads/master@{#37476}
This ensures no eager bailout point is emitted after a comma expression
in test context where the right-hand side omitted an eager bailout point
as well. This is to stay in sync with full-codegen.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-624919
BUG=chromium:624919
Review-Url: https://codereview.chromium.org/2113893004
Cr-Commit-Position: refs/heads/master@{#37475}
Migrate Math.hypot() from JS to C++ builtins. Use normalization and
Kahan summation to avoid overflow and rounding errors.
R=bmeurer@chromium.org
BUG=v8:5165, v8:5086
LOG=n
Review-Url: https://codereview.chromium.org/2102223005
Cr-Commit-Position: refs/heads/master@{#37473}
Both of these were broken in different ways:
* On arm, the loop counter was passed as argc on the stack.
* On arm64, we passed argc + 1 instead of argc.
The result in both cases was an incorrect receiver for the builtin frame
when generating stack traces.
BUG=v8:4815
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2112883002
Cr-Commit-Position: refs/heads/master@{#37471}
port 588e15c034 (r37345)
original commit message:
The opcodes for 'cmpw r/m16, r16' and 'cmpw r16, r/m16' were swapped, causing a few issues when less than/greater than comparison were performed.
Adds a regression test.
BUG=
Review-Url: https://codereview.chromium.org/2119793002
Cr-Commit-Position: refs/heads/master@{#37469}
port e607e12ea0 (r37323)
original commit message:
Introduce a new machine operator Float64Pow that for now is backed by
the existing MathPowStub to start the unification of Math.pow, and at
the same time address the main performance issue that TurboFan still has
with the imaging-darkroom benchmark in Kraken.
Also migrate the Math.pow builtin itself to a TurboFan builtin and
remove a few hundred lines of hand-written platform code for special
handling of the fullcodegen Math.pow version.
BUG=
Review-Url: https://codereview.chromium.org/2119773003
Cr-Commit-Position: refs/heads/master@{#37468}
Rolling v8/build to c80c063b314ab9cc6c3c5955c7444c2fa514bcec
Rolling v8/buildtools to 454e53abae6e4d68ee992b0a93a4174b75519393
Rolling v8/tools/mb to ea4154b4daca60a5f5c04ef764b7eaf50362250c
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2113243002
Cr-Commit-Position: refs/heads/master@{#37467}
