[Mlir-commits] [llvm] [mlir] [mlir][vector] Prevent crashing on bitcast breakdown (PR #206683)

[llvmlistbot at llvm.org]

LouisLu060211 wrote:

> Hi @LouisLu060211,
> 
> Thank you for the patch! Unfortunately, I do not think Vector should move in this direction.
> 
> From your summary:
> 
> > For example, vector<16xi3> to vector<3xi16> has 48 bits on both sides, but 16 is not divisible by 3.
> 
> It sounds like you are looking for logic to model sub-byte types in Vector. There is already [VectorEmulateNarrowType](https://github.com/llvm/llvm-project/blob/0b5c006208cf7b0fee3709f468152e7de81607ef/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp) for this purpose. While that pass works, it is admittedly somewhat fragile. In my opinion, this is because we never fully settled whether it should support arbitrary integer widths such as `i3`.
> 
> In hindsight, I think `VectorEmulateNarrowType` should not support such exotic types. The underlying logic is very complex, difficult to support, and there does not seem to be enough interest in maintaining it beyond very narrow use cases. In other words, the current support is not very general.
> 
> I also question whether `i3` is a type we should support beyond the most basic examples. I appreciate that some users may want this, but supporting it generally would come at a significant maintenance cost. IMHO, we should instead prioritise the more common cases that have more users and reviewers.
> 
> Is this a major blocker for you? If we start unblocking cases like this, I am worried that we will also need to review many other Vector transformations, such as unrolling and flattening, to make sure they bail out cleanly. That would be a substantial effort, and I would prefer to avoid it at this point.
> 
> If you have broader plans for sub-byte types, I would be happy to hear them.
> 
> Thank you!

@joker-eph After reading your comment. The verifier can actually accept this bitcast because the total bit widths match. So the crash comes from that gap. If the correct fix is to tighten the verifier so cases like vector<16xi3> to vector<3xi16>. Feel free to let me know again, and I can rework the PR.


https://github.com/llvm/llvm-project/pull/206683