[llvm] [LLVM][CodeGen][SVE] Use unpredicated instructions when there's no strictfp requirement. (PR #88166)

[Paul Walker via llvm-commits]

================
@@ -213,14 +213,31 @@ def AArch64fadd_p_contract : PatFrag<(ops node:$op1, node:$op2, node:$op3),
                                      (AArch64fadd_p node:$op1, node:$op2, node:$op3), [{
   return N->getFlags().hasAllowContract();
 }]>;
+def AArch64fadd_p_nostrictfp : PatFrag<(ops node:$op1, node:$op2, node:$op3),
+                                       (AArch64fadd_p node:$op1, node:$op2, node:$op3), [{
+    // We're allowed to introduce new trapping behaviour.
+    return !MF->getFunction().getAttributes().hasFnAttr(llvm::Attribute::StrictFP);
+}]>;
 def AArch64fadd_p_nsz : PatFrag<(ops node:$op1, node:$op2, node:$op3),
                                 (AArch64fadd_p node:$op1, node:$op2, node:$op3), [{
   return N->getFlags().hasNoSignedZeros();
 }]>;
+
+def AArch64fmul_p_nostrictfp : PatFrag<(ops node:$op1, node:$op2, node:$op3),
+                                       (AArch64fmul_p node:$op1, node:$op2, node:$op3), [{
+    // We're allowed to introduce new trapping behaviour.
+    return !MF->getFunction().getAttributes().hasFnAttr(llvm::Attribute::StrictFP);
----------------
paulwalker-arm wrote:

I figured you might say that but this patch is more about improving the code generation for the non-strictfp case and so this code it just to maintain existing functionality for the -ftrapping-math case rather than to specifically improve support for strictfp.  Do you think this is acceptable rational or should I implement strictfp support properly first?

https://github.com/llvm/llvm-project/pull/88166