This carries a bitmask indicating forbidden floating-point value kinds

in the argument or return value. This will enable interprocedural

-ffinite-math-only optimizations. This is primarily to cover the

no-nans and no-infinities cases, but also covers the other floating

point classes for free. Textually, this provides a number of names

corresponding to bits in FPClassTest, e.g.

call nofpclass(nan inf) @must_be_finite() call nofpclass(snan) @cannot_be_snan()

This is more expressive than the existing nnan and ninf fast math

flags. As an added bonus, you can represent fun things like nanf:

declare nofpclass(inf zero sub norm) float @only_nans()

Compared to nnan/ninf:

- Can be applied to individual call operands as well as the return value
- Can distinguish signaling and quiet nans
- Distinguishes the sign of infinities
- Can be safely propagated since it doesn't imply anything about other operands.
- Does not apply to FP instructions; it's not a flag

This is one step closer to being able to retire "no-nans-fp-math" and

"no-infs-fp-math". The one remaining situation where we have no way to

represent no-nans/infs is for loads (if we wanted to solve this we

could introduce !nofpclass metadata, following along with

noundef/!noundef).

This is to help simplify the GPU builtin math library

distribution. Currently the library code has explicit finite math only

checks, read from global constants the compiler driver needs to set

based on the compiler flags during linking. We end up having to

internalize the library into each translation unit in case different

linked modules have different math flags. By propagating known-not-nan

and known-not-infinity information, we can automatically prune the

edge case handling in most functions if the function is only reached

from fast math uses.