================
@@ -141,20 +143,55 @@ class DarwinSDKInfo {
llvm::DenseMap<VersionTuple, VersionTuple> Mapping;
};
+ // Special versions of hash and equal_to to map triples to system prefixes
+ // ignoring the Arch/SubArch.
+ struct TripleHash {
+ std::size_t operator()(const llvm::Triple &Val) const noexcept {
+ return hash_combine(Val.getVendor(), Val.getOS(), Val.getEnvironment(),
+ Val.getObjectFormat());
+ }
+ };
+ struct TripleEqualTo {
+ constexpr bool operator()(const llvm::Triple &LHS,
+ const llvm::Triple &RHS) const {
+ return (LHS.getVendor() == RHS.getVendor()) &&
+ (LHS.getOS() == RHS.getOS()) &&
+ (LHS.getEnvironment() == RHS.getEnvironment()) &&
+ (LHS.getObjectFormat() == RHS.getObjectFormat());
+ }
+ };
+
DarwinSDKInfo(
VersionTuple Version, VersionTuple MaximumDeploymentTarget,
- llvm::Triple::OSType OS,
+ llvm::Triple Triple,
+ std::unordered_map<llvm::Triple, std::string, TripleHash, TripleEqualTo>
----------------
cyndyishida wrote:
Yeah, what I'm saying is if the key becomes small, you don't need to worry
about that anymore.
I also think `std::map` would work fine here, and all you would need to define
is, if any, `operator <`, since the #of elements is always small & bounded,
there's likely not a noticeable perf difference between the two.
I don't think it's good to have something like `getTriple()` and have to know
that some of its data is cleared out. If you end up keeping `llvm::Triple`,
that should be an implementation detail/private to `DarwinSDKInfo` and public
APIs can be available for things that are reasonably queryable, e.g. `getOS()`
or `getVendor()`
https://github.com/llvm/llvm-project/pull/171970
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
