Optimizer Bug mit (-O3) bei WinAVR-20090313

Peter S. schrieb:
> Vermutlich handelt es sich nicht wirklich um einen Bug, aber dennoch um
> einen sehr sonderbaren Effekt: Mit Optimierung -O3 kann der erzeugte
> Code riesengross werden, bzw. wesentlich grösser als ohne Optimierung!

Ja, -O3 ist letztlich sowas wie ``optimize for speed''.  Da werden
Schleifen entrollt, Funktionen inline expandiert etc. pp. was das
Zeug hält.

Was sagt denn das Assembler-Listing?

Wenn O3 eine Geschwindigkeitsoptimierung ist (kenne die 
Compiler-Optionen nicht gut), tippe ich auf ein partielles 
loop-unrolling im main-Programm

http://de.wikipedia.org/wiki/Hotspot-Optimierung#Loop-Unrolling

Einfach ein Schuss ins Blaue.

Schöne Grüße,
Kai

Okey, das wirds wohl sein. Somit macht -O3 bi kleinen uC wie den AVR 
kaum Sinn....

Das würde ich gernerell so nicht unterschreiben. Wenn dein Prog extrem 
zeitkritisch ist, könnten dir genau das den erhofften Erfolg bringen, 
dein Controller hätte ja genug Flash. ;-)

Aber im Allgemeinen funktioniert O2 eigentlich am besten (meine 
Erfahrung)

Gruß
Fabian

Jede Optimierung kann nach hinten los gehen.

Ob eine Optimierung wirklich diesen Namen verdient, ist immer auch 
abhängig von der Zielarchitektur.

Einfach mal bedenken, daß die Voreinstellungen der aktivierten 
Optimierungsstrategien in avr-gcc die gleichen sind wie für 32- und 
64-Bit Systeme auch!

Und da AVR nun mal weder Date- noch Codecache hat, keine Pipeline 
(zumindest ist die Dauer von Befehlsausführungen unabhängig von deren 
Anordnung), Sprünge recht billig sind, manche Arithmetik jedoch 
vergleichsweise teuer (zB a << n, a/b, a%b) passt das eben bei weitem 
nicht immer. Nur daß der Code reisengroß wird, heisst nicht, daß er 
schneller wird ;-)

Es vergrößern sich zum Beispiel Sprungweiten. Während in kompaktem Code 
oft ein relativer, Sprung genommen werden kann, muss bei ausladendem 
Code die Bedingung umgedreht werden (kostet nix), und über einen 
absoluten Sprung gesprungen werden, welcher das eigentliche Sprungziel 
adressiert. Das ist langsamer und breiter. Wenn eine aufgerolle Schleife 
dann zig solcher Konstrukte enthält (Schleifenbedingung, break, ...), 
schiesst sich die Optimierung selbst ins Knie...

Unangenehm ist auch, daß viele Optimierungen die Lebensdauer von 
Registern erhöhen (zB loop invariant motion etc). Das macht den Code 
theoretisch schneller, aber wenn die Register ausgehen und stattdessen 
die Werte zum RAM hin- und hergeschaufelt werden müssen, ist der Code 
deutlich größer und merklich langsamer. Der Effekt lässt sich hin und 
wieder auch bei Inlining beobachten.

Um Gefühl defür zu bekommen, welche Optimierung geeignet ist, hilft nur 
eins: Hin und wieder muss man sich die Compilerausgabe anschauen.

Irgendwann hat man dann raus, was in 90% der Fälle gut taugt. -O3 gehört 
für avr-gcc aber sehr wahrscheinlich nicht dazu.

Die einzigen Änderungen, die avr-gcc an den Optionen vornimmt, sind

1

flag_delete_null_pointer_checks = 0;

2

3

if (!PARAM_SET_P (PARAM_INLINE_CALL_COST))

4

  set_param_value ("inline-call-cost", 5);

was dem Effekt entspricht von

1

-fno-delete-null-pointer-checks  --param inline-call-cost=5 ; anstatt 12

Johann

Sven P. schrieb:
> Jo, -O123 sind normalerweise für Geschwindigkeit, -Os für Programmgröße.

Wobei das mit der Geschwindigkeit beim AVR schnell nach hinten losgehen 
kann, -Os ist oft auch am schnellsten.

Außerdem arbeiten die Optimierungen mit der Brechstange, d.h. es wird 
alles gleich optimiert, egal, ob alle 10 Tage aufgerufen oder alle 10µs.
Man kann also leicht Verzehnfachung des Codes erreichen bei 0% 
Geschwindigkeitszuwachs.

Andere Optimierungen neben -Os würden nur Sinn machen, wenn man sie 
selektiv anwenden könnte (im Sourcecode auf einzelnen Funktionen).


Peter

Peter Dannegger schrieb:

> Wobei das mit der Geschwindigkeit beim AVR schnell nach hinten losgehen
> kann, -Os ist oft auch am schnellsten.

Würd ich auch empfehlen als Grundlage.

> Andere Optimierungen neben -Os würden nur Sinn machen, wenn man sie
> selektiv anwenden könnte (im Sourcecode auf einzelnen Funktionen).

Das geht ab 4.4.0 per

1

#pragma GCC optimize ...

2

__attribute__((__optimize__ ...))

http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas

Johann

Peter Dannegger schrieb:
> Außerdem arbeiten die Optimierungen mit der Brechstange, d.h. es wird
> alles gleich optimiert, egal, ob alle 10 Tage aufgerufen oder alle 10µs.

Nicht grundsätzlich, GCC kann Laufzeitergebnisse des Profilers gprof bei 
der Optimierung berücksichtigen. Nur leider gibt's gprof nicht für den 
AVR. Wäre ein lustiges Projekt etwas ähnliches für den AVR zu 
implementieren, ob's bei der Optimierung viel bringt sei mal 
dahingestellt.