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

[Ulrich Weigand via llvm-dev]

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)
- FMAXNUM_IEEE/FMINNUM_IEEE
  only used internally, might be needed by some targets
- FMAD/FCBRT/FSINCOS
  only used internally / for optimization, so we'll only need
  them once we start implementing optimizations for strict ops
- ATOMIC_LOAD_FADD/ATOMIC_LOAD_FSUB
  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.


Bye,
Ulrich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191210/8be9aabf/attachment.html>