[Mlir-commits] [mlir] [mlir][SCF] Deprecate `linalg::tileToForallOp` and `linalg::tileToForallOpUsingTileSizes` (PR #91878)

[llvmlistbot at llvm.org]

MaheshRavishankar wrote:

> Thanks for making progress on this!
> 
> I see this seems to single out tiling by tileSizes, what is the plan for numThreads?
> I want to make sure this is not an attempt to remove it because it would be a non-starter: it connects to further transforms for which the information is important.

It's not being removed. The numtiles option added here translates to num threads when using scr.forall (as mentioned in the description). I have t updated the lit tests yet cause I wanted to gather some initial feedback before going and fixing the lit tests (they all run and I have visually verified they look ok, but some existing lit tests have some strange semantics like zero sliced tensors)

Id like to understand more what is load bearing on the num threads aspects as opposed to just using tile sizes. They seem interchangeable to me. I have a mental model of how you can use tile sizes and make it work all the way. From whatever I have seen the num threads path creates more indexing math and some weird corner cases (there is a lit test that is producing zero sized slices for example that is particularly scary). 
Can you provide some information about what transformations need the num threads information that cannot be derived when needed (like just getting the number of iterations of the loop)


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