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

[Renato Golin]

rengolin wrote:

> So for canonicalization candidates I rather look at:
> 
> * is the transformation performed with only local information?
> * is the transformation "cheap" enough or does it require extensive computation?
> * is the transformation undoable easily (with similar local information), that is "no information is lost".

To me, the **reversibility** is the key. No loss of information, not just program interpretation (which could say _undefined behavior_ is fair game).

For example, what constitutes "local" can be a matter of interpretation. It is `op`-local, `bb`-local, `function`-local, or `module`-local? And what is _cheap_ even? Maybe a `O(n^2)` canonicalization can avoid a `O(n^3)` matching later, and is therefore _cheaper_ than not running it.

LICM can be argued that uses non-local information (op + loop + loop dependency analysis looking at the context, not just the op itself). The same can be said for CSE, since it looks at multiple expressions. Even simpler things like expression order canonicalization (`x + 10 + y + 5` -> `x + y + 10 + 5` -> `x + y + 15`), because there are multiple `add` ops that you need to look through on what constitutes an _expression_.

So, I try not to argue too strongly which passes are canonicalizations and which are not. My suggestion to have them separate is not to determine what is what, but to allow interim pass bundles to control which type of canonicalizations (reversible changes into canonical shapes) we apply within. But in between these "bundles", we should always run all of them until a fixed point.

What determines a "bundle" isn't always clear, so don't take my suggestion as concrete, just as a design goal for an upstream pipeline that we all use, so we can collaborate upstream without reinventing the wheel downstream.

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