Legalize A5 PIPE_V barriers before VPTO emission#916
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds checks to prevent unsupported A5 PIPE_V barriers from reaching the VPTO LLVM lowering stage, and schedules the LoweringSyncToPipe pass in the emission pipeline to legalize sync constructs. The reviewer suggested using assert or llvm_unreachable instead of op.emitError if the condition represents an invariant violation, or removing the "internal error" prefix if it is a user-facing error.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| if (isTargetArchA5(op.getOperation()) && | ||
| op.getPipe().getPipe() == PIPE::PIPE_V) { | ||
| op.emitError("internal error: A5 PIPE_V barrier should be erased before " | ||
| "VPTO LLVM lowering"); | ||
| return failure(); | ||
| } |
There was a problem hiding this comment.
In LLVM/MLIR, if a condition represents an invariant violation (i.e., an internal compiler error that should never be reached in a correct pipeline), it is more idiomatic to use assert or llvm_unreachable rather than op.emitError and returning failure(). This ensures that debug builds fail fast with a stack trace, making it much easier to debug.\n\nIf this condition can actually be triggered by invalid user input (e.g., if a user-provided program contains an unsupported barrier that cannot be legalized/erased), then op.emitError is appropriate, but the error message should be user-friendly and not prefixed with "internal error:".\n\nCould you clarify if this is a compiler invariant or a user-facing error, and update the handling accordingly?
assert(!(isTargetArchA5(op.getOperation()) &&\n op.getPipe().getPipe() == PIPE::PIPE_V) &&\n "A5 PIPE_V barrier should be erased before VPTO LLVM lowering");| if (isTargetArchA5(op.getOperation()) && | ||
| op.getPipe().getPipe() == PIPE::PIPE_V) { | ||
| op.emitError("internal error: A5 PIPE_V barrier should be erased before " | ||
| "VPTO LLVM lowering"); | ||
| return failure(); | ||
| } |
There was a problem hiding this comment.
In LLVM/MLIR, if a condition represents an invariant violation (i.e., an internal compiler error that should never be reached in a correct pipeline), it is more idiomatic to use assert or llvm_unreachable rather than op.emitError and returning failure(). This ensures that debug builds fail fast with a stack trace, making it much easier to debug.\n\nIf this condition can actually be triggered by invalid user input (e.g., if a user-provided program contains an unsupported barrier that cannot be legalized/erased), then op.emitError is appropriate, but the error message should be user-friendly and not prefixed with "internal error:".\n\nCould you clarify if this is a compiler invariant or a user-facing error, and update the handling accordingly?
assert(!(isTargetArchA5(op.getOperation()) &&\n op.getPipe().getPipe() == PIPE::PIPE_V) &&\n "A5 PIPE_V barrier should be erased before VPTO LLVM lowering");
Codex Review该评论由 review 机器人自动更新。
SummaryReview failed at stage Findings未生成结构化 findings，因为 review 过程提前失败。 Log Tail |
4 participants
No description provided.