-Os

Mips 16 is basically to save space.

I want to start comparing real benchmarks with llvm and gcc -mips16.

Does -Os have any meaning currently to clang? llvm?

What about inlining? Is inlining turned off?

Tia.

Reed

Mips 16 is basically to save space.

I want to start comparing real benchmarks with llvm and gcc -mips16.

Does -Os have any meaning currently to clang? llvm?

Sorta. Yes.

What about inlining? Is inlining turned off?

Yes. No. Different model though. Look for optimize_size.

-eric

Tia.

Hi Reed,

-Os could do with some love. It is more or less the same set of passes as -O2, but with a few things that are most likely to increase code size removed. We have had problems with it in the past for FreeBSD's bootloader. By tweaking the set of default passes added for -Os, I got the size down by about 20%, but I didn't have time to evaluate whether this was a general saving or just for this specific case. If you have customers who value size optimisations, then it would be worth looking in lib/Transforms/IPO/PassManagerBuilder.cpp and tweaking things a bit. I suspect that you can get some quite significant improvements here, but so far it hasn't been a priority for anyone. Having -Oz working well (currently it comes nowhere near gcc) would be particularly helpful for bootloaders, where there is little or no performance-critical code, but there is a hard limit on the size. I imagine a lot of embedded MIPS systems have similar constraints.

David

Hi Reed,

-Os could do with some love. It is more or less the same set of passes as -O2, but with a few things that are most likely to increase code size removed. We have had problems with it in the past for FreeBSD's bootloader. By tweaking the set of default passes added for -Os, I got the size down by about 20%, but I didn't have time to evaluate whether this was a general saving or just for this specific case. If you have customers who value size optimisations, then it would be worth looking in lib/Transforms/IPO/PassManagerBuilder.cpp and tweaking things a bit. I suspect that you can get some quite significant improvements here, but so far it hasn't been a priority for anyone. Having -Oz working well (currently it comes nowhere near gcc) would be particularly helpful for bootloaders, where there is little or no performance-critical code, but there is a hard limit on the size. I imagine a lot of embedded MIPS systems have similar constraints.

Hmmm. You don't remember which tweaks you tried?

At one of the BOFS during the llvm conference a few years back, one of the Apple managers stated in effect that their view of -Os was to get some modest savings but only if performance has near 0 impact.

There’s nominally an Oz option to go for “minimum size”.

-eric

Hmmm. You don't remember which tweaks you tried?

I don't, I'm afraid. I more or less just ran opt with vaguely sensible sounding combinations of passes to find the smallest one. Eventually we just removed some features from the bootloader to make it fit. One of the things on my to-do-eventually list if to set up a simulated annealing run to try permuting optimisation combinations and then running some benchmarks on size and speed to see if we can improve the default set.

At one of the BOFS during the llvm conference a few years back, one of the Apple managers stated in effect that their view of -Os was to get some modest savings but only if performance has near 0 impact.

I think that's sensible. This is why (in theory, at least) -Oz exists: for when you want to optimise for size, even at the expense of speed. In PassManagerBuilder, it's a controlled by the size factor. The interface at that level allows you to have quite fine granularity over your choice to the performance / size tradeoff, but the current implementation doesn't do much with the size parameter.

David

In a similar vein:
<http://donsbot.wordpress.com/2010/03/01/evolving-faster-haskell-programs-now-with-llvm/>.

-- Sean Silva