-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[RISCV] Make All VType Parts Optional #144971
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
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Oops, something went wrong.
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.
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.
We should change the error message just like in #115277?
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.
I honestly thought that trying to make it clear which bits are optional and which aren't with sort-of regex syntax would be more confusing than the current message. We can certainly look at improving them in the future, but probably by entirely revisiting how error messages are generated.
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.
Make sense.
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.
Given that we're doing this for compatibility with binutils, does it even make sense to encourage the optional syntax?
It's going to be rarely useful to not specify sew.
Not specifying tail and mask policy gives undisturbed policy which is the worst for performance on out of order cores.
Not specifying LMUL is only useful in loops with a single element type. If you do any widening/narrowing, you still need to change vtype to a different lmul to do any other operations on the data other than load/store. Having no lmul only on some vsetvli in your loop seems like bad readability choice.
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.
If we want, I could look at immediately adding deprecation warnings when anything is left out?
That way it works correctly, but we also get to tell users we don't want to support the optional syntax indefinitely (presumably when another version of the spec is officially released/ratified, the fields will no longer be optional)
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.
What would be considered an official release? It's not listed as optional in the ISA manual from May 2025 here https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications#ISA-Specifications
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.
Yeah, sorry, that's maybe me speaking slightly inaccurately. It feels like this change needs some acknowledgement that it potentially breaks existing assembly rather than just updating examples. The change isn't really called out in the May 2025 release (but not many are), and the extension version isn't changed either, so it's really hard to tell if it was intended to break compatibility or not.
Anyway, I'm happy to add some kind of warning if we want to encourage users away from using the "everything is optional" form of these operands.
I think we did have consensus on the call that we should support the "everything is optional" form, so I implemented it.