Support f16 and f128

[tgross35]

Thanks for filing a feature request! Please fill out the TODOs below.

Feature

Add support for 16-bit and 128-bit IEEE floating point numbers.

Benefit

This will allow using these types with rustc_codegen_clif, as described at rust-lang/rustc_codegen_cranelift#1461

Implementation

Unsure

Alternatives

Unsure, maybe it would be possible to stub out these types if adding them is difficult.

[jameysharp]

Adding the types is pretty easy, I think, and extending CLIF floating-point instructions to allow the new types is also pretty easy. Successfully compiling anything that uses the types is the hard part, I imagine.

I think the places to add the types are:

• wasmtime/cranelift/codegen/meta/src/cdsl/typevar.rs

  Line 646 in e6f9ca5

  range_to_set(self.floats.to_range(32..64, None)),

• wasmtime/cranelift/codegen/meta/src/shared/types.rs

  Lines 44 to 73 in e6f9ca5

  	#[derive(Debug, Clone, Copy, Eq, PartialEq, Hash)]
  	pub(crate) enum Float {
  	F32 = 32,
  	F64 = 64,
  	}
  	/// Iterator through the variants of the Float enum.
  	pub(crate) struct FloatIterator {
  	index: u8,
  	}
  	impl FloatIterator {
  	pub fn new() -> Self {
  	Self { index: 0 }
  	}
  	}
  	/// This provides an iterator through all of the supported float variants.
  	impl Iterator for FloatIterator {
  	type Item = Float;
  	fn next(&mut self) -> Option<Self::Item> {
  	let res = match self.index {
  	0 => Some(Float::F32),
  	1 => Some(Float::F64),
  	_ => return None,
  	};
  	self.index += 1;
  	res
  	}
  	}

• various places in https://github.com/bytecodealliance/wasmtime/blob/e6f9ca5efa0c4bf59c9cf133d9abeaab63ec07bb/cranelift/codegen/src/ir/types.rs

Once the tests are passing again after that, I think you'll have a compiler that will accept f16/f128 instructions. But if you use them, then it will fail later: during lowering on all backends; in the interpreter; in compiletests and runtests; and in fuzzing.

I think this is a fairly large project, but if rustc needs these types, I think it's reasonable to add the types in one PR and then work on adding implementations for them everywhere over time.