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

Following up on myself after some further investigation:

>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.

OTOH this is also solely an optimization, so for now we could
simply have clang not generate those when in strict mode.

>I'm also seeing the following additional intrinsics:
>
>- int_canonicalize
>I believe we need a strict version of this as well.

It seems like this is currently only supported on AMDGPU
and will simply trigger an internal error everywhere else.
(I thought there was a default expansion to a multiply
with 1.0 or something, but apparently not ...)

Given that, I don't think we need a strict version
either (at least not straight away).

>- 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.

I have a patch for those, which I'll post after ``D71218 ``is in.

Bye,
Ulrich

Following up on myself after some further investigation:

>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.

OTOH this is also solely an optimization, so for now we could
simply have clang not generate those when in strict mode.

>I'm also seeing the following additional intrinsics:
>
>- int_canonicalize
>I believe we need a strict version of this as well.

It seems like this is currently only supported on AMDGPU
and will simply trigger an internal error everywhere else.
(I thought there was a default expansion to a multiply
with 1.0 or something, but apparently not ...)

Given that, I don't think we need a strict version
either (at least not straight away).

We'll definitely want a strict version of this on AMDGPU, because
Vulkan now allows you to set different denorm-flushing modes, and to
implement it we'll sometimes need to change the setting in the middle
of a function.