================
@@ -157,15 +163,34 @@ template<typename Info> class MultiOnDiskHashTable {
// FIXME: Don't rely on the OnDiskHashTable format here.
auto L = InfoObj.ReadKeyDataLength(LocalPtr);
const internal_key_type &Key = InfoObj.ReadKey(LocalPtr, L.first);
- data_type_builder ValueBuilder(Merged->Data[Key]);
- InfoObj.ReadDataInto(Key, LocalPtr + L.first, L.second,
- ValueBuilder);
+ if constexpr (UseExternalKey) {
+ if (auto EKey = InfoObj.TryGetExternalKey(Key)) {
+ data_type_builder ValueBuilder(NewMerged->Data[*EKey]);
+ InfoObj.ReadDataInto(Key, LocalPtr + L.first, L.second,
+ ValueBuilder);
+ }
+ } else {
+ data_type_builder ValueBuilder(NewMerged->Data[Key]);
+ InfoObj.ReadDataInto(Key, LocalPtr + L.first, L.second,
ValueBuilder);
+ }
}
- Merged->Files.push_back(ODT->File);
- delete ODT;
+ NewMerged->Files.push_back(ODT->File);
}
-
+ MergedTable *Merged = getMergedTable();
+ if (!Merged) {
+ Merged = NewMerged;
+ } else {
+ for (auto &[Key, Value] : NewMerged->Data) {
+ data_type_builder ValueBuilder(Merged->Data[Key]);
+ Info::MergeDataInto(Value, ValueBuilder);
+ }
+ Merged->Files.insert(Merged->Files.end(), NewMerged->Files.begin(),
+ NewMerged->Files.end());
+ delete NewMerged;
+ }
+ for (auto *T : tables())
+ delete T;
----------------
ChuanqiXu9 wrote:
It is a suggestion to avoid looking up in the MultiOnDiskHashTable recursively.
But it requires we add another layer like we did for decls. It may require much
more typings.
My concern for the patch is, it makes the logic of MultOnDiskHashTable more
complex. It is fundamental. If you still want your current solution, I feel
better to introduce some compile time polymorphism to leave the current
implementation unchanged.
https://github.com/llvm/llvm-project/pull/155350
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
