================
@@ -32,6 +32,9 @@ struct RangeInfo {
llvm::dxil::ResourceClass Class;
uint32_t Space;
llvm::dxbc::ShaderVisibility Visibility;
+
+ // The index retains its original position before being sorted by group.
+ size_t Index;
----------------
bogner wrote:
The simpler way to do an external mapping would be to use a vector along the
lines of
```c++
SmallVector<std::pair<RangeInfo, hlsl::RootSignatureElement *>> RangeMap;
```
You'd populate this in the loop in `handleRootSignatureElements`. Then you'd
need to define `operator==` and `operator<` on `RangeInfo`, sort this based on
the `.first` element, and then use `std::lower_bound` to do a binary search to
do the lookup. This uses more memory but avoids the need for details of the
algorithm in clang to leak into the RangeInfo type in LLVM. Some care might
need to be taken if two RangeInfos can be exactly identical - I'm not sure if
that's possible or not.
If we don't want to go that route and it seems more worth it to have storage on
the RangeInfo to keep the algorithm as is, we should probably name it something
like `Cookie` instead of `Index` and label it as generic storage for diagnostic
algorithms. This makes it a bit more generic but it still makes for a bit of a
code smell in how it breaks the abstraction.
https://github.com/llvm/llvm-project/pull/147115
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
