[clang] [llvm] [mlir] Enforce single-operand form for llvm.loop.distribute metadata (PR #201077)

[Madhur Amilkanthwar via llvm-commits]

================

----------------
madhur13490 wrote:

> Should this verify that enable and disable are mutually exclusive?

Yes, I think so. We need two solutions here:
1. Verifier should disallow the presence of both `.enable` and `.disable` nodes. There is no point in having both.
2. However, verifier is not guarateed to run all the times and passes may hold both nodes transiently. I see that `setForced()` currently lets `.enable` win while `hasDistributeTransformation()` lets .disable win. We should give `.disable` precedence. It matches every other loop-transform reader — `hasUnrollTransformation()`, `hasUnrollAndJamTransformation()`, `hasVectorizeTransformation()`, and `hasDistributeTransformation() all check .disable first.

(rejecting contradictory markers is idiomatic in the verifier — zeroext/signext, readnone/readonly, the DI hasConflictingReferenceFlags helper, etc.). This would be the first loop-metadata pair to enforce it; the unroll/vectorize pairs only rely on reader precedence today, so we can extend the same check to those as a follow-up.

> I'm also confused why this is turning a parameterized metadata into 2 ... I expect optimization annotations to work in one direction, and there to be no distinct meaning between no annotation and a false.

For distribution, "disable" is genuinely distinct from "absent" — it's tri-state, not one-directional:

1. enable → force distribution on;
2. disable → force it off even when distribution is enabled globally 
3. absent → follow the global default / heuristic.
That's exactly the existing TransformationMode tri-state (TM_ForcedByUser / TM_SuppressedByUser / TM_Unspecified) shared by all loop transforms, so we can't collapse it to enable-only.

If this make sense, I'll have a fixup commit to address.


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