Customize Function
and BasicBlock
to carry both a SPIR-V ID and an index, for O(1) access.
#341
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.
As may be obvious from the first commit, I was hoping to remove the
RefCell
around therspirv::dr::Builder
.(it's still possible, but it would require keeping global and function builders separate, and using different ID ranges, and I almost jerry-rigged some contraption using
spirt::{Context,Type,Const}
but it'd be too much work to port everything over, not to mention new exciting failure modes)Instead, I ended up fixing a long-standing issue with how we expose SPIR-V functions and blocks to
rustc_codegen_ssa
- which is mostly straight-forward, as it already has associated types forFunction
andBasicBlock
, we were just using raw SPIR-V IDs (orSpirvValue
, in the case ofFunction
) for no good reason.After this PR, we're always tracking the
rspirv::dr::Builder
function/block indices, not just IDs (while still using IDs to validate that the index didn't go out of sync due to ad-hoc mutation etc.), so there shouldn't be any reason to iterate through functions (or through a function's blocks) searching for a specific ID.There were already some fast paths before, so this might not have much impact on perf, but I still like the result (if nothing else, it should be harder to misuse, and I even got to remove a silly
call
special-case).