Support "Unroll" Loop Control via function-scoped #[spirv(unroll_loops)]
.
#337
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.
This required generalizing the zombie decoration system (see the first commit), because
OpLoopMerge
(where theUnroll
"Loop Control" has to be applied) are created during linking, by the structurizer, not in the original crate (which is the one understanding the mapping between SPIR-VOpFunctions
and Rustfn
s).It's not as nice as I would've hoped, but because of all the RAUW (Replace All Uses With) happening during linking, we can't just decode all of the decorations eagerly and keep them in e.g. a
HashMap
, as the IDs being decorated by them won't be replaced by RAUW.So instead of centralizing such
rustc_codegen_spirv
decorations into a singleenum
andHashMap
, each type that implements theCustomDecoration
trait
has to be independently decoded and removed from the SPIR-V module.