Float.floatToRawIntBits is currently not super well tested in fuzzers, because it behaves somewhat unpredictably because of multiple NaN encodings. But there might be some ways to still test it and verify results, though it is a bit tricky.

It is important to test it together with other operations such as casts, see JDK-8366845.

We might be able to do some of this with JDK-8359412, where we can add these instructions in arbitrary expressions. There, it might be difficult to verify results, because of different NaN encodings. But we would at least have caught the asserting cases from JDK-8366845.

One thing that surely is important:
Unaligned float MemorySegment loads/stores use MoveI2F / MoveF2I, and so we should also do more testing using that. That is indeed how we found JDK-8366845 in the first place, with the MemorySegment test from JDK-8324751.

We should cover: I2F, F2I, L2D, D2L, HF2S, S2HF

Some ideas:
1. Fill array/MemorySegment with floats/doubles. Then do LoadI/L, with Move[I/L]2[F/D]. Now, we have it guaranteed that the value is as it was in the array/MemorySegment, and we can expect it to behave as if it was a LoadF/D, with exact float results.
2. We could just generate arbitrary expressions with JDK-8359412, but not do any result verification if there any instructions that could behave unpredictably with multiple NaN encodings. At least we could hit asserts that way.
3. We could do some more advanced value tracking across the expression, and track if a int/float bit pattern could have multiple NaN values. That probably happens quite quickly and so at that point we cannot do result verification. But there may still be some cases where we would be able to do result verification.