Floating-point literals should store bits in integers, not use host f32/f64.

[eddyb]

Compilers should never rely on host floating-point support, as that can lead to host-specific behavioral subtleties (instead of behavior being deterministically tied to the target architecture/platform), and in many cases there's not enough to gain to even look into what guarantees certain host architectures/platforms may offer.

For rustc we ported LLVM's C++ APFloat library to Rust (for e.g. evaluating float operations in constant expressions), but rspirv itself only needs to store literals, not operate on the actual values (and consumers could choose how to interpret the bits of a floating-point value, any way they want).

I'm not sure how what the timeline for 0.8 is, but this would be a breaking change.

Also, it would help with #16.

cc @khyperia

[Jasper-Bekkers]

@eddyb do you have any examples of where this is done wrong? Is it just the constant_f32 functions and LiteralFloat32 etc?

[eddyb]

Right, and loading code like this:

rspirv/rspirv/binary/decoder.rs

Lines 205 to 219 in 719cf08

	/// Decodes and returns the next SPIR-V word as a 32-bit
	/// literal floating point number.
	pub fn float32(&mut self) -> Result<f32> {
	let val = self.word()?;
	Ok(f32::from_bits(val))
	}
	/// Decodes and returns the next two SPIR-V words as a 64-bit
	/// literal floating point number.
	pub fn float64(&mut self) -> Result<f64> {
	let low = u64::from(self.word()?);
	let high = u64::from(self.word()?);
	let val = (high << 32) | low;
	Ok(f64::from_bits(val))
	}

Basically the types f32 and f64 should more or less not show up in rspirv (except maybe for fmt::Debug?).