[llvm] [DebugInfo] Emit skeleton to avoid mismatching inlining flags (PR #153568)

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 17 10:08:48 PDT 2025


dwblaikie wrote:

> > Specifically, using split-dwarf-inlining with ThinLTO meant creating a lot of tiny CUs for all the imported CUs in each backend compile. This massively increases the number of CUs and causes storage and debugger scalability issues.
> 
> I see that [e731a26](https://github.com/llvm/llvm-project/commit/e731a2678c7cf81b1d3817489a52b519cb14f85e) seems to have handled this to avoid creating a lot of tiny CUs for all the imported CUs in each backend compile in this scenario.
> 
> ```c++
>   if (useSplitDwarf() &&
>       !shareAcrossDWOCUs() &&
>       (!DIUnit->getSplitDebugInlining() ||
>        DIUnit->getEmissionKind() == DICompileUnit::FullDebug) &&
>       !CUMap.empty()) {
>     return *CUMap.begin()->second;
>   }
> ```
> 
> Please correct me if I'm mistaken.

That sounds plausible/vaguely like my recollection from way-back when. Thanks for doing the archaeology here.

> > So, I guess a few questions, but maybe the simplest to start with: if this reverts the original patch, how does it not regress the original test case: `llvm/test/DebugInfo/X86/split-dwarf-omit-empty.ll` ? Is the functionality preserved through some other means now?
> 
> To be precise, this change isn't a simple revert. It enables correct handling of the case where a function from a CU with `splitDebugInlining=true` is inlined into a CU with `splitDebugInlining=false`.

Not sure I follow - looking at the text of the change it does look like a revert. Is there some difference in the code this patch is adding compared to the code that was removed back in the original?

It's probably fine that it's a straight revert - given the functionality of the original patch was fixed more broadly with the other patch you mentioned.

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


More information about the llvm-commits mailing list