Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conditionally enable debug! with --cfg debug #7822

Closed
wants to merge 4 commits into from

Conversation

huonw
Copy link
Member

@huonw huonw commented Jul 16, 2013

As per @pcwalton's request, debug!(..) is only activated when the debug cfg is set; that is, for RUST_LOG=some_module=4 ./some_program to work, it needs to be compiled with rustc --cfg debug some_program.rs. (Although, there is the sneaky __debug!(..) macro that is always active, if you really need it.)

It functions by making debug! expand to if false { __debug!(..) } (expanding to an if like this is required to make sure debug! statements are typechecked and to avoid unused variable warnings), and adjusting trans to skip the pointless branches in if true ... and if false ....

The conditional expansion change also required moving the inject-std-macros step into a new pass, and makes it actually insert them at the top of the crate; this means that the cfg stripping traverses over the macros and so filters out the unused ones.

This appears to takes an unoptimised build of librustc from 65s to 59s; and the full bootstrap from 18m41s to 18m26s on my computer (with general background use).

./configure --enable-debug will enable debug! statements in the bootstrap build.

…a noop based on cfg(debug).

Macros can be conditionally defined because stripping occurs before macro
expansion, but, the built-in macros were only added as part of the actual
expansion process and so couldn't be stripped to have definitions conditional
on cfg flags.

debug! is defined conditionally in terms of the debug config, expanding to
nothing unless the --cfg debug flag is passed (to be precise it expands to
`if false { normal_debug!(...) }` so that they are still type checked, and
to avoid unused variable lints).
@pcwalton
Copy link
Contributor

I'll discuss this in the meeting today to make sure the team is OK with this. Thanks!

@huonw
Copy link
Member Author

huonw commented Jul 16, 2013

(This is currently broken, fixing it now.)

@pcwalton ok. FWIW, I think @alexcrichton's experimentation may've indicated a bigger performance gain, so my measurements are possibly skewed by my background use. (I guess we could get a definitive answer if @cmr's bencher stopped being unroutable.)

@alexcrichton
Copy link
Member

My "measurements" should barely be considered that. I just ad-hocly ran time ./bin/rustc ./src/librustc/rustc.rs without much consideration of what was in the background. I was very surprised by my results, and I have a feeling that yours are much more accurate! Or perhaps we could average them and go with that...

@emberian
Copy link
Member

Doing this for all of the logging statements would be nice. Like, --max-log-level=error would be the default.

@emberian emberian closed this Jul 16, 2013
@emberian
Copy link
Member

(Not that info/warn/error are really used...)

@emberian emberian reopened this Jul 16, 2013
The entire testsuite is converted to using info! rather than debug!
because some depend on the code within the debug! being trans'd.
…ectly.

An alloca in an unreachable block would shortcircuit with Undef, but with type
`Type`, rather than type `*Type` (i.e. a plain value, not a pointer) but it is
expected to return a pointer into the stack, leading to confusion and LLVM
asserts later.

Similarly, attaching the range metadata to a Load in an unreachable block
makes LLVM unhappy, since the Load returns Undef.

Fixes rust-lang#7344.
That is, the `b` branch in `if true { a } else { b }` will not be
trans'd, and that expression will be exactly the same as `a`. This
means that, for example, macros conditionally expanding to `if false
{ .. }` (like debug!) will not waste time in LLVM (or trans).
bors added a commit that referenced this pull request Jul 16, 2013
As per @pcwalton's request, `debug!(..)` is only activated when the `debug` cfg is set; that is, for `RUST_LOG=some_module=4 ./some_program` to work, it needs to be compiled with `rustc --cfg debug some_program.rs`. (Although, there is the sneaky `__debug!(..)` macro that is always active, if you *really* need it.)

It functions by making `debug!` expand to `if false { __debug!(..) }` (expanding to an `if` like this is required to make sure `debug!` statements are typechecked and to avoid unused variable warnings), and adjusting trans to skip the pointless branches in `if true ...` and `if false ...`.

The conditional expansion change also required moving the inject-std-macros step into a new pass, and makes it actually insert them at the top of the crate; this means that the cfg stripping traverses over the macros and so filters out the unused ones.

This appears to takes an unoptimised build of `librustc` from 65s to 59s; and the full bootstrap from 18m41s to 18m26s on my computer (with general background use).

`./configure --enable-debug` will enable `debug!` statements in the bootstrap build.
@bors bors closed this Jul 16, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Oct 21, 2021
`unnecessary_sort_by` checks if argument implements `Ord` trait

closes rust-lang#7822

changelog: [`unnecessary_sort_by`] now checks if argument implements `Ord` trait
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants