[Mlir-commits] [mlir] [mlir][linalg] Account for preserved outs in fusion bounds (PR #228467)

[Ziliang Zhang]

ziliangzl wrote:

> Sorry, I think I need a bit more context on this change. Could you please provide that? Some of the examples added here for lit-tests are not necessarily caught as invalid by Linalg right now, but they are a bit ill-formed. For example take this operation
> 
> ```
> linalg.generic {
>     indexing_maps = [affine_map<(d0, d1) -> ()>, affine_map<(d0, d1) -> (d0, d1)>,
>                                      affine_map<(d0, d1) -> (d0)],
>     iterator_types = ["parallel", "parallel"]}
>     ins(%a : tensor<f32>) outs(%b, %c : tensor<?x?xf32>, tensor<?xf32>) ->
>         (tensor<?x?xf32>, tensor<?xf32>)
> ```
> 
> this is inherently problematic cause if you write this as loops you get
> 
> ```
> for (i = ...) { // parallel
>    for (j = ...) { // parallel
>        b[i][j] = ...
>        c[j] = ...
>    }
> }       
> ```
> 
> This is a race condition on `c`. Now Linalg operations inherently dont disallow that (maybe they should).
> 
> My issue with this change is something that was disallowed by default, is now allowed and the resulting operation's semantics isnt clear.

You are right that the added test is not a valid motivating case. I also do not currently have a real application or pipeline that produces this pattern. The motivation is to fix an inconsistency: preserved producer outputs are included in the fused operation, but the loop-bound check currently ignores them.

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