aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/gc/float_test.go
AgeCommit message (Collapse)Author
2020-12-23[dev.regabi] cmd/compile: split out package test [generated]Russ Cox
[git-generate] cd src/cmd/compile/internal/gc rf ' mv bench_test.go constFold_test.go dep_test.go \ fixedbugs_test.go iface_test.go float_test.go global_test.go \ inl_test.go lang_test.go logic_test.go \ reproduciblebuilds_test.go shift_test.go ssa_test.go \ truncconst_test.go zerorange_test.go \ cmd/compile/internal/test ' mv testdata ../test Change-Id: I041971b7e9766673f7a331679bfe1c8110dcda66 Reviewed-on: https://go-review.googlesource.com/c/go/+/279480 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2020-10-02all: drop 387 supportKeith Randall
My last 387 CL. So sad ... ... ... ... not! Fixes #40255 Change-Id: I8d4ddb744b234b8adc735db2f7c3c7b6d8bbdfa4 Reviewed-on: https://go-review.googlesource.com/c/go/+/258957 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-03-04cmd/compile: don't allow NaNs in floating-point constant opsKeith Randall
Trying this CL again, with a fixed test that allows platforms to disagree on the exact behavior of converting NaNs. We store 32-bit floating point constants in a 64-bit field, by converting that 32-bit float to 64-bit float to store it, and convert it back to use it. That works for *almost* all floating-point constants. The exception is signaling NaNs. The round trip described above means we can't represent a 32-bit signaling NaN, because conversions strip the signaling bit. To fix this issue, just forbid NaNs as floating-point constants in SSA form. This shouldn't affect any real-world code, as people seldom constant-propagate NaNs (except in test code). Additionally, NaNs are somewhat underspecified (which of the many NaNs do you get when dividing 0/0?), so when cross-compiling there's a danger of using the compiler machine's NaN regime for some math, and the target machine's NaN regime for other math. Better to use the target machine's NaN regime always. Update #36400 Change-Id: Idf203b688a15abceabbd66ba290d4e9f63619ecb Reviewed-on: https://go-review.googlesource.com/c/go/+/221790 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2020-02-25Revert "cmd/compile: don't allow NaNs in floating-point constant ops"Bryan C. Mills
This reverts CL 213477. Reason for revert: tests are failing on linux-mips*-rtrk builders. Change-Id: I8168f7450890233f1bd7e53930b73693c26d4dc0 Reviewed-on: https://go-review.googlesource.com/c/go/+/220897 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-02-25cmd/compile: don't allow NaNs in floating-point constant opsKeith Randall
We store 32-bit floating point constants in a 64-bit field, by converting that 32-bit float to 64-bit float to store it, and convert it back to use it. That works for *almost* all floating-point constants. The exception is signaling NaNs. The round trip described above means we can't represent a 32-bit signaling NaN, because conversions strip the signaling bit. To fix this issue, just forbid NaNs as floating-point constants in SSA form. This shouldn't affect any real-world code, as people seldom constant-propagate NaNs (except in test code). Additionally, NaNs are somewhat underspecified (which of the many NaNs do you get when dividing 0/0?), so when cross-compiling there's a danger of using the compiler machine's NaN regime for some math, and the target machine's NaN regime for other math. Better to use the target machine's NaN regime always. This has been a bug since 1.10, and there's an easy workaround (declare a global varaible containing the signaling NaN pattern, and use that as the argument to math.Float32frombits) so we'll fix it in 1.15. Fixes #36400 Update #36399 Change-Id: Icf155e743281560eda2eed953d19a829552ccfda Reviewed-on: https://go-review.googlesource.com/c/go/+/213477 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2018-09-14cmd/compile: skip float32 constant folding test on 387 builderMichael Munday
The 387 unit always quietens float64 and float32 signaling NaNs, even when just loading and storing them. This makes it difficult to propagate such values in the compiler. This is a hard problem to fix and it is also very obscure. Updates #27516. Change-Id: I03d88e31f14c86fa682fcea4b6d1fba18968aee8 Reviewed-on: https://go-review.googlesource.com/135195 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-09-05cmd/compile: fix store-to-load forwarding of 32-bit sNaNsMichael Munday
Signalling NaNs were being converted to quiet NaNs during constant propagation through integer <-> float store-to-load forwarding. This occurs because we store float32 constants as float64 values and CPU hardware 'quietens' NaNs during conversion between the two. Eventually we want to move to using float32 values to store float32 constants, however this will be a big change since both the compiler and the assembler expect float64 values. So for now this is a small change that will fix the immediate issue. Fixes #27193. Change-Id: Iac54bd8c13abe26f9396712bc71f9b396f842724 Reviewed-on: https://go-review.googlesource.com/132956 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2017-09-16cmd/compile: test constant folded integer to/from float conversionsMichael Munday
Improves test coverage of the rules added in CL 63795 and would have detected the bug fixed by CL 63950. Change-Id: I107ee8d8e0b6684ce85b2446bd5018c5a03d608a Reviewed-on: https://go-review.googlesource.com/64130 Reviewed-by: Keith Randall <khr@golang.org>
2017-09-15cmd/compile: fix typo in floating point ruleTodd Neal
Change-Id: Idfb64fcb26f48d5b70bab872f9a3d96a036be681 Reviewed-on: https://go-review.googlesource.com/63950 Run-TryBot: Todd Neal <todd@tneal.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2017-09-14cmd/compile: improve floating point constant propagationMichael Munday
Add generic rules to propagate floating point constants through comparisons and integer conversions. These new rules seldom trigger in the standard library so there is no performance change, however I think it is worth adding them anyway for completeness. Change-Id: I9db5222746508a2996f1cafb72f4e0cf2541de07 Reviewed-on: https://go-review.googlesource.com/63795 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2017-04-03cmd/compile: strength-reduce floating pointKeith Randall
x*2 -> x+x x/c, c power of 2 -> x*(1/c) Fixes #19827 Change-Id: I74c9f0b5b49b2ed26c0990314c7d1d5f9631b6f1 Reviewed-on: https://go-review.googlesource.com/39295 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-08-16cmd/compile: fix uint<->float conversion on 386Cherry Zhang
The frontend rewriting lowers them to runtime calls on 386. It matches explicitly uint32, but missed uint. Fixes #16738. Change-Id: Iece7a45edf74615baca052a53273c208f057636d Reviewed-on: https://go-review.googlesource.com/27085 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-01-13cmd/compile: stop using fucomi* ops for 387 buildsKeith Randall
The fucomi* opcodes were only introduced for the Pentium Pro. They do not exist for an MMX Pentium. Use the fucom* instructions instead and move the condition codes from the fp flags register to the integer flags register explicitly. The use of fucomi* opcodes in ggen.go was introduced in 1.5 (CL 8738). The bad ops were generated for 64-bit floating-point comparisons. The use of fucomi* opcodes in gsubr.go dates back to at least 1.1. The bad ops were generated for float{32,64} to uint64 conversions. Fixes #13923 Change-Id: I5290599f5edea8abf8fb18036f44fa78bd1fc9e6 Reviewed-on: https://go-review.googlesource.com/18590 Reviewed-by: Minux Ma <minux@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 09:32:38 +0000