================
@@ -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

Reply via email to