Add CodeGen options to optimize for size. by brandonedens · Pull Request #32386 · rust-lang/rust (original) (raw)

Excellent to hear of the conversation and it was a pleasure to chat the
other night.

Super excited about this infrastructure work but bear with me; just
switched over to Rust on armv8 rather than x86 and most of my free time for
these things is nights and weekends.

As I mentioned before it might be prudent to follow a strategy similar to
GCC and/or Clang. In those compilers the O? flags are meta flags that in
turn enable or disable a collection of optimizations and those
optimizations fluctuate based upon the target too.

So via GCC you can execute
gcc -Q -Os --help=optimizers
to get a listing of what optimizations will be enabled/disabled for Os.
as a side note:
gcc -Q --help=target
also presents interesting information.

So we have the following meta flags.
GCC:
O0, O1, O2, O3, Og, Ofast, Os
Og = compile with optimizations but maximum debugging capability
Ofast = disregard standard compliance
Os = optimize for size

Clang:
O0, O1, O2, O3, Ofast, Os, Oz, -O, -O4
Oz = optimize for size at the expense of everything else
O4 (and up currently just O3)

I'd probably switch opt-level to mirror the naming in GCC / Clang, a
string. I'd probably then begin to expose the underlying optimizations
being enabled as adjustable parameters and then encode those flags being
enabled / disabled using the meta options while also presenting the user a
method of inspecting what was actually enabled / disabled in a manner
similar to GCC.

Lately I've been integrating GCC output with other compilers and its really
important to know and control how the compiler is aligning the data, what
calling convention is being used, etc...

Can we gate this stuff on nightly only? I know you said it'd immediately be
stable but it'd be real nice if we could tuck it away until we know the
ergonomics are good.

Regardless, I'll try to build up something that looks more akin to Clang on
this branch; basically some functionality via Os and Oz.

Brandon
On Mar 24, 2016 09:30, "Alex Crichton" notifications@github.com wrote:

Ok, we discussed this at the tools triage meeting yesterday and here were
some of our thoughts:

• We think that having -C opt-size separate from -C opt-level may not
  actually be the course of action we wish to take. If you're optimizing for
  size, for example, you basically have to turn optimizations on to get
  inlining/constant propagation to eliminate huge swaths of otherwise dead
  code. In that sense -C opt-level=0 -C opt-size=2 doesn't actually make
  that much sense, so we may as well fold them into the same -C opt-level
  flag. This also mirrors what gcc/clang do, I believe?
• We probably want two optimization levels for size (as you've got
  here), and we just need to be sure to pick their names carefully as they'll
  be instantly stable.
• Do you have any numbers indicating what the impact of -C opt-size=2
  are? We were curious just to see, for example, the impact on the compiler
  or other various bits of code.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#32386 (comment)