[AMD] Added canonicalization pattern to propagate DotOp attrs

[ravil-mobile]

Addressed Issue #https://github.com/ROCm/triton-internal/issues/727

---

Closes #https://github.com/ROCm/triton-internal/issues/727

[guacamoleo]

Alright, I'm getting back to this after our May sprint.

For this PR can you add a clarifying comment as to what direction attributes are being propagated and why. You could add something like the below explanation, but fixup the syntax a bit.

// DotOpMFMAConverter() add dotAttr to refine dot ops, and to the extract_slice of the dot operands.
// When the canonicalizer matches the concat of local_loads and extract_slice of the dot operands,
// the dotAttr needs to be coppied from the extract_slice of the dot operand to the local_load.
// This allows Triton to match refined local_loads to refined dots. For example
regA = local_load addrA
regB = local_load addrB
dot regA regB

--- after refinement ---

addrA0 = extract_slice addrA, 0
addrA1 = extract_slice addrA, 1
addrB0 = extract_slice addrB, 0
addrB1 = extract_slice addrB, 1

regA0 = local_load addrA0
regA1 = local_load addrA1
regB0 = local_load addrB0
regB1 = local_load addrB1

regA = concat regA0 regA1
regB = concat regB0 regB1

regA0 = extract_slice regA, 0  dotAddr00
regA1 = extract_slice regA, 1  dotAddr10
regB0 = extract_slice regB, 0  dotAddr00
regB1 = extract_slice regB, 1  dotAddr01

dot regA0, regB0  dotAttr00
dot regA0 regB1  dotAttr01
dot regA1, regB0  dotAttr10
dot regA1, regB1  dotAttr11

--- after canonicalization ---

addrA0 = extract_slice addrA, 0
addrA1 = extract_slice addrA, 1
addrB0 = extract_slice addrB, 0
addrB1 = extract_slice addrB, 1

regA0 = local_load addrA0  dotAddr00
regA1 = local_load addrA1 dotAddr10
regB0 = local_load addrB0  dotAddr00
regB1 = local_load addrB1  dotAddr01

dot regA0, regB0  dotAttr00
dot regA0 regB1  dotAttr01
dot regA1, regB0  dotAttr10
dot regA1, regB1  dotAttr11

[guacamoleo]

I'm not sure what this is prohibiting; we do want to allow these attributes to be carries across basic blocks. For example, they could be loop carried, or we could prefetch a tile of data in the prologue, and we want to get the order of loads in the prologue to match the dot ordering in the loop.

[guacamoleo]

What is this prohibiting and allowing?

[guacamoleo]

Is this block of code ensuring we only add a dotAttr if one doesn't already exist?
If so, this can also be used as a recursion exit criteria. For example, after we've labeled all the refined local_loads with their dotAttr, then we recursively label all their respective subviews with dot attribute, which is good.
But then when we recur from all the subview to the same parent, we can't place all the children't dotAttr onto the same parent (since the labels only refer to refinement), so we can exit the recursion at that point. Meaning when an op already has a dotAttr, don't recur to it's parent.