This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.
Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.
Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.
BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
This is a reland of 6f93d59d92.
One more test had to be disabled (tracked by bug 6954), and
two machops tests needed to be changed to use boxed floats
and doubles.
Original change's description:
> [test] Add nan bit patterns to uint{32,64}_vector
>
> If you just cast those patterns to float or double and pass them
> around, the quiet/signaling NaN bit might change. We had several bugs
> around this, so add these patterns to the general input vectors.
>
> This uncovers a bug in the wasm interpreter, which will be fixed in a
> separate CL.
>
> R=ahaas@chromium.org
>
> Bug: v8:6947, v8:6954
> Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0
> Reviewed-on: https://chromium-review.googlesource.com/725345
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48731}
Bug: v8:6947, v8:6954
Change-Id: I9a38b5d9324131c3950c537910371a73c93d2c13
Reviewed-on: https://chromium-review.googlesource.com/728439
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48780}
This reverts commit 6f93d59d92.
Reason for revert: Breaks full-debug build:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20full%20debug/builds/2239
Original change's description:
> [test] Add nan bit patterns to uint{32,64}_vector
>
> If you just cast those patterns to float or double and pass them
> around, the quiet/signaling NaN bit might change. We had several bugs
> around this, so add these patterns to the general input vectors.
>
> This oncovers a bug in the wasm interpreter, which will be fixed in a
> separate CL.
>
> R=ahaas@chromium.org
>
> Bug: v8:6947, v8:6954
> Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0
> Reviewed-on: https://chromium-review.googlesource.com/725345
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48731}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: I4ceb82eab5d4cbf1f335bf6f358178a17a2fd0ba
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6947, v8:6954
Reviewed-on: https://chromium-review.googlesource.com/728101
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48745}
If you just cast those patterns to float or double and pass them
around, the quiet/signaling NaN bit might change. We had several bugs
around this, so add these patterns to the general input vectors.
This oncovers a bug in the wasm interpreter, which will be fixed in a
separate CL.
R=ahaas@chromium.org
Bug: v8:6947, v8:6954
Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0
Reviewed-on: https://chromium-review.googlesource.com/725345
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48731}
This is a reland of e737b4ce0d.
The issue on windows bots was fixed in https://crrev.com/c/725733.
Original change's description:
> [test] Avoid unnecessary std::vector allocations
>
> Instead of copying an array of fixed values into an std::vector for
> each usage of the FOR_INPUTS macro, just iterate the constant data
> directly.
> This also makes the <type>_vector() functions return {constexpr Vector}
> instead of {std::vector}.
>
> R=tebbi@chromium.org
>
> Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4
> Reviewed-on: https://chromium-review.googlesource.com/725427
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48688}
Change-Id: I9ad5d22803bbbf35c458965497acc603cfa01b20
Reviewed-on: https://chromium-review.googlesource.com/725979
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48726}
This reverts commit e737b4ce0d.
Reason for revert: On windows, V8_INFINITY is not constexpr
Original change's description:
> [test] Avoid unnecessary std::vector allocations
>
> Instead of copying an array of fixed values into an std::vector for
> each usage of the FOR_INPUTS macro, just iterate the constant data
> directly.
> This also makes the <type>_vector() functions return {constexpr Vector}
> instead of {std::vector}.
>
> R=tebbi@chromium.org
>
> Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4
> Reviewed-on: https://chromium-review.googlesource.com/725427
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48688}
TBR=clemensh@chromium.org,tebbi@chromium.org
Change-Id: Iccb52941d4efe71b49b41572c3d922a5d78bdfd2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/725899
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48691}
Instead of copying an array of fixed values into an std::vector for
each usage of the FOR_INPUTS macro, just iterate the constant data
directly.
This also makes the <type>_vector() functions return {constexpr Vector}
instead of {std::vector}.
R=tebbi@chromium.org
Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4
Reviewed-on: https://chromium-review.googlesource.com/725427
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48688}
This required splitting wasm-run-utils.h in header and implementation,
since the anonymous namespace in wasm-run-utils.h is now gone.
This is a reasonable refactoring in itself.
R=titzer@chromium.orgCC=mstarzinger@chromium.org, mostynb@opera.com
Bug: chromium:746958
Change-Id: I0f3b30fef1865cd88eca37b69d0c3a9eb19e77ea
Reviewed-on: https://chromium-review.googlesource.com/647587
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47773}
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}
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}
Import base::ieee754::atan() and base::ieee754::atan2() from fdlibm and
introduce Float64Atan and Float64Atan2 TurboFan operators based on those,
similar to what we already did for Float64Log and Float64Log1p. Rewrite
Math.atan() and Math.atan2() as TurboFan builtin and use the operators
to also inline Math.atan() and Math.atan2() into optimized TurboFan functions.
R=yangguo@chromium.org
BUG=v8:5086,v8:5095
Review-Url: https://codereview.chromium.org/2065503002
Cr-Commit-Position: refs/heads/master@{#36916}
Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.log1p() as TurboFan builtin and use that operator to also
inline Math.log1p() into optimized TurboFan functions.
Also unify the handling of the special IEEE 754 functions somewhat in
the TurboFan backends. At some point we can hopefully express this
completely in the InstructionSelector (once we have an idea what to do
with the ST(0) return issue on IA-32/X87).
Drive-by-fix: Add some more test coverage for the log function.
R=yangguo@chromium.org
BUG=v8:5086,v8:5092
Review-Url: https://codereview.chromium.org/2060743002
Cr-Commit-Position: refs/heads/master@{#36914}
This switches Math.log to use an fdlibm based version of log, imported
as base::ieee754::log, and use that consistently everywhere, i.e. change
the Float64Log TurboFan operators on Intel to use the C++ implementation
as well (same for Crankshaft).
R=yangguo@chromium.org
BUG=v8:5065,v8:5086
Review-Url: https://codereview.chromium.org/2053893003
Cr-Commit-Position: refs/heads/master@{#36880}
Instead of using CheckFloatEq and CheckDoubleEq directly, I introduced
a macro which first stores the expected result in a volatile variable.
Here are some comments of previous CLs:
The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/.
Here is the key comments from CL #31808
Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function,
those inlined functions has different behavior comparing with GCC ia32 build and x87 build.
The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value.
The V8 turbofan JITTed has exactly same result in both X87 and IA32 port.
So we add the following sentence to do type cast to keep the same precision for RunCallInt64ToFloat32/RunCallInt64ToFloat64. Such as: volatile double expect = static_cast<float>(*i).
R=titzer@chromium.org, weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/1773513002
Cr-Commit-Position: refs/heads/master@{#34534}
The BufferedRawMachineAssemblerTester caused problems for the
Int64Lowering. Instead we construct a TF graph now which is compiled by
Pipeline::GenerateCodeForTesting.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1702023002
Cr-Commit-Position: refs/heads/master@{#34107}
Reason for revert:
Code is incorrect for -0.
Original issue's description:
> [turbofan] Implement rounding of floats on x64 and ia32 without sse4.1.
>
> The implementation sets the rounding mode flag and then uses the
> cvtsd2si and cvtsi2sd instructions (convert between float and int) to do
> the rounding. Input values outside int range either don't have to be
> rounded anyways, or are rounded by calculating input + 2^52 - 2^52 for
> positive inputs, or input -2^52 + 2^52 for negative inputs. The original
> rounding mode is restored afterwards.
>
> R=titzer@chromium.org
>
> B=575379
>
> Committed: https://crrev.com/fa5d09e547abe79a8c82f780deb980c53ad78beb
> Cr-Commit-Position: refs/heads/master@{#33367}
TBR=titzer@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/1593313010
Cr-Commit-Position: refs/heads/master@{#33369}
The implementation sets the rounding mode flag and then uses the
cvtsd2si and cvtsi2sd instructions (convert between float and int) to do
the rounding. Input values outside int range either don't have to be
rounded anyways, or are rounded by calculating input + 2^52 - 2^52 for
positive inputs, or input -2^52 + 2^52 for negative inputs. The original
rounding mode is restored afterwards.
R=titzer@chromium.org
B=575379
Review URL: https://codereview.chromium.org/1584663007
Cr-Commit-Position: refs/heads/master@{#33367}
TryTruncateFloat32ToUint64 converts a float32 to a uint64. Additionally it
provides an optional second return value which indicates whether the conversion
succeeded (i.e. float32 value was within uint64 range) or not.
I implemented the new operator on x64, arm64, and mips64. @v8-ppc-ports, can you
please take care of the ppc64 implementation of the second output?
Additionally I fixed a bug on x64 and mips64 in the implementation of
TryTruncateFloat64ToUint64. Cases where the input value was between -1 and 0
were handled incorrectly.
R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1512023002
Cr-Commit-Position: refs/heads/master@{#32796}
This operator now provides a second output which indicates whether the conversion from float64 to uint64 was successful or not. The second output returns 0 if the conversion fails, or something else if the conversion succeeds.
The second output can be ignored, which means that the operator can be used the same as the original operator.
I implement the new operator on x64 and arm64. @v8-mips-ports and @v8-ppc-ports, can you please take care of the mips64 and ppc64 implementation of the second output?
R=titzer@chromium.org, v8-arm-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1507703002
Cr-Commit-Position: refs/heads/master@{#32705}
The least significant bit of the input value may affect the result of
the conversion through rounding. We OR the least significant with the
second least significant bit to preserve it over the SHR instruction.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1435203003
Cr-Commit-Position: refs/heads/master@{#31969}
The usage of Unique<T> throughout the TurboFan IR does not have any
advantage. There is no single point in time when they are initialized
and most use-sites looked through to the underlying Handle<T> anyways.
Also there already was a mixture of Handle<T> versus Unique<T> in the
graph and this unifies the situation to use Handle<T> everywhere.
R=bmeurer@chromium.org,titzer@chromium.org
Review URL: https://codereview.chromium.org/1314473007
Cr-Commit-Position: refs/heads/master@{#30458}
These operators compute the absolute floating point value of some
arbitrary input, and are implemented without any branches (i.e. using
vabs on arm, and andps/andpd on x86).
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1066393002
Cr-Commit-Position: refs/heads/master@{#27662}
Use std::numeric_limits<double>::quiet_NaN() and
std::numeric_limits<float>::quiet_NaN() instead.
Review URL: https://codereview.chromium.org/864803002
Cr-Commit-Position: refs/heads/master@{#26195}
