Skip to content

-C lto -O does not enable LLVM optimizations for the LTO passes #22525

New issue

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

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

Already on GitHub? # to your account

Closed
rprichard opened this issue Feb 19, 2015 · 2 comments · Fixed by #22530
Closed

-C lto -O does not enable LLVM optimizations for the LTO passes #22525

rprichard opened this issue Feb 19, 2015 · 2 comments · Fixed by #22530
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@rprichard
Copy link
Contributor

-O seems to function like an alias for -C opt-level=2, but -O does not enable certain LTO LLVM optimizations (inlining?), whereas -C opt-level=2 does. This seems like a mistake.

The problem is this code in librustc_trans/back/lto.rs:

    let opt = sess.opts.cg.opt_level.unwrap_or(0) as libc::c_uint;

    let builder = llvm::LLVMPassManagerBuilderCreate();
    llvm::LLVMPassManagerBuilderSetOptLevel(builder, opt);
    llvm::LLVMPassManagerBuilderPopulateLTOPassManager(builder, pm,
        /* Internalize = */ False,
        /* RunInliner = */ True);
    llvm::LLVMPassManagerBuilderDispose(builder);

sess.opts.cg.opt_level is the -C opt-level setting, which is None with -O.

test.rs:

pub fn test() {}

output:

$ rustc test.rs --crate-type staticlib --emit llvm-ir -C lto -O
$ ls -l test.ll
-rw-rw-r-- 1 rprichard rprichard 36920440 Feb 19 00:25 test.ll
$ rustc test.rs --crate-type staticlib --emit llvm-ir -C lto -C opt-level=2
$ ls -l test.ll 
-rw-rw-r-- 1 rprichard rprichard 1312070 Feb 19 00:25 test.ll

I think we should base the LLVM optimization level on sess.opts.optimize. (Maybe it ought to use write::get_llvm_opt_level?)

@dotdash
Copy link
Contributor

dotdash commented Feb 19, 2015

Nice find! Probably not noticed by many because those using -C lto also go straight to -C opt-level=3 as well. Do you want to make a PR to fix this?

@dotdash dotdash added I-slow Issue: Problems and improvements with respect to performance of generated code. A-optimization labels Feb 19, 2015
@rprichard
Copy link
Contributor Author

I'd be happy to make a PR, though I probably won't get to it until tomorrow.

rprichard added a commit to rprichard/rust that referenced this issue Feb 19, 2015
Manishearth added a commit to Manishearth/rust that referenced this issue Feb 19, 2015
 Fixes rust-lang#22525

I wasn't sure if I should reuse `write::get_llvm_opt_level` or not.  It returns an `llvm::CodeGenOptLevel`, which is the Rust binding for `CodeGenOpt::Level`. `lto.rs` is passing an optlevel to LLVM's `PassManagerBuilder`, which takes an unsigned int.  `PassManagerBuilder`'s optlevel uses essentially the same enumeration (i.e. 0-3 with 2 as default), but it's implicit.
bors added a commit that referenced this issue Feb 24, 2015
Fixes #22525

I wasn't sure if I should reuse `write::get_llvm_opt_level` or not.  It returns an `llvm::CodeGenOptLevel`, which is the Rust binding for `CodeGenOpt::Level`. `lto.rs` is passing an optlevel to LLVM's `PassManagerBuilder`, which takes an unsigned int.  `PassManagerBuilder`'s optlevel uses essentially the same enumeration (i.e. 0-3 with 2 as default), but it's implicit.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants