[llvm] [LLVM[NFC] Refactor to allow debug_names entries to conatain DIE offset (PR #69399)

[David Blaikie via llvm-commits]

================
@@ -1246,6 +1246,14 @@ void DwarfDebug::finishSubprogramDefinitions() {
   }
 }
 
+void DwarfDebug::finalizeAccelerationTables() {
+  for (auto &Entry : AccelDebugNames.getEntries()) {
+    for (AccelTableData *Value : Entry.second.Values) {
+      static_cast<DWARF5AccelTableData *>(Value)->normalizeDIEToOffset();
+    }
+  }
+}
----------------
dwblaikie wrote:

Yeah, mixed feelings - I wouldn't mind this being a member function of `AccelTable` - and having some function on all entry data types - which can be a no-op on AppleNames entry types (though that'll be a bit subtle - it's only a valid no-op because the CU DIEs do persist long enough to be usable - but AppleNames will hopefully eventually go away, so that's got a path to removal, hopefully).

I did also realize that in the `DWARF5AccelTableStaticData` looks a lot like the new version of the `DWARF5AccelTableData` you're introducing here - so there might be a chance to merge these, especially once the packing/structure layout/size issue is addressed (by not using `std::variant` the struct could be shrunk down to the same size/basically the same layout (making the tag 16 bits, using the extra bits to encode the discriminator for the pointer V offset - and if it's just assertions that it's in the right mode, it won't make the static case any less efficient for this generality - and remove some complexity (eg: the DWARF5 name emission can be a non-template then))

If the DWARF5AccelTable*Data types become one data type, then I suppose this "finalize" operation could be a non-member function that takes a `AccelTable<DWARF5AccelTableData>` parameter which would be pretty simple/tidy.

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