<html><body><p><tt><font size="2">Craig Topper wrote:</font></tt><br><br><tt><font size="2">>I was thinking about a few less common floating point things and wondered<br>>if we need constrained/strict versions of them.<br>><br>>-int_fmuladd - which is used by clang to support fp-contract=on where only<br>>operations within a statement sare allowed to be concentrated.<br></font></tt><br><tt><font size="2">Probably yes.</font></tt><br><tt><font size="2"><br>>-int_convert_to_fp16/int_convert_from_fp16 - Used by some targets to<br>>support ieee 16-bit floats as a storage only type I think. A FIXME in clang<br>>indicates the plan was to get rid of these all together, but I'm not sure<br>>where we are on that.<br>>-Not an intrinsic, but we also have ISD::FP16_TO_FP and ISD::FP_TO_FP16 in<br>>SelectionDAG. I believe these are created during type legalization if half<br>>needs to be promoted.</font></tt><br><br><tt><font size="2">I haven't really looked at the whole FP16 story yet, since we're not</font></tt><br><tt><font size="2">currently supporting any such data type on the platform ...</font></tt><br><br><br><tt><font size="2">I'm also seeing the following additional intrinsics:</font></tt><br><br><tt><font size="2">- int_canonicalize</font></tt><br><tt><font size="2">I believe we need a strict version of this as well.</font></tt><br><br><tt><font size="2">- int_maximum/int_minimum</font></tt><br><tt><font size="2">This is currently only generated by clang to implement some WebAssembly</font></tt><br><tt><font size="2">builtins, but adding strict support to parallel maxnum/minnum should</font></tt><br><tt><font size="2">be straightforward.</font></tt><br><tt><font size="2"><br>As well as the following DAG nodes:</font></tt><br><br><tt><font size="2">- SINT_TO_FP/UINT_TO_FP (Kevin has a patch in progress)</font></tt><br><tt><font size="2">- FCANONICALIZE (goes with int_canonicalize)</font></tt><br><tt><font size="2">- FMAXIMUM/FMINIMUM (go with int_maximum/int_minimum)</font></tt><br><tt><font size="2">- FMAXNUM_IEEE/FMINNUM_IEEE</font></tt><br><tt><font size="2"> only used internally, might be needed by some targets</font></tt><br><tt><font size="2">- FMAD/FCBRT/FSINCOS</font></tt><br><tt><font size="2"> only used internally / for optimization, so we'll only need</font></tt><br><tt><font size="2"> them once we start implementing optimizations for strict ops</font></tt><br><tt><font size="2">- ATOMIC_LOAD_FADD/ATOMIC_LOAD_FSUB</font></tt><br><tt><font size="2"> already has a chain / treated as volatile memory access,</font></tt><br><tt><font size="2"> so we might not actually need strict versions</font></tt><br><br><tt><font size="2">In addition, there are the experimental vector reduce intrinsics</font></tt><br><tt><font size="2">and associated ISD nodes; we'll have to think about how those</font></tt><br><tt><font size="2">interact with strict FP exceptions as well at some point.</font></tt><br><br><tt><font size="2"><br>Bye,</font></tt><br><tt><font size="2">Ulrich</font></tt><br><BR>
</body></html>