Discover better llvm optimizations for Rust

[brson]

Two observations:

• Running llvm optimizations is the greater part of rustc's time, so we should take care not to run ineffective optimizations.
• Rust code has its own unique character so what are good llvm defaults may not be the best Rust defaults

Let us find the ideal combination of passes that is both fast to compile and creates fast code. LLVM almost certainly has tools for this. Testing should be done with split stacks disabled.

[lomereiter]

You may be interested in this blogpost about using Acovea for finding near-optimal flags using genetic algorithm: http://donsbot.wordpress.com/2010/03/01/evolving-faster-haskell-programs-now-with-llvm/

[graydon]

Indeed. Though I'd suggest blocking this on the two major codegen changes: removing refcounting and landing pads.

[bstrie]

As of right now, there are still enough changes in the pipe that this would probably be premature.

[thestinger]

The reason the LLVM passes take so long is because we're generating really poor pre-optimization IR. For a simple swap function, we output 150+ lines of IR while clang only has 10-15 instructions at -O0.

I think we'll need to fix the major issues with our code generation before tackling this.

[Aatch]

For some real numbers as to our code gen quality. We spend ~20% of the LLVM passes on combining redundant instructions.

Now this might be just be a quirk of the pipeline, but it doesn't seem right to me...

[thestinger]

I redid the LLVM optimization passes to match the passes used in clang 3.3 and I don't think we can do any better because we don't have different needs or patterns than C++11. The reason our compilation is many times slower than clang's is because we generate 50-200x as much IR from our poor codegen.