Support `f16` and `f128`

[Trevor Gross]

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.

[Jamey Sharp]

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.