[llvm] [MC] Allocate MCFragment with a bump allocator (PR #96402)

[Nikita Popov via llvm-commits]

nikic wrote:

> This increase likely stems from LTO optimizations allocating objects on the heap that overlap significantly with newly created MCDataFragment instances. The bump allocator eliminates this overlap and increases max-rss. This can be mitigated if we can identify the heap objects and switch the optimization pass(es) to bump allocators.

So you're saying that there is no increase in memory usage per se, and the max-rss increase is because the allocator cannot reuse already mapped memory (e.g. because it is reserved for smaller type classes, or whatever)? Have you verified that this is the case with massif?

Note that the max-rss increase is not limited to LTO only, it is also seen at `-O0`, to a lesser degree. Backend memory usage increases are just always easiest to see in the LTO configuration, as backend tends to dominate max-rss there.

> This bump allocator change opens doors for further performance (e.g. more elegant -disable-free for fragments) and max-rss improvement, so I want to keep it despite the ReleaseLTO max-rss regression...

I think this regression may be too large to keep it for speculative future gains. LTO memory usage is a pretty big problem, and the increase here is not small.

Regarding `-disable-free`, that would not work for frontends that codegen on multiple threads, right? Including rustc and lld with ThinLTO. If so, I'm not sure this is a useful optimization.

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