Han-Chung Wang

Adding `--iree-opt-data-tiling=false` should disable the data-tiling. I can't tell much without looking at logs.

There is a bug in `getFuncExecutableTargetAttrs` on data-tiling path. The bug is likely in HAL device analysis and I can take a look. There is another issue about disabling data-tiling....

Sorry that I was busy on other stuff today, so no more updates from my side. I'll prioritize this issue tomorrow.

It's fixed by https://github.com/llvm/llvm-project/pull/103401, closing the issue.

Thanks for the heads-up! I'm taking a look and will provide a fix.

> Linux CI seemed to pass... I can try my local Windows at an earlier commit 🤔 That's weird. I think it should generate deterministic IRs... compiling IREE on linux...

> Why do we want to "conserve the vector transfers"? Say that the original input is: ```mlir %extract = tensor.extract_slice %source %read = vector.transfer_read %extract %write = vector.transfer_read %dest %insert...

Inlining the mlir input below. In the beginning, I thought that the `(d0, d1) -> (0, d0)` is generated during codegen, but it is the case. There is `(d0, d1)...

I worked with @jinchen62 and we got a smaller repro: https://gist.github.com/hanhanW/b3652f5887b93fb8f0df6c6c39c1ef87 To repro, run `iree-opt --pass-pipeline="builtin.module(util.func(iree-flow-fold-unit-extent-dims))" ~/repro.mlir`. Then you'll see `affine_map (0, d0)>` in the result. ```mlir #map2 = affine_map...

Actually, the input reduction op looks weird. The size of `d0` mismatch. One is `1` and the other is `?` It looks like there is a bug in frontend lowering....