[FPEnv] Do we need constrained/strict versions of theseintrinsics?

Craig Topper wrote:

>I was thinking about a few less common floating point things and wondered
>if we need constrained/strict versions of them.
>-int_fmuladd - which is used by clang to support fp-contract=on where only
>operations within a statement sare allowed to be concentrated.

Probably yes.

>-int_convert_to_fp16/int_convert_from_fp16 - Used by some targets to
>support ieee 16-bit floats as a storage only type I think. A FIXME in clang
>indicates the plan was to get rid of these all together, but I'm not sure
>where we are on that.
>-Not an intrinsic, but we also have ISD::FP16_TO_FP and ISD::FP_TO_FP16 in
>SelectionDAG. I believe these are created during type legalization if half
>needs to be promoted.

I haven't really looked at the whole FP16 story yet, since we're not
currently supporting any such data type on the platform ...

I'm also seeing the following additional intrinsics:

- int_canonicalize
I believe we need a strict version of this as well.

- int_maximum/int_minimum
This is currently only generated by clang to implement some WebAssembly
builtins, but adding strict support to parallel maxnum/minnum should
be straightforward.

As well as the following DAG nodes:

- SINT_TO_FP/UINT_TO_FP (Kevin has a patch in progress)
- FCANONICALIZE (goes with int_canonicalize)
- FMAXIMUM/FMINIMUM (go with int_maximum/int_minimum)
only used internally, might be needed by some targets
only used internally / for optimization, so we'll only need
them once we start implementing optimizations for strict ops
already has a chain / treated as volatile memory access,
so we might not actually need strict versions

In addition, there are the experimental vector reduce intrinsics
and associated ISD nodes; we'll have to think about how those
interact with strict FP exceptions as well at some point.