--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.

[brson]

This still seems to be the case, but hasn't been motivation to fix.

[eddyb]

This bothers me every time someone accidentally does it, but I didn't even know this issue was open.

[nikomatsakis]

I still think we ought to change it. =)

[bombless]

Maybe we can force people to choose between --enable-optimize and --disable-optimize when --enable-debug is on.
That way you can never misunderstand the role of --enable-debug.

Like, when ./configure --enable-debug we trigger an error: Neither --disable-optimize nor --enable-optimize is specified, exiting

Edit: I forgot we already switched to rustbuild, but you get what I mean

[eddyb]

@bombless I'm still waiting for someone to come up with an usecase for an unoptimized compiler.

[bombless]

@eddyb I thought you are the one who may find some clues.
Doesn't it help you to decide a tricky behaviour of a compile result is caused by LLVM or rustc? I have no idea.

[nikomatsakis]

@bombless in theory yes, in practice I've yet to have such a bug (well, I did have one once, actually, but I didn't find it by turning off optimizations); in general an unopt compiler is just too slow to use.

[steveklabnik]

Isn't this fixed by config.toml? that is, these are all separate options now.

[eddyb]

@steveklabnik ./configure still exists and rustbuild reads config.mk.

[pnkfelix]

@steveklabnik also, regardless of the existence of ./configure, the code for building the bootstrap config from the config.toml still ties them together; see here:

rust/src/bootstrap/config.rs

Lines 527 to 528 in c97b60f

	if let Some(ref rust) = toml.rust {
	debug = rust.debug;

rust/src/bootstrap/config.rs

Lines 629 to 633 in c97b60f

	let default = debug == Some(true);
	config.debug_jemalloc = debug_jemalloc.unwrap_or(default);
	config.rust_debuginfo = debuginfo.unwrap_or(default);
	config.rust_debug_assertions = debug_assertions.unwrap_or(default);
	config.rust_optimize = optimize.unwrap_or(!default);

note in particular that bit about how the default is established by the presence of the debug setting, and then that affects the default value for optimize if it hasn't been explicitly established in the config.toml.

My proposal is that we stop having the default optimize here (solely for rustc bootstrap builds) be affected by the setting for debug above it. (And update the docs/messages elsewhere in e.g. configure accordingly)

[pnkfelix]

Note also that the doc comment for optimize doesn't mention the influence of debug on its value. It gives this dire warning about having optimize set to false, but the implication of the doc comment is that its always defaulting to true:

rust/config.toml.example

Lines 253 to 257 in c97b60f

	# Whether or not to optimize the compiler and standard library
	# Note: the slowness of the non optimized compiler compiling itself usually
	# outweighs the time gains in not doing optimizations, therefore a
	# full bootstrap takes much more time with optimize set to false.
	#optimize = true