[llvm-dev] [FPEnv] Do we need constrained/strict versions of theseintrinsics?
Ulrich Weigand via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 10 04:59:27 PST 2019
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.
>-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
>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:
I believe we need a strict version of this as well.
This is currently only generated by clang to implement some WebAssembly
builtins, but adding strict support to parallel maxnum/minnum should
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev