================
@@ -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>
----------------
ian-twilightcoder wrote:
Yeah we'd need `operator <` for `map`, and there isn't really a logical
implementation of that for triples so that's why I went with `unordered_map`.
Is there any advantage of `map`? As far as I can tell it has the same downsides
of `unordered_map` re allocations.
Maybe what would be best is a `SupportedTarget` struct that holds the triple
pieces we want plus the system prefix, and then we could store those in a
`SmallVector`. We could use that as the canonical platform representation, and
still support looking them up by target triple.
https://github.com/llvm/llvm-project/pull/171970
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
