deeply-nested benchmark is troublesome for LLVM

[tmiasko]

The deeply-nested benchmarks have at various times in the past exposed a performance bug in LLVM. Depending on inlining decisions and unit partitioning the compilation might require a few orders of magnitude more time to complete than usual:

• always try inlining functions which do not call other functions rust#77307 (comment)
• Add unreachable propagation mir optimization pass rust#66329 (comment)
• [do not merge] Try turning on MIR inliner by default rust#68213 (comment)
• deeply-nested chain hangs with Item = u32 rust#70749

Consider changing the benchmark to avoid the issue (e.g., use a single codegen unit) or removing the benchmark altogether.

[Mark-Simulacrum]

This seems like precisely the reason to not change the benchmark - we don't want user code to hit this. If there's an LLVM bug we should fix that directly.

[tmiasko]

This seems like precisely the reason to not change the benchmark - we don't want user code to hit this. If there's an LLVM bug we should fix that directly.

Right, bug impacts users right now and should be fixed (see other examples in linked thread that expose it right now).

Exposing it in this benchmark is a matter of simplifying the IR enough to change inlining decision in LLVM (while keeping empty and chain in separate codegen unit). It isn't indicative whether problem is present in general or not, so keeping it as is is mostly a source of trouble with little benefits, especially that benchmarks is completely artifical (chaining empty iterators of ZSTs).