On 17 October 2011 15:58, James Molloy <james.molloy at arm.com> wrote:> -Os doesn’t actually exist for llc, and I can’t see an obvious place where > that condition would be set. Where do we specify if we’re optimizing for > codesize or performance?The pass manager builder has an option for Os (0, 1, 2). But all it does, AFAICR, is to disable one explosive optimization pass. I'm not sure how that gets propagated into the DAG. Maybe every function in that module receives the attribute Richard mentions... Optimization for size hasn't been tested properly, at least not for ARM, and I hit all sorts of trouble (even before getting to DAG) when enabling it. -- cheers, --renato http://systemcall.org/
On Oct 18, 2011, at 7:37 AM, Renato Golin wrote:> On 17 October 2011 15:58, James Molloy <james.molloy at arm.com> wrote: >> -Os doesn’t actually exist for llc, and I can’t see an obvious place where >> that condition would be set. Where do we specify if we’re optimizing for >> codesize or performance? > > The pass manager builder has an option for Os (0, 1, 2). But all it > does, AFAICR, is to disable one explosive optimization pass.In clang/LLVM, -Os is not very different from -O2. It dials back inlining, and disables a few other optimizations. The idea is to reduce code size without sacrificing too much performance. The -Oz option is supposed to do the same as gcc's -Os: Minimize code size at any cost. This option is not supported by the code generator yet.> I'm not sure how that gets propagated into the DAG. Maybe every > function in that module receives the attribute Richard mentions...Exactly. This is so you can mix -Os and -O3 code in an LTO build.> Optimization for size hasn't been tested properly, at least not for > ARM, and I hit all sorts of trouble (even before getting to DAG) when > enabling it.Bugzilla or it didn't happen. /jakob
>> Optimization for size hasn't been tested properly, at least not for >> ARM, and I hit all sorts of trouble (even before getting to DAG) when >> enabling it. > > Bugzilla or it didn't happen.Optimization for size on ARM is more important than most other platforms. It is still very common for embedded ARM cores to have only 64 kb of Flash. A couple friends of mine were two of Atari's first seven video game coders. They had a choice of using 2 kb or 1 kb ROMs to store their executables in. While 2 kb ROMs allowed for much easier to write and more featureful games, they always strove to target the 1 kb ROMs because they cost half as much to manufacture and so the coders would earn twice as much in royalties. It happened all the time that a game's executable size would get down to just a few bytes over 1 kb. Despite their best efforts, the coders could never get their executable to 1 kb or less, because doing so would break the hard-coded timing loops. I understand that some coders would go insane as a result. -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quixote at dulcineatech.com