[Mlir-commits] [mlir] [mlir][scf] Add simple LICM pattern for `scf.while` (PR #76370)

[Thomas Raoux]

ThomasRaoux wrote:

> > By that definition many optimizations can be considered a canonicalization but yet I don't think we would want to do them as part of canonicalizations.
> 
> Like what?
> 
> > There are precedents where we decided to not do some transformation as canonicalizations as they are too opinionated. I think this is one of those cases.
> 
> Please elaborate: I'm on the opposite side and I don't quite perceive the reason here. Not doing a canonicalization should be exceptional and very well motivated IMO. I'm wary of getting into being afraid of adding more canonicalization.
> 

Here are few examples of transformations that were moved out of canonicalization over time because having more control over when transformations are applied was necessary: 
https://github.com/llvm/llvm-project/commit/01055ed1d72dd74d0dcdf29d2cb734704ad673cb
https://github.com/llvm/llvm-project/commit/da8a8e9280ec6fb5ef9f94cba53959192145d164
https://github.com/llvm/llvm-project/commit/4142932a834f0dca9e9ae0c3754f097ffa3fc1ef

That's just some examples from a quick search but I recall there were more.

> > My concern is that it won't be possible to consider the initial IR to decide whether some IR should be inside or outside the loop. It seems common for compilers to have some kind of cost model for LICM (or other code motion) and this will prevent that for all users.
> 
> I don't understand what you're trying to say here? What does it mean "initial IR"?
> 
> To me the input program to the compiler is "arbitrary", I don't put any value on the "initial IR" in term of being more "optimal". Doing so would break composability and goes entirely against the concept of canonicalization as I understand it.

I understand the reasoning but in practice it is common for compilers to relying on the original program as fall back when a transformation is not obviously a win.

I don't understand where is the line with regards to canonicalization if we go that route. What kind of transformation would not be a canonicalization then? Would function inlining be a canonicalization for instance? And if not why?

My interpretation (admittedly not based on docs but inferred from use cases)  was that canonicalization were a set of always good  simplifications that allowed the rest of the compiler to make it simpler for other transformations to decide which form of IR to expect. 

My concern is that this could significantly reduce user control over what transformations are applied as canonicalization has to be applied as all or nothing and those patterns are usually not exposed otherwise, preventing any alternative solution for users.



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