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

[rprichard]

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

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?

[rprichard]

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