[Mlir-commits] [mlir] [mlir][vector] Linearization: push 'bit width' logic out of patterns (PR #136581)
James Newling
llvmlistbot at llvm.org
Wed Apr 30 14:30:19 PDT 2025
newling wrote:
> Sorry for the delay with this, I was waiting for either other reviewers to comment or for a "ping", I wasn't expecting this to be merged in the meantime 😅 Feel free to ping me directly if things go stale.
>
> I've left a couple of comments - these can be addressed in a separate PR (this change is overall good, thanks!). I'm just still a bit confused about the logic around "scalable" vectors. Since you've looked at it recently, do you know the answer? (see my question inline)
Apologies @banach-space , I assumed you were fine with committing as is. I'll 'ping' the PR next time. In response to your questions (I'll also post a PR improving the docs):
> What does it mean to be "non-linearizable"?
Here it just means "we don't have a pattern to linearize it yet". Or equivalently, that the ConversionTarget should consider it legal, and so we should not fail if it is not converted by a pattern.
> Is linearization disabled in the presence of scalable vectors?
Yes, but only for some ops. Other ops have implementations for linearizing scalable vectors.
I think some of the confusion (and complexity) here could be avoided if linearization was implemented as just a bunch of patterns to append to a `RewritePatternSet`, like most of the functions in `VectorRewritePatterns.h`. I'm not sure why it was implemented as a legalization (i.e. with a `ConversionTarget` and a `TypeConverter`) in https://github.com/llvm/llvm-project/pull/81159 ( @Hardcode84 ? )
Also if anyone is opposed to this PR please let me know and I'll revert it (ping : @dcaballe @bviyer )
https://github.com/llvm/llvm-project/pull/136581
More information about the Mlir-commits
mailing list