Code-Optimierung beim Rowley

[Frank (Gast)]

Hallo,

ich benutze den Rowley Compiler für den MSP430. Kennt sich jemand mit 
den Code-Optimierungsfunktionen aus?

Was macht z.B. Code Factoring, Flattening Optimization, Code Motion 
Optimization, Copy Propagation Opt. oder auch Peephole Optimiz.?

Habe bei Rowley nachgeschaut, aber keine Erläuterung dafür gefunden.

Vielleicht kennt auch jemand einen Link in dem alle 
Optimierungsverfahren erläutert werden.

[Frank (Gast)]

Ein paar Antworten habe ich bei Wikipedia gefunden. Offen bleibt aber 
noch:

- Block Localization Optimization
- Code Motion Optimization
- Cross Jumping Optimization
- Flattening Optimization
- Jump Chaining Optimization
- Tail Merging Optimization

[Stephan (Gast)]

Du hast doch Kohle dafür gezahlt. Dann nimm den Support in Anspruch, 
wenn das nicht im Handbuch steht. Oder ist das eine gecrackte Version?

[Frank (Gast)]

Es steht im Handbuch allerdings so knapp das ich es nicht verstehe.

Beispiel

Block Localization

"This optimization moves blocks of code in order reduce span-dependent 
jump sizes on many architectures."

Code Motion

"Code motion moves blocks of instructions from one place to another to 
reduce the number of jump instructions in the final program."

Wo ist da der Unterschied?

Den Support in Anspruch zu nehmen ist ein guter Tipp. Das funktioniert 
nur leider überhaupt nicht am Wochenende.

Generell gibt es Compiler-Optimierungen aber auch bei anderen Compilern. 
Von daher sollte es eine allgemeine Frage sein.

[Sven P. (Gast)]

Frank wrote:
> Block Localization
>
> "This optimization moves blocks of code in order reduce span-dependent
> jump sizes on many architectures."
>
> Code Motion
>
> "Code motion moves blocks of instructions from one place to another to
> reduce the number of jump instructions in the final program."

Ich denke, das ist so gemeint:
Auf einigen Architekturen belegt ein Sprung-Befehl unterschiedlich viel 
Programmspeiche, je nachdem, wie weit gesprungen wird (ganz triviales 
Beispiel: 256 Speicherstellen gehen noch in ein Byte, danach wird der 
Sprungbefehl ein Byte länger usw.). Da wird dann wohl herumgeschoben, 
sodass relative Sprünge möglichst immer mit der kürzesten Variante des 
Sprungbefehles auskommen.

Die zweite Optimierung betrifft dann wohl die Zahl der Sprünge 
insgesamt.

[Johann L. (gjlayde)]

Frank wrote:

> Block Localization

wurde schon erklärt

> Code Motion
>
> "Code motion moves blocks of instructions from one place to another to
> reduce the number of jump instructions in the final program."

Ein (sequenzielles) Programm besteht aus basic blocks (BB) und edges 
(E). Ein BB ist ein Stück linear ablaufender Code, ohne Verzweigungen 
und ohne Labels. Diese elementaren Elemente kann man sich als Kanten in 
einem gerichteten Graph vorstellen. Die Knoten im Graph sind die Edges, 
das sind wie gesagt verzweigungen im Programmfluß und Stellen, an denen 
der Programmfluß wieder zusammenführt.

Im Speicher steht das "geplättete" Darstellung des Programms; die BBs 
stehen in irgendeiner Reihenfolge und sind über (bedingte) Sprünge 
verbunden. Je nachdem, wie man den Graph platt macht, gibt es 
unterschiedlich viele und weite Sprünge.

Ja nach Architektur kosten Sürünge unterschiedlich viel, zB je nach
-- Sprungweite
-- ob vor oder zurückgesprungen wird
-- Zustand einer Befehls-Pipeline
-- Zustand eines Befehls-Caches

Durch Umarrangieren der BBs kann man Sprünge sparen, bzw Laufzeit gegen 
Codegröße austauschen.

Beispiel 1

if X
   A
else
   B
C

Beispiel 2

if X
   AC
else
   BC

In #1 sind mehr Sprünge als in #2. Hier wird #2 vermutlich längeren Code 
geben, weil BB C in #2 2x austaucht. Aber der Code ist schneller, weil 
vor C kein Sprung steht. A und C verschmelzen zu einem neuen BB AC, dito 
für B und C zu BC. Zusätzlich sind andere Optimierungen möglich, weil in 
#2 innerhalb von AC bzw. BC optimiert werden kann, was in #1 nicht so 
einfach möglich ist, weil man zur Compilezeit nicht weiß, welchen Pfad 
das Programm zur Laufzeit nimmt.

Johann