[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