================
@@ -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:
The difference between this patch and other users of MultiOnDiskHashTable is,
other users actually store an ID only (an integer). And they will use the ID to
load what they want later. How do you think about doing similar things for
HeaderSearch?
That may require some more typings and may introduce some overhead. I just want
to reduce the complexity of `MultipleDiskHashTable`.
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
