vgather support i8/ui8 -> i16/ui16 - #1315
Open
Likai-19 wants to merge 1 commit into
Open
Conversation
Likai-19
force-pushed
the
feature_vmi_vgather
branch
from
August 21, 2026 07:12
3476eb4 to
712e8c7
Compare
mouliangyu
reviewed
Aug 24, 2026
| static bool isSupported16BitGatherResult(Type sourceElemType, | ||
| Type resultElemType) { | ||
| auto resInt = dyn_cast<IntegerType>(resultElemType); | ||
| if (!resInt || resInt.getWidth() != mlir::pto::kValue16) { |
Collaborator
There was a problem hiding this comment.
[P1] 文档声明与 verifier 不一致：这里的 isSupported16BitGatherResult 只接受 IntegerType 且宽度为 16，因此 f16/bf16 的 B16 gather 会在 VMIGatherOp::verify() 阶段被拒绝，无法到达 lowering。PR 文档却把 f16/bf16 -> matching result 列为已支持类型。请在本 PR 中实现并补 runtime 覆盖，或删除/修正文档中的 float 支持声明。
mouliangyu
requested changes
Aug 24, 2026
mouliangyu
left a comment
mouliangyu
left a comment
Collaborator
There was a problem hiding this comment.
检视结论：需要修正文档与 verifier 的支持范围不一致。当前实现并不支持文档声明的 f16/bf16 B16 gather；请实现并补 runtime 覆盖，或撤回该声明。
Zhendong404
requested changes
Aug 25, 2026
| | `offsets` | `VRegType` | Per-lane element offsets (integer VMI vector) | | ||
| | `mask` | VMI mask | **Required.** Predicate mask gating lane participation | | ||
| | `pmode` | `str` or `None` | Optional predicate mode: `"merge"` keeps predicate-inactive lanes at their prior value; `"zero"` writes 0 | | ||
| | `result_type` | `VRegType` or scalar dtype | Optional result VMI vector type; defaults to the source element type. Required for i8/ui8 -> i16/ui16 promotion. | |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This change broadens pto.vmi.vgather so it can serve a wider range of indexed-gather workloads on the A5 vector pipe. Previously vmi.vgather only handled a single path (32-bit results, 32-bit element offsets, b32 mask, one physical register). This PR makes the full B16/B32 gather family available, adds byte→halfword promotion, and lifts the single-register restriction up to the ISA limit.
New scenarios now supported
8-bit → 16-bit gather (zero-extension promotion) A UB buffer of 8-bit elements (i8/ui8) can now be gathered into a 16-bit result vector (i16/ui16). Each active lane reads one byte and produces a 16-bit lane by zero-extension — the upper 8 bits are zero-filled, regardless of whether the source is typed signed or unsigned. This lets quantized / byte-tensor gather workloads run directly without a separate widening pass.
16-bit gather with 16-bit offsets (the B16 path) 16-bit results indexed by ui16 offsets under a b16 mask are now a first-class path, alongside the existing 32-bit / i32-offset / b32 path. Same-width 16-bit gathers (ui16/i16/f16/bf16 source → matching result) and the 8→16 promotion above both use it.
Multi-chunk gather up to 4 physical registers vmi.vgather now handles logical vectors spanning multiple physical vector registers — up to the ISA limit of 4 physical registers per instruction. For 16-bit results this means up to 512 lanes; for 32-bit results up to 256 lanes. The earlier restriction that limited 16-bit gather to a single physical register has been removed.
Redundant select elimination under a statically all-active mask When the governing mask is statically all-active (e.g. a create_mask covering the full lane count, or an all-true constant mask), the gather no longer emits the trailing select/blend on inactive lanes — it returns the bare gathered result. Non-static or partial masks still take the masked path as before.
Originated from: #1210