r194403 - Using an invalid -O falls back on -O3 instead of an error

Chandler Carruth chandlerc at google.com
Mon Nov 11 13:06:16 PST 2013


On Mon, Nov 11, 2013 at 12:31 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> > I think assuming that these optimizations are ordered in some way
> > based on "fast" is wrong. For *many* C++ codebases -O2 produces
> > consistently higher quality code than -O3.
>
> What does *many* mean? Even a small percentage of the total can be a lot
> in absolute magnitude. -O3 should produce faster code than -O2, on average,
> and if that is not true, then we have a serious problem (and the test suite
> should do more -O2 testing).
>

-O3 will trade off code size in the hope of getting more performance.
Applications where that tradeoff doesn't pay off don't benefit from it.
Typically, more loop-heavy or numerics heavy applications tend to benefit.
More generic, or "application"-y code tends to run better with -O2.


>
> Also, this might depend on the platform. Embedded cores might benefit much
> more from -O3 than fancy out-of-order desktop chips.
>

Yes, I would expect embedded cores to benefit more, and the code workloads
run on those cores to also benefit more. Fast out-of-order chips (desktop
or phone or tablet) tend to like small code more, and tend to perform
better at -O2.


>
> Can you please explain further?


Sorry if I'm still being vague. It's vague. This is based on my experience
both benchmarking lots of my own software (personal and at work) and based
on listening to lots of others doing the same. I think this is somewhat OK
because we're just trying to pick a "default" or a "fallback". I just don't
think -O3 is the most sensible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131111/b5467da0/attachment.html>


More information about the cfe-commits mailing list