[LLVMdev] [cfe-dev] Meaning of LLVM optimization levels

[David Tweed]

Hi, interesting idea.

I'll just note one thing at this point in the discussion: whether it's done by trying to "project what a transformation will do" or by applying transforms with the capability to roll-back, this depends on having a good idea of how a given piece of code (at some level) will actually perform on a piece of real hardware. Without that I suspect other aspects of the how to do optmizations won't work effectively anyway.

Cheers,
Dave
________________________________________
From: cfe-dev-bounces at cs.uiuc.edu [cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Renato Golin [renato.golin at linaro.org]
Sent: Thursday, June 06, 2013 9:40 PM
To: LLVM Dev; Clang Dev
Subject: [cfe-dev] Meaning of LLVM optimization levels

Folks,

I'm trying to rationalize about optimization levels and maybe we should come up with a document like this:

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Though, I remember a discussion a few months ago, and some people recommended we had names, rather than numbers, to dissociate the idea that 3 is better than 2. Regardless, would be good to have some guidelines on what goes where, so we don't end up in yet another long discussion about where to put the optimization <insert-name-here>.

As far as I can get from our side is:

-O3 : throw everything and hope it sticks
-O2 : optimized build, but should not explode in code size nor consume all resources while compiling
-O1 : optimized debug binaries, don't change the execution order but remove dead code and stuff
-O0 : don't touch it
-Os : optimize, but don't run passes that could blow up code. Try to be a bit more drastic when removing code. When in doubt, prefer small, not fast code.
-Oz : only perform optimizations that reduce code size. Don't even try to run things that could potentially increase code size.

I've been thinking about this, and I think, regarding those criteria, it would make sense to use a try/compare/rollback approach to some passes, at least the most dramatic ones.

For instance, the vectorizer keeps the old loops hanging, and under Os/Oz, it should be possible to rollback the pass if the end result is bigger. Of course, IR size has little to do with final code size, but that's why we have (and rely so much on) heuristics.

AFAIK, for that to work on any pass as they are, we'd have to implement a transactional model on IRBuilder, which is not trivial, but could be done. Does anyone have a strong opinion about this?

cheers,
--renato

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.