alt Hacker NewsI’m not sure I agree on the impossible part, I feel like a sufficiently smart interprocedural analysis that also implements range analysis interprocedurally could prove a lot to where it becomes useful.
I guess what I would like to see is SIMD libraries being able to confidently say nobody needs to use intrinsics (or differentiate between relaxed/normal SIMD on the user API level) because the language + high level SIMD APIs are smart enough to choose the right implementation.
IIRC IEEE min/max with proper NaN handling needs 8 instructions on x86 vs 1 on arm64 I find it very sad that we apparently haven’t really solved that yet without forcing the user to use different APIs.
Replies
You can do it with just 3 instructions for IEEE 754-2019 minimumNumber (ignores NaN):
vminpd ymm2, ymm1, ymm0
vcmpunordpd ymm0, ymm0, ymm0
vblendvpd ymm0, ymm2, ymm1, ymm0
vminpd ymm1, ymm0, ymm1
vbroadcastsd ymm2, qword ptr [rip + .LCPI0_0]
vandpd ymm2, ymm0, ymm2
vorpd ymm1, ymm2, ymm1
vcmpunordpd ymm2, ymm0, ymm0
vblendvpd ymm0, ymm1, ymm0, ymm2
If you want propagating NaNs but don't care about signed zero or NaN payload/sign, you can use
vminpd ymm2, ymm0, ymm1
vminpd ymm1, ymm1, ymm0
vorpd ymm0, ymm1, ymm2
if (self < other) | self.is_nan() { self } else { other}
vcmpltpd ymm2, ymm0, ymm1
vcmpunordpd ymm3, ymm0, ymm0
vorpd ymm2, ymm3, ymm2
vblendvpd ymm0, ymm1, ymm0, ymm2
Anything without range analysis is not worth it.
Note that:
NonZerof32 * NonZerof32 -> NonNanf32
NonZerof32::from_bits(1) multiplied with itself is zero.
Doing range analysis needs the language to support it at compile time, and the dev to specify what range it is.
The only 'stable' thing i can think of is a type for 'greater-eq-one' using only addition and multiplication. Practically every other operation breaks most of the type knowledge up to that point.