[IR] Remove the possibility of ConstantExpr having fast-math flags.

[jcranmer-intel]

This possibility was added in https://reviews.llvm.org/D34303 to resolve some assertion failures with cases where FP math operations got constant-folded in constant expressions. However, at no point did the IR representation allow for expressing fast-math flags on constant expressions.

With the change of #93038, there are no longer any constant expressions capable of being FP math operators, and thus FPMathOperator can go back to being Instruction-only.

[llvmbot]

@llvm/pr-subscribers-llvm-ir

Author: Joshua Cranmer (jcranmer-intel)

Changes

This possibility was added in https://reviews.llvm.org/D34303 to resolve some assertion failures with cases where FP math operations got constant-folded in constant expressions. With the change of #93038, however, there are no longer any constant expressions capable of being FP math operators, and thus FPMathOperator can go back to being Instruction-only.

---

Full diff: https://github.com/llvm/llvm-project/pull/94507.diff

1 Files Affected:

• (modified) llvm/include/llvm/IR/Operator.h (-2)

diff --git a/llvm/include/llvm/IR/Operator.h b/llvm/include/llvm/IR/Operator.h
index fda26891acfa7..f63f54ef94107 100644
--- a/llvm/include/llvm/IR/Operator.h
+++ b/llvm/include/llvm/IR/Operator.h
@@ -330,8 +330,6 @@ class FPMathOperator : public Operator {
     unsigned Opcode;
     if (auto *I = dyn_cast<Instruction>(V))
       Opcode = I->getOpcode();
-    else if (auto *CE = dyn_cast<ConstantExpr>(V))
-      Opcode = CE->getOpcode();
     else
       return false;
 

[efriedma-quic]

LGTM

[nikic]

It would be good to also make the class inherit from Instruction instead of Operator (in this context, "Operator" means "Instruction or ConstantExpr").

[jcranmer-intel]

It would be good to also make the class inherit from Instruction instead of Operator (in this context, "Operator" means "Instruction or ConstantExpr").

I've considered that as well. FPMathOperator was originally an Operator when it was first implemented and Instruction-only, so I've reverted it back to that form for now. I've been poking around having FMF be present on Instruction in lieu of SubclassOptionalData, at which case the inheritance from Instruction is far more helpful. If that is the route taken to add more FMF bits, then I'll do it as part of that change.