llvm dev - Dec 2019 - [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191211/adeb2300/attachment.html>

On Wed, Dec 11, 2019 at 2:51 PM Ulrich Weigand via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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.
>
> >- 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev