Han-Chung Wang

@jinchen62 did you get a chance to see which op is generating the IR? The generic op looks invalid to me, like I explained in the above comment.

I'd suggest to check if there are bugs in torch -> linalg lowering, or other high level dialects -> torch lowering.

I'm not convinced that the issue is `tensor.cast`. There are some shape inference passes/patterns in MLIR dialect, and they create tensor.cast op to spell out some static shapes. With the...

cc @rednoah91

Thanks @mshockwave, I'll help re-enable the test after the fix is propagated to IREE!

As mentioned in the other issue https://github.com/iree-org/iree/issues/20785, we want to get rid of lowering config propagation. It implies that we will switch to `TileRootAndFuseProducerConsumer`. The issue mainly demonstrates that it...

> Get rid of as in not have it at all and use the [same mechanisms](https://github.com/iree-org/iree/blob/main/compiler/src/iree/compiler/Codegen/LLVMCPU/KernelDispatch.cpp) (or modified versions) used for setting the lowering config on the first place on-the-fly?...

> Also, I know that it's theoretically possible to have pack->generic cases, but is that really a pattern that is observed often? Because with the fusion data-tiling path, I guess...

@egebeysel let's move the pack fusion discussion to https://github.com/iree-org/iree/issues/20723, and make the scope of this issue be: solving the redundant buffer issue in TileRootAndFuseProducerConsumer approach.

@pashu123 I shared how CPU codegen pipeline works, lowering_config details, and strategy selection idea with @AaronStGeorge this week. Now he has better understanding, and starts playing the IR with your...