Long and memory-wasting debug symbols generation

[speshuric]

Steps to reproduce

1. Save attached main.cpp.txt as cpp file (it is small - 1.7 KB, <100LOC)
2. Compile it with debug information and O2/O3 optimizations. I use: clang++ main.cpp -g -O2
3. Uncomment lines one by one and compile again

Expected

Compile is almost instant.

Actually

Compile time grows twice with every uncommented line. Memory usage exceeds 20GB with uncommented line with f24

Last uncommented line	Compile time on my PC, seconds
f16	0.945
f17	1.627
f18	3.170
f19	6.121
f20	12.355
f21	25.471
f22	51.952
f23	1:46.11

Environment

$clang++ --version
clang version 19.1.7
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$uname -a
Linux 6.14.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 09 May 2025 17:36:18 +0000 x86_64 GNU/Linux

Despite I use clang installed as package from archlinux repos, the same issue observed on godbolt site with various clang versions and targets.

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Alexander Speshilov (speshuric)

### Steps to reproduce 1. Save attached [main.cpp.txt](https://github.com/user-attachments/files/20214729/main.cpp.txt) as cpp file 2. Compile it with debug information and O2/O3 optimizations. I use: `clang++ main.cpp -g -O2` 3. Uncomment lines one by one and compile again

Expected

Compile time is almost instantly.

Actually

Compile time grows twice with every uncommented line. Memory usage exceeds 20GB with uncommented line with f24

Last uncommented line	Compile time on my PC, seconds
f16	0.945
f17	1.627
f18	3.170
f19	6.121
f20	12.355
f21	25.471
f22	51.952
f23	1:46.11

Environment

$clang++ --version
clang version 19.1.7
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$uname -a
Linux 6.14.6-arch1-1 #<!-- -->1 SMP PREEMPT_DYNAMIC Fri, 09 May 2025 17:36:18 +0000 x86_64 GNU/Linux

Despite I use clang installed as package from archlinux repos, the same issue observed on godbolt site with various clang versions and targets.

[speshuric]

main.cpp

#include <iostream>
using namespace std;
typedef signed long long ll;

// NOTE: this f is executed 2^N times
void f00(ll &i) { i++; }

// we need to go deeper!
void f01(ll &i) { f00(i); f00(i); }
void f02(ll &i) { f01(i); f01(i); }
void f03(ll &i) { f02(i); f02(i); }
void f04(ll &i) { f03(i); f03(i); }
void f05(ll &i) { f04(i); f04(i); }
void f06(ll &i) { f05(i); f05(i); }
void f07(ll &i) { f06(i); f06(i); }
void f08(ll &i) { f07(i); f07(i); }
void f09(ll &i) { f08(i); f08(i); }
void f10(ll &i) { f09(i); f09(i); }

// deeper
void f11(ll &i) { f10(i); f10(i); }
void f12(ll &i) { f11(i); f11(i); }
void f13(ll &i) { f12(i); f12(i); }
void f14(ll &i) { f13(i); f13(i); }
void f15(ll &i) { f14(i); f14(i); }
void f16(ll &i) { f15(i); f15(i); }
//void f17(ll &i) { f16(i); f16(i); }
//void f18(ll &i) { f17(i); f17(i); }
//void f19(ll &i) { f18(i); f18(i); }
//void f20(ll &i) { f19(i); f19(i); }

// ... and deeper
//void f21(ll &i) { f20(i); f20(i); }
//void f22(ll &i) { f21(i); f21(i); }
//void f23(ll &i) { f22(i); f22(i); }
//void f24(ll &i) { f23(i); f23(i); }
//void f25(ll &i) { f24(i); f24(i); }
//void f26(ll &i) { f25(i); f25(i); }
//void f27(ll &i) { f26(i); f26(i); }
//void f28(ll &i) { f27(i); f27(i); }
//void f29(ll &i) { f28(i); f28(i); }
//void f30(ll &i) { f29(i); f29(i); }

// ... oh... no....
//void f31(ll &i) { f30(i); f30(i); }
//void f32(ll &i) { f31(i); f31(i); }
//void f33(ll &i) { f32(i); f32(i); }
//void f34(ll &i) { f33(i); f33(i); }
//void f35(ll &i) { f34(i); f34(i); }
//void f36(ll &i) { f35(i); f35(i); }
//void f37(ll &i) { f36(i); f36(i); }
//void f38(ll &i) { f37(i); f37(i); }
//void f39(ll &i) { f38(i); f38(i); }
//void f40(ll &i) { f39(i); f39(i); }

int main()
{
    ll i = 0LL;
    f00(i);
    cout << i << endl;
    return 0;
}

[dwblaikie]

@jmorse seems to be debug location tracking issue - gmlt (so inline stack frames, etc) takes about the same time as -g0 (~8 seconds if you uncomment the rest of the deeper code block) - with -g it goes up to 6 minutes, and the flame graph has 29% of the time in AssignmentTrackingAnalysis, 15% in visitDbgRecords, 8% in EmitDbgValue, etc.

[jmorse]

Thank you for the test reproducer! The test puts its finger on a particular limitation of variable location tracking -- we never delete variable-assignment information (except for DCE). LLVMs inlining is able to constant-fold everything in the increment-function back into a single instruction, all the way up and down the inlining chain, so there's never any reason to not inline. However, if we inline up to a depth of 20, that means there are 2^20 #dbg_value variable assignment records for the i parameter to f00, hence we rapidly run out of memory.

Arguably this doesn't happen in "real" code, with this example being exceptional in stimulating a limitation in LLVM as inlining breadth isn't typically exponential (IMO). If any extra instruction were preserved in f00, inlining would quickly hit a size limit and wouldn't don't generate 2^n variable assignment records. I think the cost is still felt in different ways though, it's common for C++ to use accessor methods for fetching values that get inlined a few hundred times into one function, generating hundreds of #dbg_values for "this" pointers that'll never be meaningful.

The natural thing to do is drop variable-location information for an inlined-function when there are no instructions left in that inlined scope. However we don't store information about inlined scopes for ready recall, and would have to recompute it during a pass like removeRedundantDebugValues, which risks slowing everything else down -- on the compile time tracker I think tramp3d would benefit as it heavily inlines, but everything else might regress.

This might be easier with @SLTozer 's revamp of source locations as we'll bring some source-location-information into Function objects.