================
@@ -2941,18 +2941,22 @@ def CIR_RemOp : CIR_BinaryOp<"rem",
CIR_AnyIntOrVecOfIntType> {
// and result must all be the same floating-point scalar or vector type.
//
// The optional `fenv` attribute describes constraints on the floating-point
-// handling of the operation.
+// handling of the operation. The optional `fastmath_flags` attribute holds the
+// fast-math flags of the operation.
class CIR_FPBinaryOp<string mnemonic, list<Trait> traits = []>
: CIR_BinaryOp<mnemonic, CIR_AnyFloatOrVecOfFloatType,
!listconcat(CIR_FenvOpTraits, traits),
CIR_DynamicMemoryEffects> {
- let arguments = !con(commonArgs, (ins OptionalAttr<CIR_FenvAttr>:$fenv));
+ let arguments = !con(commonArgs, (ins
----------------
xakep8 wrote:
The builder now records the active fast-math state, but only CIR_FPBinaryOp
consumes it. Classic CodeGen also attaches contract to FP intrinsic calls,
unary operations, comparisons, and conversions. For example, 1.0f /
__builtin_sqrtf(x) marks both llvm.sqrt and fdiv as contractable, and AMDGPU
requires both flags for its rsqrt contraction. CIR currently cannot represent
the flag on cir.sqrt. Should we extend fastmath_flags to the shared FP
operation bases, or explicitly leave this as a documented follow-up?
https://github.com/llvm/llvm-project/pull/226334
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
