[llvm] [NFC][MC][Dwarf] Add Range/Location List Entry fragment to reduce memory usage (PR #146098)

[Fangrui Song via llvm-commits]

MaskRay wrote:

I understand your perspective, but I'm cautious about this change.
The current fragments (in the question: MCLEBFragment and MCDataFragment) use more memory than necessary. A custom fragment that combines two LEBs (DW_RLE_offset_pair) or two LEBs and one Data (DW_LLE_offset_pair) could be more space-efficient.

However, this would introduce delicate code dealing with neighbor fragments and linker-relaxation (I don't fully recall how the following code works, even though I authored most of the linker relaxation improvements in recent years; https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation search "label difference").
If this is a bug, it could be challenging to diagnose, and any future enhancements would likely need to modify this new (redundant in feature) fragment.

```cpp
  // Heuristic: if we can emit one of the offsets as a constant now, that
  // consumes less memory than creating a MCDwarfLocListOffsetPairFragment.
  bool BeginOrEndInBaseFragment = Base->getFragment() == Begin->getFragment() ||
                                  Base->getFragment() == End->getFragment();
  // If the offset ulebs require linker-relaxable relocations then fall back to
  // default uleb emission, rather than using MCDwarfLocListOffsetPairFragment.
  // FIXME: Is there a better way to check this?
  bool SameSection = &Base->getSection() == &End->getSection() &&
                     &End->getSection() == &Begin->getSection();
  bool MayBeLinkerRelaxable =
      Base->getSection().isLinkerRelaxable() || !SameSection;
  if (BeginOrEndInBaseFragment || MayBeLinkerRelaxable)
    return MCStreamer::emitDwarfLocListOffsetPairEntry(OffsetPair, Base, Begin,
                                                       End, EnumEle);
```

@aengelke has shared some ideas for improvement in this area but hasn’t had time to integrate them into LLVM. I’d prefer we explore general fragment content optimizations before introducing complex code like this. While I believe a custom fragment could offer greater efficiency than a generic fragment improvement, the latter might be sufficient to reduce the need for introducing a new fragment.

Your debug info improvements are valuable, but do they truly require such intricate assembler changes?


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