[PATCH] D126883: [Debuginfo][DWARF][NFC] Refactor DwarfStringPoolEntryRef.

Alexey Lapshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 15 03:52:06 PDT 2022


avl added a comment.

In D126883#3583613 <https://reviews.llvm.org/D126883#3583613>, @JDevlieghere wrote:

> Ah that's a good point. Yep the DIEString approach looks good.

I would suggest to use solution from this patch instead of suggestion with DwarfStringPoolEntryRefImpl.

The drawbacks of suggestion with DwarfStringPoolEntryRefImpl:

1. It leads to extra memory usage and fragmentation since many additional objects would be allocated.
2. It requires to change many places where DwarfStringPoolEntryRef is currently used.



  class NonRelocatableStringpool {
    std::unique_ptr<DwarfStringPoolEntryRefImpl> getEntry(StringRef S);
  }
  
  class DIEString {
    std::unique_ptr<DwarfStringPoolEntryRefImpl> S;
  }
  
  class AccelTableBase {
  public:
    /// Represents a group of entries with identical name (and hence, hash value).
    struct HashData {
      std::unique_ptr<DwarfStringPoolEntryRefImpl> Name;
   }
  }
  ...



3. It introduces new performance penalties, because std::unique_ptr de-referencing and virtual function call would be added while accessing DwarfStringPoolEntryRef methods.

The solution from this patch does not introduce new memory allocations, It does not change usage points of DwarfStringPoolEntryRef, It adds only "MapEntry.is<ByValStringEntryPtr>" check while accessing DwarfStringPoolEntryRef methods.

What do you think?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126883/new/

https://reviews.llvm.org/D126883



More information about the llvm-commits mailing list