Rockbox: working CFLAGS

[jdong]

Earlier today I tried playing with CFLAGS in an attempt to get some "free" performance boosts. Any stock optimizations above -O (-O1) won't work, you'll get linker relocation truncation errors.

So, I started adding the options above -O one-by-one and ended up with a working set of CFLAGS. The main problem was -foptimize-sibling-calls, but doing "-O2 -fno-optimize-sibling-calls" did not make build work again, so I just listed every other optimization flag:

Code: [Select]

export GCCOPTS=-W -Wall -O -fstrict-aliasing -nostdlib -ffreestanding -Wstrict-prototypes -march=armv4t -mtune=arm7tdmi -ffunction-sections -fomit-frame-pointer -mlong-calls -fthread-jumps -fcrossjumping -fcse-follow-jumps  -fcse-skip-blocks -fgcse  -fgcse-lm  -fexpensive-optimizations -fstrength-reduce  -frerun-cse-after-loop  -frerun-loop-opt -fcaller-saves -fpeephole2 -fschedule-insns  -fschedule-insns2 -fsched-interblock -fsched-spec -fregmove -fstrict-aliasing -fdelete-null-pointer-checks -freorder-blocks  -freorder-functions -falign-functions  -falign-jumps -falign-loops  -falign-labels -ftree-vrp -ftree-pre

Did it help? Not that I can feel off-the-bat, but I've yet to do any scientific testing. Free lunches usually don't come this easy ;-)

[Llorean]

You didn't mention which builds don't compile with the higher optimizations, nor if any of them did, nor if you're only testing this in relationship to one specific hardware (and which it is, if you are).

[jdong]

I apologize; I tested strictly with the iPod 5G build which exhibited the behavior I described above. I used both the recommened GCC 4.0.3 and the latest 4.1.0 to confirm my results.

[Robertek]

Did you earn some good results?? Like longer battery life, better response, etc?? Did you test battery life etc??

Sorry Im stupid, but where you place your CFLAGS, because this crosscompiling doesnt use files such /etc/make.conf

[GodEater]

Did you earn some good results?? Like longer battery life, better response, etc?? Did you test battery life etc??

Sorry Im stupid, but where you place your CFLAGS, because this crosscompiling doesnt use files such /etc/make.conf

Battery life isn't going to be affected by this in any appreciable way at all. We need to know how to power down unused bits of the iPod to do that. The gcc compiler optimisations aren't going to magically do that for us.

[saratoga]

You should probably compare boost numbers while playing a given file to see if theres a real improvement.

[Robertek]

I know that this will not enhance battery a lot, but it could make less cpu usage - less cpu time, but you are right , than it could use more of other resources like ram. So it is questionable..
But it could make the player more faster, of course it behaves well now, with rockbox:)

[nirax]

seems that the behavior changed since the post of the thread was started.

i can compile with:

export GCCOPTS=-W -Wall -Wundef -O2 -march=armv4t -mtune=arm7tdmi -nostdlib -ffreestanding -Wstrict-prototypes -mcpu=arm7tdmi -mlong-calls -fomit-frame-pointer -Wno-pointer-sign -pipe -fweb -frename-registers

and it works fine so far. im going to write/port some performance testing app if there is no one existing yet
to have some numbers. mabe the FPS display of mplayer will be sufficient, although im quite confident there will be not much of a change visible there.

[nirax]

i just see that mtune and mcpu are both in the line. mtune is deprecated, so skip it.

one question though, did anyone here tried compilation also with the ARMV5 compiler ?
From my experience its output is faster and has a much smaller binary footprint than GCC

[nls]

This is pointless unless you have a benchmark to test the speed differences with.
After playing around quite a bit with gcc, I have seen many places where more
optimizations enabled leads to slower code.
Most codecs and a few plugins (like mpegplayer) have their own makefiles and set their own O levels.