Forum: Compiler & IDEs AVR-GCC Deoptimierung


von Mark .. (mork)


Lesenswert?

Hallo,

ich habe eine Funktion
1
char add(char a,char b)
2
{
3
  return a+b;
4
}
die mir die Summe der beiden Argumente liefert. Bei Optimierung 2,3,s 
erzeugt AVR-GCC das hier:
1
  35                  .global   _Z3addcc 
2
  37                  _Z3addcc: 
3
  38                  .LFB42: 
4
  39                  .LM1: 
5
  40                  /* prologue: frame size=0 */ 
6
  41                  /* prologue end (size=0) */ 
7
  42 0000 962F            mov r25,r22 
8
  43                  .LBB2: 
9
  44                  .LM2: 
10
  45 0002 980F            add r25,r24 
11
  46                  .LBE2: 
12
  47                  .LM3: 
13
  48 0004 892F            mov r24,r25 
14
  49 0006 9927            clr r25 
15
  50                  /* epilogue: frame size=0 */ 
16
  51 0008 0895            ret
R22 wird zuerst nach r25 kopiert, mit r24 addiert und das Ergebnis dann 
nach r24 kopiert. Nicht gerade der beste Weg, um r24 mit r22 zu 
addieren.

Das richtig abartige kommt aber bei Optimierung 0:
1
  32                  .global   _Z3addcc 
2
  34                  _Z3addcc: 
3
  35                  .LFB42: 
4
  36                  .LM1: 
5
  37                  /* prologue: frame size=2 */ 
6
  38 0000 CF93            push r28 
7
  39 0002 DF93            push r29 
8
  40 0004 CDB7            in r28,__SP_L__ 
9
  41 0006 DEB7            in r29,__SP_H__ 
10
  42 0008 2297            sbiw r28,2 
11
  43 000a 0FB6            in __tmp_reg__,__SREG__ 
12
  44 000c F894            cli 
13
  45 000e DEBF            out __SP_H__,r29 
14
  46 0010 0FBE            out __SREG__,__tmp_reg__ 
15
  47 0012 CDBF            out __SP_L__,r28 
16
  48                  /* prologue end (size=10) */ 
17
  49 0014 8983            std Y+1,r24 
18
  50 0016 6A83            std Y+2,r22 
19
  51                  .LBB2: 
20
  52                  .LM2: 
21
  53 0018 9981            ldd r25,Y+1 
22
  54 001a 8A81            ldd r24,Y+2 
23
  55 001c 890F            add r24,r25 
24
  56 001e 9927            clr r25 
25
  57                  .LBE2: 
26
  58                  /* epilogue: frame size=2 */ 
27
  59 0020 2296            adiw r28,2 
28
  60 0022 0FB6            in __tmp_reg__,__SREG__ 
29
  61 0024 F894            cli 
30
  62 0026 DEBF            out __SP_H__,r29 
31
  63 0028 0FBE            out __SREG__,__tmp_reg__ 
32
  64 002a CDBF            out __SP_L__,r28 
33
  65 002c DF91            pop r29 
34
  66 002e CF91            pop r28 
35
  67 0030 0895            ret
Da wird anscheinend der Stackpointer manuell de-/inkrementiert.

Bei Opt. 1 kommt aber die einzig anständige Lösung:
1
  32                  .global   _Z3addcc 
2
  34                  _Z3addcc: 
3
  35                  .LFB42: 
4
  36                  .LM1: 
5
  37                  /* prologue: frame size=0 */ 
6
  38                  /* prologue end (size=0) */ 
7
  39                  .LBB2: 
8
  40                  .LM2: 
9
  41 0000 860F            add r24,r22 
10
  42                  .LBE2: 
11
  43                  .LM3: 
12
  44 0002 9927            clr r25 
13
  45                  /* epilogue: frame size=0 */ 
14
  46 0004 0895            ret
Kann mir bitte jemand erklären, wieso der GCC bei Opt 0,2,3,s solche 
"Deoptimierungen" durchführt?

MfG Mark

von Christoph _. (chris)


Lesenswert?

> Das richtig abartige kommt aber bei Optimierung 0:

Nur zur Info: "Optimierung 0", also das Flag -O0, bedeutet "optimiere 
gar nicht". Ist also kein Wunder dass der Code dann etwas umständlicher 
aussieht.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.