[RFC][mlir][vector] Modify/remove bit-width specific flattening/linearization

So I’d like to retract that support for now .

That’s totally fine. I agree that the decision should be based on this broader scope. Writing this RFC was a good exercise, it forced me to reveal more of the context.

That said, I don’t fully follow the phrase “inner 2 dimensions” - in your example, it looks like only a single dimension is being collapsed. But that’s just a nit.

I think we mean the same thing, by collapse the inner N dimensions (of a rank M+N thing) I mean flatten N dimensions into a single dimension. So go from rank M+N to rank M+1. I’ll be more explicit next time to avoid this ambiguity!

This seems to stem from the presence of the trailing unit dimension .

I’d rather say that the unit dimension reveals the extreme case. To me the unintuitive behavior persists when the trailing dim isn’t 1. Consider 3 types T1) 1600xi1 T2) 100x16xi1 T3) 100x4x4xi1.

With a bit-threshold of 8, transfer_read operations are converted as follows: T1 -> T1 and T2 -> T2 and T3 -> T1. Which is better, T2 or T1 ? If T1 is better, then why not T2 -> T1? If T2 is better, then why not T3 -> T2?

The current algorithm is:
If the rank-1 form is better, convert to the rank-1 form.

The gradual lowering (proposal 3) algorithm:
While the rank N-1 form is better, convert from rank N to rank N-1 form.

The latter seems better to me. I can’t provide a strong argument for why.

This last point makes me wonder: shouldn’t the bit-width logic be a no-op when targetVectorBitWidth is not provided? If not, maybe that’s something we should fix directly?

It is, yes. The issue I have is that if I change the patterns to flatten more gradually, the bit-width related linearization tests fail - linearization gets stuck at T2 and doesn’t go to T1. Just to clarify, I am not blocked from making progress if we don’t change the logic (proposal 4). It would just mean less compact code, because I need to retain the ‘direct path’ patterns.

Another thought I’ve had is that flattening of transfer_read/transfer_write (code) is a kind of linearization, and maybe Vector could be simplified by moving it to linearization (with options to choose subsets of patterns).