================
@@ -1761,30 +1761,30 @@ Sema::DiagnoseAssignmentEnum(QualType DstType, QualType
SrcType,
return;
}
- typedef SmallVector<std::pair<llvm::APSInt, EnumConstantDecl *>, 64>
- EnumValsTy;
- EnumValsTy EnumVals;
-
- // Gather all enum values, set their type and sort them,
- // allowing easier comparison with rhs constant.
- for (auto *EDI : ED->enumerators()) {
- llvm::APSInt Val = EDI->getInitVal();
- AdjustAPSInt(Val, DstWidth, DstIsSigned);
- EnumVals.emplace_back(Val, EDI);
+ const EnumDecl *Key = ED->getCanonicalDecl();
+ auto [It, Inserted] = AssignEnumCache.try_emplace(Key);
+ auto &Values = It->second;
+
+ if (Inserted) {
+ Values.reserve(ED->enumerators().size());
+
+ for (auto *EC : ED->enumerators()) {
+ Values.push_back(EC->getInitVal());
+ AdjustAPSInt(Values.back(), DstWidth, DstIsSigned);
+ }
+
+ if (Values.empty())
+ return;
+
+ llvm::sort(Values);
+ Values.erase(llvm::unique(Values), Values.end());
----------------
erichkeane wrote:
Do you mean to insert-in-order? That ends up being fairly expensive, since
each insert is effectively a table-scan?
IMO, we can more or less count on the order in code to be:
1- Roughly sorted: MOST people do their enumerator-init values in order
2- Have few duplicates: Duplicate values tend to be used only for a vast
minority of enumerators (if more enumerations).
SO I would think the llvm::sort will be pretty darn close to O(1) most of the
time, and unique/erase about the same.
OR am I missing something obvious?
https://github.com/llvm/llvm-project/pull/176560
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits