[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

[via lldb-commits]

================
@@ -374,25 +377,40 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
   m_fallback.GetFullyQualifiedType(context, callback);
 }
 
+bool DebugNamesDWARFIndex::SameAsEntryATName(
+    llvm::StringRef query_name, const DebugNames::Entry &entry) const {
+  auto maybe_dieoffset = entry.getDIEUnitOffset();
+  if (!maybe_dieoffset)
+    return false;
+
+  // [Optimization] instead of parsing the entry from dwo file, we simply
+  // check if the query_name can point to an entry of the same DIE offset.
+  // This greatly reduced number of dwo file parsed and thus improved the
+  // performance.
+  for (const DebugNames::Entry &query_entry :
+       entry.getNameIndex()->equal_range(query_name)) {
+    auto query_dieoffset = query_entry.getDIEUnitOffset();
+    if (!query_dieoffset)
+      continue;
+
+    if (*query_dieoffset == *maybe_dieoffset) {
+      return true;
+    } else if (*query_dieoffset > *maybe_dieoffset) {
+      // The pool entries of the same name are sequentially cluttered together
+      // so if the query name from `query_name` is after the target entry, this
+      // is definitely not the correct one, we can stop searching.
----------------
jeffreytan81 wrote:

@labath, let me see if I can explain well:

The purpose of `SameAsEntryATName(query_name, entry)` is to check whether the `pool entry` has the name `query_name`. 

Name table encodes data like this:
```
<name_table_entry for "query_name"> --> <consecutive_list_of_pool_entry>
```

In the name table, the `SameAsEntryATName(query_name, entry)` function in this PR attempts to verify if the `entry` is within a list of `<consecutive_list_of_pool_entry>` above.

The "incorrectly implemented check" in this PR tries to bail out early by checking whether the first `Entry Offset` pointed to by `<name_table_entry for "query_name">` is greater than or equal to the `entry`'s offset in the "Entry Pool". If this condition is met, it indicates that the `entry` is located before the `<consecutive_list_of_pool_entry>` in the "Entry Pool", meaning it cannot be part of the `<consecutive_list_of_pool_entry>` we are searching for. Consequently, the code can bail out early without iterating through the `<consecutive_list_of_pool_entry>` to check for a match.

Per testing, this early bail out does not affect much performance (I guess because `<consecutive_list_of_pool_entry>` is small for most `query_name`), so it is not an important optimization. For split dwarf, avoid touching dwo files is the key performance mover in this PR.


https://github.com/llvm/llvm-project/pull/108907