Enabling debug symbols negatively affects the optimiser

[swiftcoder]

I have a crate of moderate complexity, which I have recently been profiling.

When I enable debug = true in conjunction with opt-level = 3, and lto = true, I'm noticing a reduction in performance of the compiled code versus just opt-level = 3, and lto = true. The builds with debug info are exhibiting highly accurate debug symbols even for small functions which I would expect to have been inlined.

I'm curious whether this behaviour is by design, and if so, why we are in the opposite camp to C++ compilers, which in my experience prioritise optimisations over accuracy of debug symbols?

[jonas-schievink]

This might be because frame pointers are force-enabled when debug info is requested: #48785

[michaelwoerister]

That's the first time I've heard debuginfo of optimized builds being described as highly accurate :)
As @jonas-schievink mentions it might have to do with frame-pointer emission (which will soon be decoupled of debuginfo). Otherwise, this is mostly up to LLVM and I guess the situation is very similar to what clang does.

There is also debug = 1, which just generates line-tables and thus should have less of an impact on the optimizer.

[swiftcoder]

There is also debug = 1, which just generates line-tables and thus should have less of an impact on the optimizer.

Ah ha. That's good to know. The Cargo manifest documentation mentions in passing that the debug entry can takes the values 2, true, and false, but I didn't pull on that thread sufficiently to realise that 1 was also a valid value.

[HadrienG2]

Now that #48785 is closed, does this problem still occur?

[jonas-schievink]

Closing as fixed. Please let us know if this is still an issue.