[cfe-dev] [LLVMdev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang

[Chandler Carruth]

On Mon, Jan 14, 2013 at 10:34 AM, <dag at cray.com> wrote:

> Chandler Carruth <chandlerc at gmail.com> writes:
> > 5) Optimize to the max or '-O3'
> > - Attribute: maxopt (new attribute)
> > - Goal: produce the fastest binary possible.
>
> > This level should always produce binaries at least as fast as opt, but
> > they might be faster at the cost of them being larger and taking more
> > time to compile.
>
> That's almost impossible to achieve if you include things like
> vectorization.  It is often difficult to know statically whether
> vectorization will help or harm.  One can do runtime code selection but
> that has its own costs and can be slower than O2 in some cases.
>
> I simply don't think it's a useful or achieveable guarantee.  It's a
> good goal but I would be against making it a reuiqrement as it will
> severely limit what we do at O3 over O2.
>

Note that this isn't a guarantee or a requirement, but a goal. That said,
we should push hard to achieve that goal, including turning off
optimizations until we get them *right* if absolutely necessary.

I specifically agree with you that this makes vectorization really hard to
get right. I think that is because vectorization is really hard to get
right! ;] Unless passes and optimizations can be set up to speed up code at
least as much (and hopefully more... ;]) than they slow down code, I don't
think they should be on by default.

None of this precludes researching new optimization passes, trying
different things, or exposing flags for users with deeply domain specific
needs to turn on domain targeted optimization strategies (quite aside from
any optimization level). This is just about creating reasonable
expectations for the default collections.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130114/8ea0e864/attachment.html>