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

Robinson, Paul Paul.Robinson at am.sony.com
Mon Jan 14 16:10:32 PST 2013


On Mon, Jan 14, 2013 at 2:58 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> On Mon, Jan 14, 2013 at 2:07 PM, Christopher Jefferson <chris at bubblescope.net> wrote:
> 
> > > 3) Optimize quickly or '-O1'
> > > 
> > > - Attribute: quickopt (this would be a new attribute)
> > > - Goal: Perform basic optimizations to improve both performance and simplicity of the code, but perform them *quickly*.
> > > This level is all about compile time, but in a holistic sense. It tries to perform basic optimizations to get reasonably efficient code, and get it very quickly.
> >
> > GCC tries to make -O1 be compatible with debugging. I find having debugging functional with some level of optimisation very useful, particularly in template heavy C++ code. I don't know if there is an optimisation level with similar behaviour in clang.
> I'm happy to have an added goal here of code that is reasonable to debug, but I think before we can have that we need to have at least *some* idea what that constitutes. Currently, I have no really good ideas....

I spent time in a previous job making -O1 more debuggable with our compiler.
It's a very broad topic with some subject elements but we came up with
a quick rule of thumb:
Optimize *within* each statement but not *across* statements.

So: optimize expressions within a statement (e.g. strength reduction)
but not common subexpressions in different statements.  Simple loop
optimizations are okay if they don't mess with single-stepping (no
conversion to bottom-tested loops). Be cautious about induction
variables.  No real instruction scheduling; all (or most) of the
instructions for a given statement are contiguous.
Variables have single homes at sequence points, with updated values.

You get the idea.
--paulr




More information about the llvm-dev mailing list