--enable-debug seems to imply --disable-optimize

[SimonSapin]

I build rustc from source with --enable-debug to get output from RUST_LOG to chase down an ICE, and the resulting compiler is about 25 times slower than Nigthly on the same commit. (Servo’s script crate takes ~50 minutes instead of ~2 to trigger the same ICE, #24687.)

@huonw said on IRC:

I recall there was a bug that made enable-debug imply disable-optimise

… which would explain the slowdown, but I didn’t find an issue filed for it, so here it is.

This may be a Makefile issue: #8058.

[dotdash]

See #24416 and #24405. The latter is specifically about optimizations and supposed to be fixed by #24408. Is this still a problem (again) or are you building an older version of the compiler?

[bombless]

Oh you can explain it in different ways, see #24405

[bombless]

--enable-debug --enbale-optimize should be good enough btw

[SimonSapin]

I’m building 0d8309e 2015-04-25.

I believe #24416 (which I had found) is not related but #24405 kind of is.

I can try --enable-debug --enable-optimize as #24405 suggests, but since ./configure --help lists --disable-optimize and not --enable-optimize I was lead to believe that enabling optimizations was the default. Is it not? Or is is tied to --enable-debug? If so, why?

[pnkfelix]

@SimonSapin i think this may be "by design", according to discussion on #24205 and #17665. Although then again it is not clear that there was consensus on #17665 that --enable-debug should imply --disable-optimize (though my reading of the comments there that at least some of the participants were in favor of it having that effect).

The intention, as I understand it, is that if you do --enable-debug, then you want an "ideal" environment for debugging, which for some people implies "do not let LLVM optimizations get in the way of my debugging experience."

The problem with this reasoning is that bootstrapping rustc takes an absurdly long time with --disable-optimize. So in practice I do not see how one could realistically actually use --enable-debug without also including --enable-optimize to override what it is doing today.

(At this point I essentially always call configure via a driver script that passes explicit switches based on local filesystem context.)

---

Anyway, I would not object if we went back and again decoupled the --enable/disable-optimize configure setting from the --enable/disable-debug configure setting.

(The argument for why --enable-debug "should" imply --disable-optimize, as noted in the relevant weekly meeting, was that 2-3 flags for configure the build is too many, and therefore we wanted to identify two "modes": release mode and developer mode, and then choosing your mode via configure would yield the "ideal" experience for that mode. This all sounds fine, but I clearly take issue with the claim that --disable-optimize is part of anyone's ideal developer mode.)

[SimonSapin]

I can imagine the logic behind this, but in practice this is far from ideal.

It’s only one data point, but here is how my thought process and experience went:

• I hit an ICE and I don’t know the exact cause
• Asking on IRC, I’m recommended to retry with RUST_LOG=syntax::codemap
• There is no log output. I assume logging is disabled on my Rust build
• I decide to try making another build where they’re enabled.
• I look at ./configure --help. --enable-debug seems relevant, it probably enables logging.
• I note that --disable-optimize is listed as an option, but --enable-optimize is not. I assume this means my build will be optimized. This is what I want.
• The build is taking a while. I know Rust takes a long time to bootstrap and all, but this seems longer than usual. I go do something else.
• The build ended up taking just over 4 hours.
• I start building Servo with this new rustc. Cargo somehow decide to rebuild everything, even though I was careful to pick the same Rust commit. This takes another 2 hours, instead of the usual ~8 minutes.
• Every rebuild of just Servo’s script crate (where the ICE is triggered) now takes over 50 minutes instead of ~2.

[pnkfelix]

Reopening: while documentation helps, I still think we should address the root problem here.

See: https://internals.rust-lang.org/t/why-is-enable-debug-implying-disable-optimize-for-rustc/1978

(And maybe I'll just put up a PR changing the configure script to make it stop doing this.)

[nikomatsakis]

I agree with @pnkfelix and @SimonSapin that in practice you do not want to disable optimizations, and we should not do so without an explicit --disable-optimize. This is extra true now that the debuginfo includes inlined functions fairly reliably even in optimized builds (at least on linux): getting a complete backtrace was the only reason I ever resorted to disable-optimize in the past, and it was always painfully slow.