You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Harmonize *ScaledMMAAttr operand order and drop MMAFragment (#22465)
This PR does multiple things that were easier done all at once:
1. Harmonize `*ScaledMMAAttr` operand order:
* The operand order of `ScaledMMAAttr` was `lhs, lhs_scale, rhs,
rhs_scale`, while the operand order of `DataTiledScaledMMAAttr` was
`lhs, rhs, lhs_scale, rhs_scale`.
* This PR changes `ScaledMMAAttr` to match the `DataTiledScaledMMAAttr`
convention. This propagates to a change of operand order in the
enclosing `inner_tiled` ops.
2. Drop `MMAFragment`:
* There used to be a TableGen enum `MMAFragment`, that had unclear
semantics: the enum values were sometimes used as opaque symbolic enums
to refer to operand by "role", e.g. "Lhs", and sometimes used as the
underlying integer values as operand indices, e.g. "Rhs == 1". This was
originally OK as all MMA-like ops had the same 3 operands Lhs, Rhs, Acc.
But when ScaledMMAAttr was introduced, that didn't... scale: now the
preexisting enum value "Rhs == 1" didn't equal anymore the corresponding
operand index under the `lhs, lhs_scale, rhs, rhs_scale` convention (1
!= 2) and even regardless of convention, the enum value "Acc ==2" never
corresponded to operand index anymore (2 != 4).
* This PR drops MMAFragment and generalizes the use of plain integer
`operandIndex`.
* This is made reasonable to implement by the harmonization of operand
orders (above 1.). If we tried doing this without 1., then we would feel
more of a need for opaque "role" enums to replace MMAFragment without
having to fix up operand indices between two conventions.
3. Drop some logic that only existed to make up for the discrepancy
between convensions and the fuzzy semantics of MMAFragment.
Signed-off-by: Benoit Jacob <[email protected]>
0 commit comments