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