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

[Orlando Cazalet-Hyams via llvm-commits]

OCHyams wrote:

Thanks for the speedy review.

> 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").

Jeremy pointed me to your blog post before I took over this patch :) 

> If this is a bug, it could be challenging to diagnose (see `getBackend().relaxLEB128(LF, Value)`), and any future enhancements would likely need to modify this new (redundant in feature) fragment.
> 
> ```c++
>   // 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);
> ```

It seemed to work for simple test cases, but I can see how easily it could be buggy and how difficult that would be to identify.

> @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](https://maskray.me/blog/2024-06-30-integrated-assembler-improvements-in-llvm-19) 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?
> 
> To make `MCLEBFragment` smaller, we can remove the `Fixups` member variable and move `IsSigned` to MCFragment.

I suppose one point in favour of this patch is that it reduces instructions:u slightly too. That said, I'm more than happy to trust your judgement in this area - thanks for putting up the alternative patch. It looks like yours reduces max-rss further too.


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