This leads to a better handling of the Smi case when we introduce a checked truncation from a number or oddbal to a 32 bit word, which we were previously doing by concatenating a Smi to float64 conversion with a float64 to word32 truncation.
BUG=
Review-Url: https://codereview.chromium.org/2191503002
Cr-Commit-Position: refs/heads/master@{#38091}
This is a first step towards a perfect world where a call interface descriptor is the only place that defines calling convention for a particular code stub.
Review-Url: https://codereview.chromium.org/2172223002
Cr-Commit-Position: refs/heads/master@{#38059}
This allows us to fuse the address computation with the actual memory
access operation on x64, which reduces the register pressure and the
number of instructions. There's probably some follow up cleanup that has
to happen to make sure the machine operator optimizations that are
relevant to word64 computations are also available (similar to what is
already available for word32).
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2183043002
Cr-Commit-Position: refs/heads/master@{#38051}
Always use the BytecodeGraphBuilder when the --turbo-from-bytecode
is enabled, assuming the function should be compiled for Ignition.
Adds a new MaybeOptimizeIgnition function to runtime-profiler
which is called if the function should be optimized from bytecode
rather than going via full-codegen.
BUG=v8:4280
Committed: https://crrev.com/9ca7db914be88e6792a88eab4a1988ee031d70c4
Review-Url: https://codereview.chromium.org/2156753002
Cr-Original-Commit-Position: refs/heads/master@{#37921}
Cr-Commit-Position: refs/heads/master@{#38002}
Implement UnalignedLoad and UnalignedStore optional
turbofan operators and use them in WasmCompiler for unaligned
memory access.
BUG=
Review-Url: https://codereview.chromium.org/2122853002
Cr-Commit-Position: refs/heads/master@{#37988}
So far we don't have a useful way to inline Math.max or Math.min in
TurboFan optimized code. This adds new operators NumberMax and NumberMin
and changes the Float64Max/Float64Min operators to have JavaScript
semantics instead of the C++ semantics that it had previously.
This also removes support for recognizing the tenary case in the
CommonOperatorReducer, since that doesn't seem to have any positive
impact (and actually doesn't show up in regular JavaScript, where
people use Math.max/Math.min instead).
Drive-by-fix: Also nuke the unused Float32Max/Float32Min operators.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2170343002
Cr-Commit-Position: refs/heads/master@{#37971}
See discussion in https://codereview.chromium.org/2156303002/#msg8
With the new --harmony-function-tostring behavior, these tests would
fail without this change. This change makes the tests pass regardless
of whether or not --harmony-function-tostring is used.
All of these changes are simply inserting a space after the "function"
keyword to match the current function toString behavior. When
--harmony-function-tostring is enabled, the toString behavior matches
the spacing used in the function declaration. With the declaration
matching the current formatting, the toString behavior becomes
unaffected by --harmony-function-tostring.
BUG=v8:4958
LOG=n
Review-Url: https://codereview.chromium.org/2161413002
Cr-Commit-Position: refs/heads/master@{#37959}
Reason for revert:
Breaks tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/10758
Original issue's description:
> [Intepreter] Always use BytecodeGraphBuilder when --turbo-from-bytecode
>
> Always use the BytecodeGraphBuilder when the --turbo-from-bytecode
> is enabled, assuming the function should be compiled for Ignition.
> Adds a new MaybeOptimizeIgnition function to runtime-profiler
> which is called if the function should be optimized from bytecode
> rather than going via full-codegen.
>
> BUG=v8:4280
>
> Committed: https://crrev.com/9ca7db914be88e6792a88eab4a1988ee031d70c4
> Cr-Commit-Position: refs/heads/master@{#37921}
TBR=mstarzinger@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2165223002
Cr-Commit-Position: refs/heads/master@{#37925}
Always use the BytecodeGraphBuilder when the --turbo-from-bytecode
is enabled, assuming the function should be compiled for Ignition.
Adds a new MaybeOptimizeIgnition function to runtime-profiler
which is called if the function should be optimized from bytecode
rather than going via full-codegen.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2156753002
Cr-Commit-Position: refs/heads/master@{#37921}
Fixes bug in test-gap-resolver.cc that didn't test different move reps.
Fixes test canonicalization so all slots have the same type (non-float).
Improve test failure text output.
LOG=N
BUG=v8:5187
Review-Url: https://codereview.chromium.org/2169493002
Cr-Commit-Position: refs/heads/master@{#37915}
This CL more or less reverts commit https://codereview.chromium.org/2107733002/
The use of the MathPow code stub that was introduced by that commit caused
problems on arm64, and the MathPow code stub was also an obstacle in the
implementation of parallel code generation.
In addition this CL turns on the mjsunit/wasm/embenchen tests for arm64
which were turned off because of problems with MathPow on arm64.
R=titzer@chromium.org, bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2166793002
Cr-Commit-Position: refs/heads/master@{#37911}
Add a dedicated simplified operator to inline the general case for the
ToBoolean conversion. In a follow up CL we will also use the ToBoolean
hints gathered by the baseline compiler.
Review-Url: https://codereview.chromium.org/2167593002
Cr-Commit-Position: refs/heads/master@{#37882}
This commit introduces support for writing unwinding tables in the
.eh_frame format, to be inserted in the jitdump read by Linux perf and
emitted with FLAG_perf_prof and FLAG_perf_prof_unwinding_info enabled.
x64 is fully implemented and tested, arm and arm64 are untested and the
unwinding information needs to be expanded, but the mechanism is ready.
BUG=v8:4899
LOG=N
Review-Url: https://codereview.chromium.org/2026313002
Cr-Commit-Position: refs/heads/master@{#37799}
I removed or replaced some values in the list of float and double values
in value-helper.h which cannot be represented precisely as floats or
doubles, respectively.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2135243004
Cr-Commit-Position: refs/heads/master@{#37671}
The PlainPrimitiveToNumber operator performs a superset of the operations
previously performed by the BooleanToNumber and StringToNumber operators,
so we can just use the special lowering rules for PlainPrimitiveToNumber
based on the input type and get rid of the specialized operators.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2139183002
Cr-Commit-Position: refs/heads/master@{#37669}
This removes the frame state input representing the before-state from
nodes having any comparison operator. Lowering that inserts number
conversions of the inputs has to be disabled when deoptimization is
enabled, because the frame state layout is no longer known.
R=jarin@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2134173002
Cr-Commit-Position: refs/heads/master@{#37646}
By adding MachineType to LinkageLocation, it is possible not only to reason
about the location of a LinkageLocation on the stack, but also about it's
size. This will be useful in follow-on CLs that attempt to merge some of the
parameter passing logic of tail calls and normal (non-tail) calls.
As a nice side-effect, it is no longer necessary to separately keep a
MachineSignature in a CallDescriptor, because the MachineTypes contianed in
LinkageLocation for all of the Descriptor's parameters and return types are
sufficient. This CL therefore removes the MachineSignature from the
CallDescriptor and adjusts all the calling code accordingly, simplifying and
de-duplicating code in a bunch of places.
R=titzer@chromium.org, bmeurer@chromium.org
LOG=N
Review-Url: https://codereview.chromium.org/2124023003
Cr-Commit-Position: refs/heads/master@{#37633}
Consume Smi/Signed32 feedback for division and modulus and introduce
appropriate checked operators. This is especially important for modulus
where the Float64Mod operator is significantly slower than Int32Mod on
most platforms. For division it's mostly important to propagate
integerness, i.e. to avoid follow-up conversions between float and
int32.
Drive-by-fix: Use Int32Mod for the ModulusStub (and the bytecode handler)
when the inputs are both Smi.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2138633002
Cr-Commit-Position: refs/heads/master@{#37621}
This removes the frame state input representing the before-state from
nodes having the {JSAdd} or the {JSSubtract} operator. Lowering that
inserts number conversions of the inputs has to be disabled when
deoptimization is enabled, because the frame state layout is no longer
known.
R=jarin@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2125593002
Cr-Commit-Position: refs/heads/master@{#37522}
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
Review-Url: https://codereview.chromium.org/2126453002
Cr-Original-Commit-Position: refs/heads/master@{#37512}
Cr-Commit-Position: refs/heads/master@{#37519}
This removes the frame state input representing the before-state from
nodes having the {JSMultiply} operator. Lowering that inserts number
conversions of the inputs has to be disabled when deoptimization is
enabled, because the frame state layout is no longer known.
R=jarin@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2111193002
Cr-Commit-Position: refs/heads/master@{#37517}
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 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}
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}
In the current implementation of wasm an unrepresentable input of the
float32-to-int32 conversion is detected by first truncating the input, then
converting the truncated input to int32 and back to float32, and then checking
whether the result is the same as the truncated input.
This input check does not work on arm and arm64 for an input of (INT32_MAX + 1)
because on these platforms the float32-to-int32 conversion results in INT32_MAX
if the input is greater than INT32_MAX. When INT32_MAX is converted back to
float32, then the result is (INT32_MAX + 1) again because INT32_MAX cannot be
represented precisely as float32, and rounding-to-nearest results in (INT32_MAX
+ 1). Since (INT32_MAX + 1) equals the truncated input value, the input appears
to be representable.
With the changes in this CL, the result of the float32-to-int32 conversion is
incremented by 1 if the original result was INT32_MAX. Thereby the detection of
unrepresenable inputs in wasm works. Note that since INT32_MAX cannot be
represented precisely in float32, it can also never be a valid result of the
float32-to-int32 conversion.
@v8-mips-ports, can you do a similar implementation for mips?
R=titzer@chromium.org, Rodolph.Perfetta@arm.com
Review-Url: https://codereview.chromium.org/2105313002
Cr-Commit-Position: refs/heads/master@{#37448}
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=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg
Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
Review-Url: https://codereview.chromium.org/2090723005
Cr-Original-Commit-Position: refs/heads/master@{#37384}
Cr-Commit-Position: refs/heads/master@{#37416}
Perform the following transformation:
| Before | After |
|------------------+---------------------|
| add w2, w0, w1 | adds w2, w0, w1 |
| cmp w2, #0x0 | b.<cond'> <addr> |
| b.<cond> <addr> | |
|------------------+---------------------|
| add w2, w0, w1 | adds w2, w0, w1 |
| cmp #0x0, w2 | b.<cond'> <addr> |
| b.<cond> <addr> | |
and the same for and instructions instead of add. When the result of the
add/and is not used, generate cmn/tst instead. We need to take care with which
conditions we can handle and what new condition we map them to.
BUG=
Review-Url: https://codereview.chromium.org/2065243005
Cr-Commit-Position: refs/heads/master@{#37400}
Reason for revert:
Looks like this breaks on nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/7626
Original issue's description:
> [builtins] New frame type for exits to C++ builtins
>
> 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=v8:4815
> R=bmeurer@chromium.org, yangguo@chromium.org
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
> Cr-Commit-Position: refs/heads/master@{#37384}
TBR=yangguo@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4815
Review-Url: https://codereview.chromium.org/2106113002
Cr-Commit-Position: refs/heads/master@{#37394}
This functionality is duplicated with the same functionality in
SimplifiedLowering, which is kinda premature and doesn't seem to
be useful.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2103323003
Cr-Commit-Position: refs/heads/master@{#37386}
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=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review-Url: https://codereview.chromium.org/2090723005
Cr-Commit-Position: refs/heads/master@{#37384}
There are no useful typing rules for Change and Checked operators, so we
better make sure we don't run them through the Typer at all.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2107783004
Cr-Commit-Position: refs/heads/master@{#37382}
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=v8:3599,v8:5086,v8:5157
Review-Url: https://codereview.chromium.org/2103733003
Cr-Commit-Position: refs/heads/master@{#37323}
- Adds the concept of FP register aliasing to RegisterConfiguration.
- Changes RegisterAllocator to distinguish between FP representations
when allocating.
- Changes LinearScanAllocator to detect interference when FP register
aliasing is combining, as on ARM.
- Changes ARM code generation to allow all registers s0 - s31 to be
accessed.
- Adds unit tests for RegisterConfiguration, mostly to test aliasing
calculations.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2086653003
Cr-Commit-Position: refs/heads/master@{#37251}
Port fc59eb8a7a
Original commit message:
Moves between operands with different representations shouldn't happen,
so don't test them. This makes it easier to modify canonicalization to
differentiate between floating point types, which is needed to support
floating point register aliasing for ARM and MIPS.
This change also expands tests to include explicit FP moves (both register and stack slot).
LOG=N
BUG=v8:4124
BUG=chromium:622619
Review-Url: https://codereview.chromium.org/2090993002
Cr-Commit-Position: refs/heads/master@{#37241}
We cannot change x - y < 0 to x < y, because it would only be safe if
x - y cannot overflow, which we don't know in general.
R=jarin@chromium.org
BUG=v8:5129
Review-Url: https://codereview.chromium.org/2090493002
Cr-Commit-Position: refs/heads/master@{#37164}
Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
operator based on that, similar to what we do for Float64Cos and Float64Sin.
Rewrite Math.tan() as TurboFan builtin and use those operators to also
inline Math.tan() into optimized TurboFan functions.
Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
the %ConstructDouble runtime entry for writing tests.
BUG=v8:5086,v8:5126
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2083453002
Cr-Commit-Position: refs/heads/master@{#37087}
Import base::ieee754::cos() and base::ieee754::sin() from fdlibm and
introduce Float64Cos and Float64Sin TurboFan operator based on that,
similar to what we do for Float64Log. Rewrite Math.cos() and Math.sin()
as TurboFan builtins and use those operators to also inline Math.cos()
and Math.sin() into optimized TurboFan functions.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
R=mvstanton@chromium.org
BUG=v8:5086,v8:5118
Review-Url: https://codereview.chromium.org/2073123002
Cr-Commit-Position: refs/heads/master@{#37072}
Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.exp() as TurboFan builtin and use that operator to also
inline Math.exp() into optimized TurboFan functions.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108,chromium:620786
R=mvstanton@chromium.org
Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
Review-Url: https://codereview.chromium.org/2077533002
Cr-Original-Commit-Position: refs/heads/master@{#37037}
Cr-Commit-Position: refs/heads/master@{#37047}
