[NFC] Remove assert from SPV Work Graphs#8599
Merged
Merged
Conversation
This replaces string matching of WG type names with using the proper NodeIOFlags. This avoids the compiler incorrectly treating a user-defined type as if it is the built-in type.
V-FEXrt
approved these changes
Jul 1, 2026
damyanp
approved these changes
Jul 1, 2026
llvm-beanz
changed the title
llvm-beanz
changed the title
damyanp
approved these changes
Jul 1, 2026
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.
I misunderstood how this was being used, and now that I understand, the assert makes no sense.
In the SPIRV representation defined in https://github.khronos.org/SPIRV-Registry/extensions/AMD/SPV_AMDX_shader_enqueue.html, as well as in DXIL, the record objects are always arrays. At the source level we differentiate single objects from arrays but the single object is just an array of one element.
For the single object case any function that takes an index defaults to for the index.
This is true in both SPIRV and DXIL. Checking if the type name ends in
sisn't a meaningful assert. The user either had a single element array, or a multi-element array, and they either didn't provide an index (so it defaults 0) or they did because they were required to at the AST level.Either way we don't need to check any of this in an assert in the codegen layer.