-
Notifications
You must be signed in to change notification settings - Fork 25
[water] fixes to wave.extract #791
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This operation normally appears after expansion, so after analyses and should not participate in them. We also don't exactly know how it would participate in them as it refers to a partially-lowered state reasoning about vectors. It shouldn't have identical tensor types before and after given its semantics, and such typing would contradict the Python equivalent. Also enforce vector-level invariants when the operation is in vector form. Signed-off-by: Alex Zinenko <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR refines the wave.extract operation to correctly represent its role as an internal lowering operation and enforce stricter type constraints.
Changes:
- Removed analysis-related traits from
wave.extractsince it appears post-expansion - Added verification to ensure result types are 1-dimensional tensors or 1-element vectors
- Updated operation description to clarify its internal/lowering nature
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| water/include/water/Dialect/Wave/IR/WaveOps.td | Removed analysis traits, updated description to clarify internal operation status, and added common arguments syntax |
| water/lib/Dialect/Wave/IR/WaveOps.cpp | Added comprehensive verification logic for element type matching, vector/tensor dimensionality, and source-result compatibility |
| water/test/Dialect/Wave/ops-invalid.mlir | Added test cases covering invalid position rank, vector size, tensor dimensionality, unspecified types, and dimension mismatches |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (!resultTensorType.getFullySpecified() || | ||
| resultTensorType.getRank() != 1) { |
Copilot
AI
Jan 30, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The error message at line 1660 does not distinguish between the two failure conditions (not fully specified vs. incorrect rank). Consider splitting this into two separate checks with distinct error messages to improve debugging clarity.
| if (!resultTensorType.getFullySpecified() || | |
| resultTensorType.getRank() != 1) { | |
| if (!resultTensorType.getFullySpecified()) { | |
| return emitOpError() | |
| << "result tensor type must be fully specified, got " | |
| << resultTensorType; | |
| } | |
| if (resultTensorType.getRank() != 1) { |
| Therefore, the result tensor is always indexed by one dimension. | ||
|
|
||
| TODO: we don't have a good way of verifying this, but the indexing symbol | ||
| symbol of the result must be the indexing symbol for which the size |
Copilot
AI
Jan 30, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The word 'symbol' is duplicated on line 306. It should appear only once.
| symbol of the result must be the indexing symbol for which the size | |
| of the result must be the indexing symbol for which the size |
This is needed for lowering after all Signed-off-by: Alex Zinenko <[email protected]>
Signed-off-by: Alex Zinenko <[email protected]>
tgymnich
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This operation normally appears after expansion, so after analyses and should not participate in them. We also don't exactly know how it would participate in them as it refers to a partially-lowered state reasoning about vectors.
It shouldn't have identical tensor types before and after given its semantics, and such typing would contradict the Python equivalent.
Also enforce vector-level invariants when the operation is in vector form.