[Mlir-commits] [mlir] [mlir][xegpu] Fix operand layouts when rematerializing on layout conflict (PR #224730)

[Charitha Saumya]

================
@@ -1652,6 +1652,36 @@ LogicalResult ResolveLayoutConflicts::assignResultLayout(OpResult &result) {
   return success();
 }
 
+// Recursively rematerialize a trivially-rematerializable producer subtree so
+// that the clone yields `layout`. Cloning only the producer would leave its
+// operands pointing at values that carry the original (conflicting) layout,
----------------
charithaintc wrote:

maybe I am misunderstanding something.

> I don't' understand why we discuss "conflict" here. 

If no conflict is involved, then why we "clone" things here? isn't that to avoid conflicts. maybe I did not get this part.

My point was assuming we clone things to avoid a conflict, it should be no different than how we handle any other conflict. why specialize cases and make the code hard to understand. 

> Not sure how you can write a clean while loop if you need walk backward to all ancestors.

In my understanding a fixed point algo works like below for this case.

```
while (changed) {
    changed = false
    bool b = walkAndHandleAnyNewConflict(root)
    if (b) changed = true
    else changed = false
}
```

This will run until the IR has no more conflicts. 

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