[MLIR][Arith] Add denormal attribute to binary/unary operations

[chelini]

Add support for denormal in the Arith dialect (binary and unary operations).
Denormal are attached to every operation, and they can be of three different
kinds:

1. ieee, denormal are preserved and processed as defined by IEEE 754 rules.

2. preserve sign, a mode where denormal numbers are flushed to zero, but the
   sign of the zero (+0 or -0) is preserved.

3. positive zero, a mode where all denormal numbers are flushed to positive zero
   (+0), ignoring the sign of the original number.

Denormal refers to both the operands and the result. Currently only lowering for
ieee is supported.

[llvmbot]

@llvm/pr-subscribers-mlir-linalg
@llvm/pr-subscribers-mlir-core
@llvm/pr-subscribers-mlir-arith
@llvm/pr-subscribers-mlir

@llvm/pr-subscribers-mlir-math

Author: lorenzo chelini (chelini)

Changes

The Flush to Zero (FTZ) modifier is used in floating-point arithmetic to set  very small numbers, known as denormal or subnormal numbers, to zero. FTZ is done to improve performance, as handling these small numbers can slow down computations. Note that this attribute does not specify if the rounding happens toward positive or negative zero since it is architecture (or vendor)-dependent.

---

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

3 Files Affected:

• (modified) mlir/include/mlir/Dialect/Arith/IR/ArithBase.td (+4-2)
• (modified) mlir/test/Dialect/Arith/ops.mlir (+15-1)
• (modified) mlir/test/Dialect/Math/ops.mlir (+1-1)

diff --git a/mlir/include/mlir/Dialect/Arith/IR/ArithBase.td b/mlir/include/mlir/Dialect/Arith/IR/ArithBase.td
index 19a2ade2e95a0e..b7dc984817a333 100644
--- a/mlir/include/mlir/Dialect/Arith/IR/ArithBase.td
+++ b/mlir/include/mlir/Dialect/Arith/IR/ArithBase.td
@@ -108,12 +108,13 @@ def FASTMATH_NO_SIGNED_ZEROS : I32BitEnumAttrCaseBit<"nsz",      3>;
 def FASTMATH_ALLOW_RECIP     : I32BitEnumAttrCaseBit<"arcp",     4>;
 def FASTMATH_ALLOW_CONTRACT  : I32BitEnumAttrCaseBit<"contract", 5>;
 def FASTMATH_APPROX_FUNC     : I32BitEnumAttrCaseBit<"afn",      6>;
+def FASTMATH_FTZ             : I32BitEnumAttrCaseBit<"ftz",      7>;
 def FASTMATH_FAST            : I32BitEnumAttrCaseGroup<
     "fast",
     [
       FASTMATH_REASSOC,         FASTMATH_NO_NANS,     FASTMATH_NO_INFS,
       FASTMATH_NO_SIGNED_ZEROS, FASTMATH_ALLOW_RECIP, FASTMATH_ALLOW_CONTRACT,
-      FASTMATH_APPROX_FUNC]>;
+      FASTMATH_APPROX_FUNC, FASTMATH_FTZ]>;
 
 def FastMathFlags : I32BitEnumAttr<
     "FastMathFlags",
@@ -121,7 +122,8 @@ def FastMathFlags : I32BitEnumAttr<
     [
       FASTMATH_NONE,           FASTMATH_REASSOC,         FASTMATH_NO_NANS,
       FASTMATH_NO_INFS,        FASTMATH_NO_SIGNED_ZEROS, FASTMATH_ALLOW_RECIP,
-      FASTMATH_ALLOW_CONTRACT, FASTMATH_APPROX_FUNC,     FASTMATH_FAST]> {
+      FASTMATH_ALLOW_CONTRACT, FASTMATH_APPROX_FUNC,     FASTMATH_FTZ,
+      FASTMATH_FAST]> {
   let separator = ",";
   let cppNamespace = "::mlir::arith";
   let genSpecializedAttr = 0;
diff --git a/mlir/test/Dialect/Arith/ops.mlir b/mlir/test/Dialect/Arith/ops.mlir
index f684e02344a517..0209d612273e6d 100644
--- a/mlir/test/Dialect/Arith/ops.mlir
+++ b/mlir/test/Dialect/Arith/ops.mlir
@@ -1127,7 +1127,7 @@ func.func @fastmath(%arg0: f32, %arg1: f32, %arg2: i32) {
 // CHECK: {{.*}} = arith.addf %arg0, %arg1 fastmath<nnan,ninf> : f32
   %7 = arith.addf %arg0, %arg1 fastmath<nnan,ninf> : f32
 // CHECK: {{.*}} = arith.mulf %arg0, %arg1 fastmath<fast> : f32
-  %8 = arith.mulf %arg0, %arg1 fastmath<reassoc,nnan,ninf,nsz,arcp,contract,afn> : f32
+  %8 = arith.mulf %arg0, %arg1 fastmath<reassoc,nnan,ninf,nsz,arcp,contract,afn,ftz> : f32
 // CHECK: {{.*}} = arith.cmpf oeq, %arg0, %arg1 fastmath<fast> : f32
   %9 = arith.cmpf oeq, %arg0, %arg1 fastmath<fast> : f32
 
@@ -1161,3 +1161,17 @@ func.func @intflags_func(%arg0: i64, %arg1: i64) {
   %3 = arith.shli %arg0, %arg1 overflow<nsw, nuw> : i64
   return
 }
+
+// CHECK-LABEL: flush_to_zero
+// CHECK-SAME: %[[ARG0:.+]]: f32, %[[ARG1:.+]]: f32
+func.func @flush_to_zero(%arg0: f32, %arg1: f32) {
+  // CHECK: %{{.+}} = arith.addf %[[ARG0]], %[[ARG1]] fastmath<ftz> : f32
+  // CHECK-NEXT: %{{.+}} = arith.subf %[[ARG0]], %[[ARG1]] fastmath<ftz> : f32
+  // CHECK-NEXT: %{{.+}} = arith.mulf %[[ARG0]], %[[ARG1]] fastmath<ftz> : f32
+  // CHECK-NEXT: %{{.+}} = arith.divf %[[ARG0]], %[[ARG1]] fastmath<ftz> : f32
+  %0 = arith.addf %arg0, %arg1 fastmath<ftz> : f32
+  %1 = arith.subf %arg0, %arg1 fastmath<ftz> : f32
+  %2 = arith.mulf %arg0, %arg1 fastmath<ftz> : f32
+  %3 = arith.divf %arg0, %arg1 fastmath<ftz> : f32
+  return
+}
diff --git a/mlir/test/Dialect/Math/ops.mlir b/mlir/test/Dialect/Math/ops.mlir
index 7e45d9bc6f74a9..6accd09647b8bb 100644
--- a/mlir/test/Dialect/Math/ops.mlir
+++ b/mlir/test/Dialect/Math/ops.mlir
@@ -289,7 +289,7 @@ func.func @fastmath(%f: f32, %i: i32, %v: vector<4xf32>, %t: tensor<4x4x?xf32>)
   // CHECK: math.trunc %[[F]] fastmath<fast> : f32
   %0 = math.trunc %f fastmath<fast> : f32
   // CHECK: math.powf %[[V]], %[[V]] fastmath<fast> : vector<4xf32>
-  %1 = math.powf %v, %v fastmath<reassoc,nnan,ninf,nsz,arcp,contract,afn> : vector<4xf32>
+  %1 = math.powf %v, %v fastmath<reassoc,nnan,ninf,nsz,arcp,contract,afn,ftz> : vector<4xf32>
   // CHECK: math.fma %[[T]], %[[T]], %[[T]] : tensor<4x4x?xf32>
   %2 = math.fma %t, %t, %t fastmath<none> : tensor<4x4x?xf32>
   // CHECK: math.absf %[[F]] fastmath<ninf> : f32

[kuhar]

I wonder if this should be something else than a fast math flag, e.g., a rounding mode or an execution mode. In SPIR-V it's the latter and you can only set it per the whole program: https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_execution_mode:~:text=4460-,DenormFlushToZero,-Any%20denormalized%20value, so I don't think we will able to lower FTZ on individual arith ops when lowering to SPIR-V.

[chelini]

I wonder if this should be something else than a fast math flag, e.g., a rounding mode or an execution mode. In SPIR-V it's the latter and you can only set it per the whole program: https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_execution_mode:~:text=4460-,DenormFlushToZero,-Any%20denormalized%20value, so I don't think we will able to lower FTZ on individual arith ops when lowering to SPIR-V.

Hi Jakub, I would like to have this attribute on a per-op basis since this is what PTX exposes. If you are around next week at the LLVM dev meeting, @matthias-springer , @joker-eph, and I will also be there, and we can have a roundtable discussion on this topic. What do you think?

[kuhar]

Sure, sounds good.

[kuhar]

We had a brief offline chat with @matthias-springer and @chelini about this today. Leaving a comment just so that I forgot what we talked about. This is based on my understanding, I should verify this:

• fast math adds assumptions but does not change semantics, should be safe to drop
• rounding modes change semantics and cannot be simply dropped

I think what we want is a rounding mode attr with well defined behavior that in the general case cannot be dropped / ignored during lowering. If SPIR-V doesn't support something, it should be clear that we are sacrificing correctness during lowering, but this shouldn't block us having these rounding modes for targets that can support it.

[joker-eph]

LLVM often uses target intrinsics instead for this kind of “exotic” attributes, especially when it can’t be supported consistently across target.
Another aspect is how much the attribute would affect other transformations on this op than just lowerings.

I am not sure what’s the right thing to do here, but I wanted to mention about tradeoffs.

[dcaballe]

I talked to Jakub during the LLVM Dev and I still have reservations about this. I don't see FTZ as significantly different from other flags in FMF that lead to approximate results. If we are concerned about the specific approximation to zero that FTZ enforces, we should consider a more open-ended “approxDenormals” FMF. Honestly, I would be surprised if functions used for “approxFunc” FMF are handling denormals properly. In my opinion, “approxDenormals” should allow for the approximation of denormals, and omitting this flag should result in more accurate results without necessarily changing the semantics. I wouldn’t walk the FMF vs rounding mode path. One could argue that “allowContract” is actually a “rounding mode” as, beyond contracting operations, what this flag states is that it’s ok to not round the intermediate results of the operations being contracted.

[kuhar]

The direction looks good overall

[kuhar]

LGTM. I haven't reviewed the logic carefully, so please get a second approval from someone who can do that.

[rengolin]

Hi Jakub, I would like to have this attribute on a per-op basis since this is what PTX exposes.

Additional data here: in Arm, VFP is IEEE compliant while NEON is not (has denormals). So per operation would be a way to distinguish. However, the front-end would have to distinguish between scalar (VFP) IEEE compliant and vector (NEON) with denormals. Not a trivial thing to get right.

@banach-space @smithp35

[dcaballe]

Thanks! The representation and initial lowering makes sense to me. We can dig a bit more into the scalar vs Neon case separately.

[chelini]

Thanks! The representation and initial lowering makes sense to me. We can dig a bit more into the scalar vs Neon case separately.

Perfect, thank you all. Let' keep discussing this. As I next step I will connect e2e with the LLVM dialect.

[joker-eph]

I have some concerns about the tradeoffs discussed here, it does not seem to me that this got explored and spelled out entirely.
In particular, we should start from thinking about the "charter" for arith: while it does not strictly limit itself to what LLVM supports, adding things that can't be expressed in LLVM likely deserve some sort of a higher bar (it can't be a "free for all" situation where we just append every possible thing that someone could imagine).
In the things that LLVM does not support, we have grandfathered the support for tensor type (which is now adopted and heavily used by OpenAI Triton for example) and we also support some MLIR-specific thing like multi-dimensional vector. But both of these can legalize to LLVM, it's not a divergence between arith and LLVM per-se.

I tend to see the situation a bit like it is handled when adding support for this kind of things into LLVM: there is a tradeoff between the added complexity (these need to be handled by transformations, canonicalizer, etc) and the added benefits (who are the users? Is it a widespread needed feature or something exotic? What are the lowering paths? What are the alternatives? Why not using target-specific intrinsics?). It is of course a case-by-case evaluation!

Discourse is likely a better place to discuss this, and this change likely deserved and RFC in the first place before landing (sorry I should have called this clearly initially, but I thought this would be discussed much more in practice).
Happy to book an Open Meeting slot to discuss this in a high-bandwidth setting if needed as well.

It may be more prudent to revert this in the meantime.

[rengolin]

It seems I have missed the discussion here. Some points...

Agreed, per operation makes more sense in the context of NEON. Though, admittedly, the only official doc that I could find for this covers ArmV7 and we are in ArmV9 era

Indeed. I mention this because, while LLVM has a definite set of targets, MLIR is more broad and widely adopted by a lot of accelerator start-ups, which usually have more than one compute unit (SIMD, systolic array, analog, etc) with different floating point behaviours.

That's interesting. Does this mean that if the scalar code is IEEE compliant and we are under a precise fp mode, the code should not be vectorized?

@dcaballe, that's exactly what the patch @banach-space mention does.

Which flags would allow changing an ieee denormal mode to ftz, for example? I think it's important that we document that.

This is again per target / extension. You may have conversion instructions, you may have soft-float helpers, and you may not. My original point here is this:

Denormal support is not a property of the operation, but the hardware micro-architecture it targets, including its runtime support.

While I said this may be thought of as a instruction-level property, it doesn't have to be. In reality, the compilers that try to compile individual instruction in separate units (think mixed AI accelerators) do so in a precise way and thus control the distribution. In the end, those instructions need to be fetched by different units and thus be at the very least in separate regions in the object file, but most commonly in separate libraries altogether.

How does this affect the implementation? I don't know. I have not spend time, nor have a use case in hand, to have a good answer.

@joker-eph, while I agree with your general point and the need for a charter, your comment is not specific enough to warrant a reversal. Perhaps you could be a bit more specific in a forum thread and we continue from there? Also, @chelini, if you could expose the usage pattern you're looking for, that'd give more power to your argument.

Generally, changes to core dialects like arith should really go through an RFC on the forum before being a PR. Usually, the simple cases are quick enough (this one took only a couple of days). This is yet another thing we need to get right in the charter for the whole project, but first we need to define what a "core dialect" means and which are they.

[banach-space]

Updated reference:

The only official doc that I could find for this covers ArmV7, and we are in the ArmV9 era.

Here’s the latest spec covering ArmV9: link.

Unfortunately, I haven’t had as much time to analyze it as I’d like. I’m hoping to focus more on this area next quarter, though I can’t promise anything definitive.

Regarding the concerns raised by @joker-eph
I suggest the following:

• Add a note in the code marking this as "experimental" to highlight ongoing discussions.
• Post an RFC on Discourse to gauge broader feedback on the approach taken here.

While LLVM has a liberal revert policy, these steps should help us make a more informed decision. Based on the RFC feedback, we can decide whether to revert, re-implement, or redesign.

How does this affect the implementation? I don't know. I have not spent time, nor do I have a use case in hand, to have a good answer.

I feel the same - it’s a bit of a chicken-and-egg problem at this point.

Also, @chelini, if you could expose the usage pattern you're looking for, that'd give more power to your argument.

+1 to this.

[joker-eph]

@joker-eph, while I agree with your general point and the need for a charter, your comment is not specific enough to warrant a reversal. Perhaps you could be a bit more specific in a forum thread and we continue from there?

My comment is that without being able to clearly map this change to the "charter" for arith, we can't just land this as-is without proper RFC/discussion. We're back to:

Generally, changes to core dialects like arith should really go through an RFC on the forum before being a PR.

The fact that you missed this discussion is a good indication that this didn't get enough visibility.

In this case my concerns about this change and the associated tradeoffs to consider, warrants a revert IMO.
This is in line with LLVM developer policy and past practices:

• Remember, it is normal and healthy to have patches reverted. Having a patch reverted does not necessarily mean you did anything wrong.
• Any time you learn of a serious problem with a change, you should revert it.
• If you are asked to revert by another contributor, please revert and discuss the merits of the request offline (unless doing so would further destabilize tip of tree).

So again: please revert, and discuss first in a RFC.

[kuhar]

My position is that this change seems consistent with the existing philosophy of the arith dialect. Like I summarized on Discourse, arith is slightly higher level than both LLVM and SPIR-V and is not just a mirror of either of the two. We already have some things that are not trivially mappable to spirv (e.g., anything related to non-standard integer types, freeze semantics (adjacent to arith)). I think we generally have to be careful with these if they have a clear lowering path to llvm and spirv, but both the examples I just listed and denormal flags are fine because they will be decided by some 'frontend' instead of folds or default rewrite patterns. For this reason, I'm fine with this PR and I don't consider it going against any written documentation for arith or be otherwise precedent-setting.

[joker-eph]

My position is that this change seems consistent with the existing philosophy of the arith dialect.

This is a reasonable thing we can debate in the RFC.

I'm personally not convinced: because LLVM IR and actual LLVM targets other than PTX don't seem support this right now, and the tradeoffs/alternatives with how we would manage this have to be considered, it didn't happen here so far: an RFC is the way to go to ensure this.

If we had done it, we'd be in position right now to properly document this feature on https://mlir.llvm.org/docs/ ; this PR didn't document nor discuss clearly the expectations and the plans for the support for this feature or anything, I couldn't update https://mlir.llvm.org/docs/Dialects/ArithOps/ even if I wanted to right now!
Also what's the plan with the canonicalizer/folding and all the code handling arith? Is there an actual plan to get this updated and honor this new mode of arithmetic?

[stellaraccident]

+1 on continuing on discourse. -1 on a pre-emptory revert. (I very much appreciate the effort and thought leadership work that went into this and I think it is easy to look in retrospect and see that a multi-month conversation grew to something that should have been a broader discussion. But the group of stakeholders here is small enough that I think that the path forwards is a low stake discussion on Discourse about how to evolve this piece, and that it benefits nobody to lead with a revert)

[dcaballe]

Thanks everyone for the feedback. What started as a simple extra FMF flag evolved into a more comprehensive denormal model, which indeed would have required an RFC. Apologies for not signaling this earlier. However, the PR has been open for nearly two months and discussed multiple times offline with Jakub and others, including F2F at LLVM Dev. The proposal incorporated the feedback provided so we felt confident enough to proceed.

A few points I wanted to clarify, some already made by others:

"Free for all": I don't think describing this proposal as "free for all" is accurate. We are not proposing an Nvidia-specific modifier but a generic way to model various denormal behaviors. This is applicable to any hardware and even includes denormal modes which are not supported by our hardware.

"Exotic": I don’t think "Exotic" fits here either. Denormals (unfortunately!) are a fundamental part of the FP model, and the lack of representation is a gap in our ecosystem which is impacting everyone. Besides the emerging AI architectures that Renato mentioned, a quick search led to:

• Nvidia's FTZ instructions/intrinsics (see PTX ISA 8.5).
• AMD's FTZ instructions/intrinsics (see lit test)
• AVX-512's instructions/intrinsics to check for denormal values at instruction level (see Intel® Intrinsics Guide)
• Neon's exclusive FTZ mode and its evolution across VPU generations: (see Learn the architecture - Neon programmers' guide)

Denormals in LLVM: LLVM's denormal model is best-effort (see “denormal-fp-math” in LLVM Language Reference Manual — LLVM 20.0.0git documentation) and carries legacy baggage so I don’t think LLVM should be used as a strict role model for this particular case. It seems more reasonable to me to learn from LLVM and create something that better aligns with today's hardware requirements, which is what we were aiming for.

Per-instruction Denormal Mode: Besides the per-function mode, LLVM seems to allow finer control of the FP mode with llvm.set.fpmode and llvm.get.fpmode intrinsics (see https://llvm.org/docs/LangRef.html#llvm-set-fpmode-intrinsic). This should allow us to lower Arith to a generic per-instruction denormal model in LLVM.

Denormals and Compiler Infrastructure: As Jakub mentioned, the compiler's role with denormals is to propagate and preserve the behavior set by the front-end/framework. The compiler shouldn't be randomly changing the denormal mode. Consequently, it should be low risk to classify the denormal mode as something experimental while investigating/fixing any potential issues.

We'll follow up with an RFC on Discourse. Thanks again for your input.

[rengolin]

My comment is that without being able to clearly map this change to the "charter" for arith, we can't just land this as-is without proper RFC/discussion

Unfortunately, there is no charter for arith. Once we get the governance ready (I started writing the document, will share with you once it reached the draft state), we will get to it. Right now, I don't think anyone can claim they know what the charter is.

The fact that you missed this discussion is a good indication that this didn't get enough visibility.

That's a stretch. Especially because...

the PR has been open for nearly two months and discussed multiple times offline with Jakub and others, including F2F at LLVM Dev. The proposal incorporated the feedback provided so we felt confident enough to proceed.

This is a perfectly valid course for LLVM, a bit on the cautious side. I cannot claim "because I didn't see, it wasn't properly discussed" with this history. Reverting now would warrant a stronger reason than "I didn't see" or "I wasn't convinced".

That's why we so desperately need a charter!

This is applicable to any hardware and even includes denormal modes which are not supported by our hardware.

Agree, and we gave a few examples before it was approved and merged.

Denormals (unfortunately!) are a fundamental part of the FP model, and the lack of representation is a gap in our ecosystem which is impacting everyone.

Yup.

It seems more reasonable to me to learn from LLVM and create something that better aligns with today's hardware requirements, which is what we were aiming for.

+1 to this point. I'd hate to repeat the same mistakes. My patch referenced by Andrzej was a blunt instrument to something that should have been better planned from the start, but we didn't know better. Now we do.

Consequently, it should be low risk to classify the denormal mode as something experimental while investigating/fixing any potential issues.

Exactly. No one that doesn't know what they're doing would ever pick those attributes, and the compiler should never add them without really knowing what it's doing.

I also don't see the current implementation as problematic. Maybe naive, but not wrong or in need of revert.

[joker-eph]

Reverting now would warrant a stronger reason than "I didn't see" or "I wasn't convinced".

I mentioned concrete concerns, please don't reduce my design concern like this.
I believe they stand, and we have been able to process that way in LLVM and MLIR for years without the need to change the governance or write any more charters.

Such change should go through an RFC, it didn't, @dcaballe and @chelini will process with a discussion in a RFC, but that's not a reason to not revert. My concerns are warranting a revert according to every precedent in the project AFAICT.

The proposal incorporated the feedback provided so we felt confident enough to proceed.

@dcaballe, you didn't do anything wrong, quoting back the developer policy:

Remember, it is normal and healthy to have patches reverted. Having a patch reverted does not necessarily mean you did anything wrong.

[stellaraccident]

-1 on revert

[rengolin]

Such change should go through an RFC, it didn't, @dcaballe and @chelini will process with a discussion in a RFC, but that's not a reason to not revert. My concerns are warranting a revert according to every precedent in the project AFAICT.

You're mixing the arguments and picking and choosing precedent. Nothing in LLVM is this clear cut and I would not like to see it begin now. For the past few years I have supported your cause to make MLIR more mobile and have often argued in your favour in multiple forum threads. This is definitely not personal, or reductionist.

But "should" is not "must". If patches were reverted every time someone didn't do what someone else thought they should have done we would not have the project we have today. This is not a reasonable request.

@dcaballe, you didn't do anything wrong, quoting back the developer policy:

Remember, it is normal and healthy to have patches reverted. Having a patch reverted does not necessarily mean you did anything wrong.

Quoting this over and over again will not make it more valid to this particular thread. No one else in this discussion agrees with you that it applies and the patch should be reverted, and we all know by heart the LLVM policy. It is healthy to have your patches reverted, but I'm not going to start reverting patches simply because I don't agree with. It is also healthy to hash out design upstream and this is what they're doing. There's also enough precedent for that in LLVM. We'll discuss this in an RFC and if we find consensus that this is wrong, we change course. If not, we continue.

To be clear, the charter would not have stopped this PR from being merged, or forced people to submit an RFC beforehand. It would have made it easier to argument pro and against technical points in the charter, instead of what we (individually) think the other should have done.

For example, if we had a clear technical charter for arith/math, in line with llvm etc., Lorenzo et al would have started this PR towards that charter instead, and none of this discussion would have occurred, because it would have been "right" from the start. But they acted on the charter than they believed was right, others agreed, and here we are. 100% pure-bred LLVM style.

Perfect? No. But eventually consistent.

[chelini]

Thank you for your feedback and reviews on this PR. I appreciate your time and effort in providing constructive comments. Reflecting on the discussions and concerns, I underestimated this change's complexity and implications. While I had discussions with Jakub and Diego and felt confident in pushing this forward, it is clear that the decision was premature. For this, I apologize; an RFC would have been a better first step.

I have reviewed the comments on this PR multiple times and have decided to revert these changes. Moving forward, we should formalize the discussion around implementing denormal handling through an RFC since canonicalization and folding concerns are grounded. I also want to avoid a precedent where a member's feedback is not considered or ignored. We don't need a consensus to revert; we need a consensus not to. The MLIR community is already fragmented, and I don't want to make this situation worse than it already is.

[chelini]

@chsigg I reverted this PR; let me know if you need help undoing the changes you made in Triton.