Hacker News new | ask | show | jobs
by kibwen 451 days ago
I'm not personally familiar with the implementation, but Rust's const fn is evaluated using an interpreter called MIRI with its own softfloat implementation, and therefore isn't limited by the precision of the host platform. The act of cross-compilation shouldn't pose a problem, and would be a soundness issue in the compiler if it did.
1 comments
throwawaymaths 451 days ago
no the soundness of the compiler is at risk because the target has limitations, not the host.
link
kibwen 451 days ago
As long as the target is compliant with IEEE 754, which is what Rust expects, it shouldn't be an issue. The only platform that I know of that causes problems is extremely old pre-SSE 32-bit x86, where floats sometimes have 80-bit precision and which can't be worked around because of LLVM limitations which nobody's going to fix because the target is so obscure. Rust will probably just end up deprecating that target and replacing it with a softfloat equivalent.
link
throwawaymaths 450 days ago
there are multiple IEE-754 fps. 32, 64, and 80 in use.

so your claim is that rust compiler knows in advance which will be used by the target and adjusts its softfloat accordingly?

I'm not convinced. IIRC there are cases for SIMD where there is only a 2 ULP guarantee and some tryhard silicon gives you 1 ULP for the same opcode.

link
kibwen 450 days ago
> so your claim is that rust compiler knows in advance which will be used by the target and adjusts its softfloat accordingly?

Rust performs FP operations using the precision of the underlying type. For compile time evaluation this is enforced by Miri, and for runtime evaluation this is enforced by carefully emitting the appropriate LLVM IR.

> IIRC there are cases for SIMD where there is only a 2 ULP guarantee and some tryhard silicon gives you 1 ULP for the same opcode.

Rust only permits operations in constant contexts when it's confident that it can make useful guarantees about their behavior. In particular, FP ops in const contexts are currently limited as follows:

"This RFC specifies the behavior of +, - (unary and binary), *, /, %, abs, copysign, mul_add, sqrt, as-casts that involve floating-point types, and all comparison operations on floating-point types."

https://github.com/rust-lang/rfcs/blob/master/text/3514-floa...

link