Zitat von
matzeed7
Gibt es denn irgendwo eine Aussage wie die Abbildung von den pseudoregistern in die entsprechenden Hardregister definiert ist??
So ganz verstehe ich deine Frage nicht.
Für eine Maschine ist dies angegeben in den Comstraints zu dem jeweiligen Operanden, wobei in den Constraint noch mehr steht: Constraints beziehen sich ja auf Operanden allgemein, also nicht nur auf REG-Operanden, sondern auch auf Adressen, MEM, Konstanten, und Teilmengen/Vereinigungen davon, etc. AUsserdem stehen in den Constrains Dinge wie: early clobber, ob Operanden Kommutieren, Kosten von Constraints, ob eine Constraint Nebeneffekte hat, ...
Für eine konkrete Insn wird die Abbildung notiert, sobald sie erfolgt ist; hier eine Insn von avr-gcc 3.4.6 nach .25.greg:
Code:
(insn 15 39 17 1 (set (reg:HI 24 r24 [orig:41 <result> ] [41])
(plus:HI (reg/v:HI 24 r24 [orig:42 a ] [42])
(reg/v:HI 22 r22 [orig:43 b ] [43]))) 25 {*addhi3} (nil)
(nil))
Pseudo 41 enthält den Return-Wert (<result>), der aber schon auf Hard-Reg 24 (durch REGISTER_NAMES[] benamt zu "r24") abgebildet wurde. Variable "a" in 42 lebt auch in 24 und b lebt in 43, jetzt in 22.
Hier siehst du schon ein Problem: Sowohl <result> als auch a leben in r24. Das geht ok weil a nach der Insn nicht mehr gebraucht wird. Eine REG_DEAD Note für 24 gibt's an der Insn aber keine, weil 24 nach der Insn nicht tot ist (danach lebt <result> drin).
In .24.lreg gabt's noch Dead-Notes für a in insn 15:
Code:
(insn 15 39 17 1 (set (reg:HI 41 [ <result> ])
(plus:HI (reg/v:HI 42 [ a ])
(reg/v:HI 43 [ b ]))) 25 {*addhi3} (nil)
(expr_list:REG_DEAD (reg/v:HI 42 [ a ])
(expr_list:REG_DEAD (reg/v:HI 43 [ b ])
(nil))))
Wo a wirklich lebt, sieht man aber erst in der Assembler-Ausgabe (-S -dP -fverbose-asm), denn nach .26.postreload kommen noch einige Passes.
Code:
; (insn 15 39 47 (set (reg:HI 24 r24 [orig:41 <result> ] [41])
; (plus:HI (reg/v:HI 24 r24 [orig:42 a ] [42])
; (reg/v:HI 22 r22 [orig:43 b ] [43]))) 25 {*addhi3} (nil)
; (expr_list:REG_DEAD (reg/v:HI 22 r22 [orig:43 b ] [43])
; (nil)))
add r24,r22 ; <result>, b ; 15 *addhi3/1 [length = 2]
adc r25,r23 ; <result>, b
Auch wenn dir das alles weiterhelfen mag, möchte ich nochmals erwähnen, daß es nicht sonderlich sinnvoll ist, Informationen aus den -da Dateien rauszuziehen, um sie auszuwerten! Diese Dateien dienen den gcc-Entwicklern u.a. zum Auffinden von Bugs und beim Implementieren neuer Features. Wenn man wirklich Informationen haben will, sollte man eher versuchen, GCC zu instrumentieren als seinen -da-Ausgaben hinterherzulaufen. Von daher ist wohl ein Wörtchen mit deinem Auftraggeber angebracht, der dich diese Studienarbeit schreiben lässt.
Es bringt dir nähmlich mehr, etwas von den Interna vom GCC zu lernen/verstehen, als dich mit dem lisp-Parser rumzuärgern für ne Ausgabe, die du nicht klar spezifiziert bekommst. Un wenn du es hinbekommst, dann rekonstruierst du lediglich die Informationen, die GCC intern schon (sicherlich vollständiger) hat!
Was den lisp-Parser angeht, so gibt's den schon in ./gcc/read-rtl.c, dem Gegenstück zu ./gcc/print-rtl.c. Der RTL-Reader dient aber AFAIK zum Lesen des md-Files.
Zitieren
Lesezeichen