mirror of
https://github.com/torvalds/linux.git
synced 2024-11-17 01:22:07 +00:00
28fbf1d540
The e500 SPE floating-point emulation code has several problems in how
it handles conversions to integer and fixed-point fractional types.
There are the following 20 relevant instructions. These can convert
to signed or unsigned 32-bit integers, either rounding towards zero
(as correct for C casts from floating-point to integer) or according
to the current rounding mode, or to signed or unsigned 32-bit
fixed-point values (values in the range [-1, 1) or [0, 1)). For
conversion from double precision there are also instructions to
convert to 64-bit integers, rounding towards zero, although as far as
I know those instructions are completely theoretical (they are only
defined for implementations that support both SPE and classic 64-bit,
and I'm not aware of any such hardware even though the architecture
definition permits that combination).
#define EFSCTUI 0x2d4
#define EFSCTSI 0x2d5
#define EFSCTUF 0x2d6
#define EFSCTSF 0x2d7
#define EFSCTUIZ 0x2d8
#define EFSCTSIZ 0x2da
#define EVFSCTUI 0x294
#define EVFSCTSI 0x295
#define EVFSCTUF 0x296
#define EVFSCTSF 0x297
#define EVFSCTUIZ 0x298
#define EVFSCTSIZ 0x29a
#define EFDCTUIDZ 0x2ea
#define EFDCTSIDZ 0x2eb
#define EFDCTUI 0x2f4
#define EFDCTSI 0x2f5
#define EFDCTUF 0x2f6
#define EFDCTSF 0x2f7
#define EFDCTUIZ 0x2f8
#define EFDCTSIZ 0x2fa
The emulation code, for the instructions that come in variants
rounding either towards zero or according to the current rounding
direction, uses "if (func & 0x4)" as a condition for using _FP_ROUND
(otherwise _FP_ROUND_ZERO is used). The condition is correct, but the
code it controls isn't. Whether _FP_ROUND or _FP_ROUND_ZERO is used
makes no difference, as the effect of those soft-fp macros is to round
an intermediate floating-point result using the low three bits (the
last one sticky) of the working format. As these operations are
dealing with a freshly unpacked floating-point input, those low bits
are zero and no rounding occurs. The emulation code then uses the
FP_TO_INT_* macros for the actual integer conversion, with the effect
of always rounding towards zero; for rounding according to the current
rounding direction, it should be using FP_TO_INT_ROUND_*.
The instructions in question have semantics defined (in the Power ISA
documents) for out-of-range values and NaNs: out-of-range values
saturate and NaNs are converted to zero. The emulation does nothing
to follow those semantics for NaNs (the soft-fp handling is to treat
them as infinities), and messes up the saturation semantics. For
single-precision conversion to integers, (((func & 0x3) != 0) || SB_s)
is the condition used for doing a signed conversion. The first part
is correct, but the second isn't: negative numbers should result in
saturation to 0 when converted to unsigned. Double-precision
conversion to 64-bit integers correctly uses ((func & 0x1) == 0).
Double-precision conversion to 32-bit integers uses (((func & 0x3) !=
0) || DB_s), with correct first part and incorrect second part. And
vector float conversion to integers uses (((func & 0x3) != 0) ||
SB0_s) (and similar for the other vector element), where the sign bit
check is again wrong.
The incorrect handling of negative numbers converted to unsigned was
introduced in commit
|
||
|---|---|---|
| .. | ||
| fabs.c | ||
| fadd.c | ||
| fadds.c | ||
| fcmpo.c | ||
| fcmpu.c | ||
| fctiw.c | ||
| fctiwz.c | ||
| fdiv.c | ||
| fdivs.c | ||
| fmadd.c | ||
| fmadds.c | ||
| fmr.c | ||
| fmsub.c | ||
| fmsubs.c | ||
| fmul.c | ||
| fmuls.c | ||
| fnabs.c | ||
| fneg.c | ||
| fnmadd.c | ||
| fnmadds.c | ||
| fnmsub.c | ||
| fnmsubs.c | ||
| fre.c | ||
| fres.c | ||
| frsp.c | ||
| frsqrte.c | ||
| frsqrtes.c | ||
| fsel.c | ||
| fsqrt.c | ||
| fsqrts.c | ||
| fsub.c | ||
| fsubs.c | ||
| lfd.c | ||
| lfs.c | ||
| Makefile | ||
| math_efp.c | ||
| math.c | ||
| mcrfs.c | ||
| mffs.c | ||
| mtfsb0.c | ||
| mtfsb1.c | ||
| mtfsf.c | ||
| mtfsfi.c | ||
| stfd.c | ||
| stfiwx.c | ||
| stfs.c | ||
| udivmodti4.c | ||