Registerallokator til Dat1E. Jens Jakob Jensen, Nils Daniel Brixen og Henrik Stuart

Transkript

1 Registerallokator til Dat1E Jens Jakob Jensen, Nils Daniel Brixen og Henrik Stuart 23. maj 2002

2 Indholdsfortegnelse 1 Oversigt over opgaven Formål Læsevejledng Sammenfatng Analyse af emneområdet Emnekontekst Defition af problemet Overordnet prcip Virtuelle registre Interferens En dskrænkng Optimalitet Formulerg som graffarvng Graffarvng Interferensgrafen Registerallokerg som graffarvng Grundlægge metode Renumberg Build Coalesce Spill Costs Simplify Spill Code Select Optimistisk farvng Simplify Select Resultat Forbedret coalescg Konservativ coalescg Iterativ coalescg Resultater Spill-omkostnger Defition af spill cost Chait s metode Bedst af tre Ændret spill cost og specialtilfælde

3 INDHOLDSFORTEGNELSE Spill-kode Alternative metoder Liveness-analyse Andre teknikker Prioritetsbaseret farvng Graffusion Implementationen Mål for implementationen Indskrænkng af struktionssæt MIPS Intel IA Introduktion af pseudo-struktioner Repræsentation af arkitektur og struktionssæt Grænseflade til allokatoren Grænseflade Mere generel grænseflade Oversigt over det implementerede DList TDListFn StrgSet Worklists RegisterAllocator Om implementationen Ændrger til Appel s pseudo-kode Prioriterg af MOVE-struktioner Liveness-analyse Beregng af spill cost Implementation af spill Automatisk callee saves-bevarg Debuggg Brugervejledng Anvelse Implementation af kald-konventioner Defition af en arkitektur Afprøvng Metode til afprøvng Lovlig registerallokerg Mål for afprøvng Praktiske begrænsnger Afprøvng med MIPS Kriterier for afprøvng Beskrivelse af uddata Eksempel fra Appel & George ([App99]) Eksempel fra Torben Mogensen ([Mog00]) Afprøvng med Intel Sammenligng med den eksistere Sammenligng af allokerg og coalescg Sammenligng af kørselsresultater

4 INDHOLDSFORTEGNELSE 3 5 Konklusion 74 6 Litteratur 76 A Kildetekst 78 A.1 DList.sig A.2 DList.sml A.3 TDListFn.sml A.4 StrgSet.sig A.5 StrgSet.sml A.6 Worklists.sig A.7 Worklists.sml A.8 RegisterAllocator.sml A.9 Architecture.sig A.10 ArchAppel3.sml A.11 ArchAppel4.sml A.12 ArchMIPS.sml A.13 ArchIntel.sml A.14 RegAllocTest.sml

5 Kapitel 1 Oversigt over opgaven 1.1 Formål Registerallokatoren der benyttes til 1.-delskurset Datalogi 1E er begrænset ved kun at understøtte en delmængde af MIPS-struktionssættet, og ved ikke at understøtte spill. Desuden er den relativt ufleksibel med hensyn til angivelse af caller-/callee-savesregistre. Målet med denne opgave er at udvikle en ny registerallokator, som kan erstatte den eksistere, til brug på kurset Datalogi 1E. Vi vil derfor lægge vægt på en simpel grænseflade til allokatoren, samt fyldestgøre dokumentation af den praktiske brug. Desuden er det vigtigt at registerallokergen er korrekt, men ikke nødvigvis optimal. På Datalogi 1E bruges sproget Standard ML til at implementere en oversætter, og da registerallokatoren skal fungere som en del heraf, er det er krav, at implementationen foretages i Standard ML mere specifikt skal den fungere ved brug af Moscow MLoversætteren Læsevejledng For at kunne konstruere en registerallokator, har vi undersøgt en del af teorien bag registerallokerg. Det giver sig udslag i, at opgaven består af to dele: en teoretisk del, og en praktisk del. Den teoretiske del består af en undersøgelse af grene af teorien bag registerallokerg. Denne undersøgelse danner grundlaget for den anden del, som omhandler den konkrete implementerg af en registerallokator. Kapitel 2 deholder den teoretiske del. Det består af en præciserg af emneområdet og problemet for opgaven (afsnit 2.1 og 2.2). Herefter beskrives en klassisk tilgang til problemet i afsnit 2.3 og 2.4. Afsnit 2.5 til 2.8 omhandler nogle forbedrger til den grundlægge metode. Afsnit 2.10 opsummerer kort nogle andre metoder at gribe registerallokergsproblemet an på. Vi gør os ikke forhåbnger om at dække hele registerallokergsområdet der er en ganske stor mængde litteratur om området. Vi har forsøgt at vælge de dele, som lader til at have gennemslagskraft, det vil sige tages med i efterfølge forskng. 1 Se sestoft/mosml.html.

6 1.3 Sammenfatng 5 I den teoretiske del af opgaven vil vi udelukke koncentrere os om at beskrive problemstillger og mulige løsnger. Vi vil ikke i den del tage overvejelser omkrg implementation med - således vil kapitel 2 deholde teori for nogle teknikker, som vi ikke vil tage med i vores implementerg. Kapitel 3 beskriver den konkrete implementation vi har foretaget. Der begyndes i afsnit 3.1 og 3.2 med at præcisere, hvilke dele af den beskrevne teori vi vil tage med i vores registerallokator, og hvilke årsager vi har til at vælge de dele ud, som vi har valgt. I afsnit 3.3 til 3.6 behandles forskellige dele af registerallokatorimplementationen, og afsnit 3.7 deholder en praktisk vejledng i brug af implementationen - herunder hvordan forskellige kaldkonventioner kan realiseres. Afprøvng af en registerallokator kan gribes an på mange forskellige måder. I afsnit 4.1 diskuteres nogle af disse, og den strategi som vi har valgt til at afprøve implementationen præsenteres. Dette er første del af kapitel 4 som omhandler afprøvngen af den implementerede registerallokator. Resten af dette kapitel beskriver hvilke afprøvnger, der er foretaget, og resultaterne af dem. Til sidst i opgaven, kapitel 5, er der placeret en konklusion. Da emneområdet for opgaven er behandlet i kurset Datalogi 1E, vil vi i kapitel 2 forudsætte, at læseren har et kskab til registerallokerg og oversætterteknik generelt svare til en person der har fulgt kurset Datalogi 1E. Dog er afsnit 3.7 rettet specielt mod personer der skal benytte registerallokatoren, det vil sige nogle der er i gang med at tage kurset Datalogi 1E. 1.3 Sammenfatng Der er implementeret en registerallokator ud fra beskrivelsen i [App99] som resulterer i lovlige registerallokererger i de afprøvede tilfælde. Sammenlignet med den eksistere registerallokator er der ikke den store forskel for programmer som ikke spiller, hvilket tyder på at den implementerede registerallokator foretager en rimelig allokerg og fjerner et rimeligt antal MOVE-struktioner. Der er tilstræbt en enkel grænseflade til registerallokatoren som samtidig er fleksibel med hensyn til valg af arkitektur og kaldkonvention. Det mener vi er lykkedes. Alt i alt mener vi at have udviklet et rimeligt alternativ til den eksistere registerallokator på Datalogi 1E, som desuden kan benyttes til videre undersøgelse af emnet registerallokerg.

7 Kapitel 2 Analyse af emneområdet 2.1 Emnekontekst Registerallokerg er en del af processen at oversætte fra et programmergssprog til maskkode. Som bekt er der mange former for lager i en maske. Disse er, for eksempel, registre, CPU-cache, arbejdslager og diske. Af disse er det kun registrene, som oversætteren har fuld kontrol over - for eksempel kan oversætteren ikke kontrollere hvilke tg der er placeret i CPU ens cache. Da tilgangstiden til registrene er væsentlig lavere resten af lageret, er det ønskeligt at udnytte disse i videst mulig udstrækng. Vi vil i resten af opgaven bruge betegnelsen hukommelse om alle typer for lager, som ikke er registre. Hvis ambitionen med oversætteren blot er at få bevaret programmets semantik, kan man ignorere problemet med at udnytte registrene optimalt. Man kan så klare sig med et ganske lavt antal registre, og opbevare alt i hukommelsen; hver gang en værdi skal bruges, hentes den d i et register og skrives tilbage til hukommelsen efter en eventuel ændrg. Dette resulterer i et højt antal hukommelsestilgange for programmet, og disse antages at være væsentlig langsommere registertilgange. Hvis ambitionen derimod, er at oversættelse, for eksempel fra et højniveau-sprog til maskkode, skal resultere i kode der er (mdst) lige så god som håndprogrammeret maskkode, så er det en vigtig del af processen, at udnytte registrene godt. Det er registerallokatorens opgave at bestemme, hvad der skal placeres i de forskellige registre på forskellige tidspunkter. Opgaven går således ud på at udføre denne fordelg, så antallet af hukommelsestilgange for det resultere program mimeres. Oversættelse af et program foregår ofte i flere tr, hvor der bruges en mellemkode (se [App99] kapitel 7). På denne mellemkode udføres nogle forskellige optimerger, som for eksempel afhænger af rækkefølgen af struktionerne, og ikke af det konkrete format for struktionerne. Denne del af oversættelsen kalder vi optimerg. 2.2 Defition af problemet I dette afsnit vil vi præcisere hvad der forstås ved problemet registerallokerg.

8 2.2 Defition af problemet Overordnet prcip En metode som er helt fundamental for hvordan vi griber registerallokergen an på, er at lade optimergsfasen af oversættelsen tro, at der er et ubegrænset antal registre til rådighed. Når optimergsfasen er overstået, er det så op til registerallokatoren at sørge for, at der kun benyttes registre, som rent faktisk er til stede i masken. På denne måde bliver registerallokergen altså adskilt fra resten af oversættelsesprocessen Virtuelle registre I de dele af oversættelsen der ligger før registerallokergen dføres altså såkaldte virtuelle registre 1, som oversætteren kan benytte til at deholde variable i programmet, mellemresultater eller konstanter. Registerallokerg består så i at konstruere en afbildng fra virtuelle registre til maskregistre. På denne måde bliver hvert virtuelt register knyttet til et maskregister. Det er dog ikke ligegyldigt hvordan denne afbildng konstrueres. Hvis, for eksempel, en struktion skal læse to argumenter (antag at de henholdsvis har værdierne 3 og 5) og disse er placeret i to forskellige virtuelle registre i mellemkoden, bliver programmets semantik ikke bevaret, hvis de to virtuelle registre afbildes i samme maskregister - så vil struktionen enten få værdien 3 eller 5 på begge argumenter. I resten af opgaven vil vi bruge betegnelsen kildeprogrammet, om den sekvens af maskkode-struktioner som gives som ddata til registerallokatoren. Kildeprogrammet består altså af struktioner skrevet i et bestemt masksprog, blot med den forskel, at der antages et vilkårligt stort antal registre Interferens Ovenståe problematik med overlap i brug kan formaliseres som begrebet terferens (følge defition er den ultimative defition af terferens som dført af Chait et al. i [CAC + 81] side 55). To virtuelle registre terfererer, hvis der fdes et sted i kildeprogrammet, og en mulig eksekvergsrækkefølge af struktionerne, så der gælder at: 1. Begge virtuelle registre er deferede 2. Begge virtuelle registre bliver brugt 3. Der er forskellige værdier i de to virtuelle registre Registerallokergen skal altså foregå, så tet par af virtuelle registre der terfererer allokeres til samme maskregister. Hvis bare et af de tre punkter ovenfor ikke er opfyldt, kan de to virtuelle registre tildeles samme maskregister på det pågælde punkt, for den pågælde eksekverg af kildeprogrammet der er gen forskel på de to virtuelle registre. På den anden side, hvis alle tre er opfyldte, så er der forskel på de to virtuelle registre, og det vil være forkert at benytte samme maskregister på det punkt, i den pågælde eksekverg. Med ovenståe defition, er det ikke nemt at afgøre, om to virtuelle registre terfererer man skal for samtlige steder i kildeprogrammet og samtlige mulige eksekverger af dette undersøge de tre punkter. [CAC + 81] bemærker, at dette i det generelle tilfælde er uafgørligt. Derfor benyttes en anden defition af, om de virtuelle 1 For at undgå forvirrg med de fysiske registre, vil vi betegne disse som maskregistre, hvor det er nødvigt for at undgå misforståelser.

9 2.2 Defition af problemet 8 registre terfererer ved en struktion, som tilnærmer de tre punkter. Denne er vist i defition 2.1. Defition 2.1 Interferens To virtuelle registre u og v terfererer ved en struktion i, hvis 1. u og v begge er tilgængelige. Det vil sige, der fdes en vej fra en defition af u til i, og en vej fra en defition af v til i. 2. u er leve ved en defition af v (eller omvt). Hvor en variabel v er leve ved en struktion i, hvis der fdes en vej fra i til en struktion der læser v, og der ikke er nogen skrivng til v på vejen. Denne defition af terferens er naturligvis et konservativt estimat af den ultimative defition, så der vil være tilfælde, hvor virtuelle registre tildeles forskellige maskregistre, selvom de kunne have delt et maskregister. Fordelen er dog, at denne defition af terferens kan implementeres forholdsvis let. Dette gøres ved hjælp af liveness-analyse, der fder ud af hvilke virtuelle registre, der er leve på de forskellige punkter i kildeprogrammet. Dette er kort beskrevet i afsnit 2.9. Alt i alt er registerallokerg altså det problem, at konstruere en afbildng fra de virtuelle registre til maskregistrene, således at to virtuelle registre der terfererer på noget punkt i kildeprogrammet, ikke tildeles samme maskregister. Da der kan være et vilkårligt stort antal virtuelle registre, men kun et fast (lille) antal maskregistre, kan man naturligvis ikke forvente, at det altid kan lade sig gøre at konstruere afbildngen fra virtuelle- til maskregistre. Hvis dette er tilfældet, må man opbevare dholdet af et eller flere virtuelle registre i hukommelsen - man spiller registret. Den kode der skal sørge for at dlæse og skrive registret tilbage til hukommelsen kaldes spill kode. Briggs nævner i [Bri92], at prcippet med adskillelsen af registerallokerg fra resten af oversættelsesprocessen er en god idé, hvis der er tilstrækkeligt mange registre til rådighed, men ikke nødvigvis, hvis der er meget få registre. Vi vil dog (jvf. antagelsen i afsnit 2.1) behandle registerallokergen som beskrevet i afsnit Med dette valg, er der forskellige måder at foretage registerallokergen på: der kan for eksempel udføres registerallokerg for hvert udtryk (se for eksempel [App99] afsnit 11.4), for hver procedure eller for et helt program. Registerallokerg for en procedure af gangen kaldes global registerallokerg 2, og er den metode vi vil undersøge En dskrænkng Briggs bemærker i [Bri92] (afsnit 2.2.1), at et virtuelt register v kan bruges til flere forskellige opgaver i løbet af en procedure, og at det ikke er nødvigt at tildele det samme maskregister til alle disse forskellige opgaver. Dette benyttes til at defere begrebet live range, som altså er disjunkte sekvenser af struktioner høre til forskellige opgaver for et virtuelt register. Hvis man i løbet af oversættelsen dfører rigeligt af virtuelle registre - det vil sige et for hver opgave, kan man opnå, at der kun er én live range for hvert virtuelt register. På denne måde kan man nøjes med at behandle virtuelle registre under registerallokergen, og ikke live ranges. Dette kræver naturligvis også, at det oprdelige program er skrevet på denne måde - for eksempel, at man 2 Se for eksempel [Bri92] afsnit 1.2.

10 2.3 Formulerg som graffarvng 9 ikke bruger samme variabel i til to helt forskellige opgaver denfor samme procedure, men derimod deferer en variabel per opgave. Vi vil dskrænke os til at behandle virtuelle registre under registerallokergen, og ikke live ranges. Dette svarer til, at vi lader et virtuelt register og en live range være samme tg. Dette valg begrænser ikke mulighederne for resten af registerallokergen hvis processen ønskes udvidet med live ranges, kan der dføres et separat tr der identificerer live ranges i kildeproceduren (se for eksempel [CH90] afsnit 4.1) Optimalitet I den hidtidige beskrivelse har vi været lidt vage omkrg hvad der forstås ved at udnytte maskregistrene bedst muligt. Målet med registerallokergen er at foretage tildelgen af virtuelle registre til maskregistre, så kildeprogrammets semantik bevares (ved hjælp af terferens-begrebet), og så antallet af hukommelsestilgange i det resultere program mimeres. Hvis det på nogen måde er muligt at foretage allokergen, så der ikke spilles, så er en optimal registerallokerg en, der opnår dette. Hvis det ikke er muligt, er en optimal registerallokerg, en, der giver det laveste antal hukommelsestilgange som følge af spill kode. Registerallokergsproblemet kan reduceres til et graffarvngsproblem (se afsnit 2.3). Ifølge [CAC + 81] er graffarvngsproblemet N P-hårdt. Det vil sige registerallokergsproblemet er også N P-hårdt. Det betyder, at man ikke skal regne med at kunne konstruere en registerallokator der udfører optimal registerallokerg denfor overskuelig tid i samtlige tilfælde. 2.3 Formulerg som graffarvng Den klassiske metode til at behandle registerallokerg på, er ved at reducere det til et graffarvngsproblem. Det var Chait et al. der i i [CAC + 81] først beskrev en implementation af en registerallokator bygget ud fra formulergen af registerallokergsproblemet som et graffarvngsproblem Graffarvng Givet et graf G = (V, E) kan graffarvng betyde to forskellige tg: enten er det kanterne i E, der skal farves, eller også er det knuderne i V der skal farves (se for eksempel [Bry92]). I forbdelse med registerallokerg benyttes udtrykket graffarvng om knudefarvngsproblemet. En farvng af G er en tildelg af en farve til hver af knuderne i V, således, at tet par af knuder, der er forbundne af en kant i E, får samme farve. Det mdste antal farver som kan bruges til at farve G, kaldes det knude-kromatiske tal (eller blot det kromatiske tal) for G Interferensgrafen Antag nu, at vi skal udføre registerallokerg for en procedure P fra et givent kildeprogram 3. Vi skal (som beskrevet i afsnit 2.2.3) tildele hvert virtuelt register et maskregister. Vi kan modellere dette ved at konstruere en terferensgraf, hvor der er en knude for hvert virtuelle register i P, og hvor der er en kant imellem to knuder, hvis 3 Som nævnt i afsnit på side 8 vil vi undersøge global registerallokerg, så vi behandler hver procedure for sig.

11 2.3 Formulerg som graffarvng 10 de terfererer (se afsnit for en diskusion af begrebet terferens). Desuden er der én knude for hvert maskregister, og disse terfererer alle med handen - de udgør altså en k-klike, hvis der er k maskregistre. De knuder der svarer til maskregistre betegnes præfarvede knuder - at de terfererer med handen skyldes, at de naturligt nok ikke kan være i det samme maskregister. En fordel ved at medtage præfarvede knuder i terferensgrafen er, at tg der er specifikke for maskarkitekturen kan dkodes i grafen. For eksempel nævner [CAC + 81] at i maskkoden til IBM System/370 kan base-registret til en LOAD-struktion ikke placeres i registret R0. Denne type formation er yderst specifik for den givne arkitektur, men ved at lade alle virtuelle registre i kildeprogrammet der benyttes som base-registre til load-struktioner terferere med det præfarvede register R0, kan formationen puttes d i terferensgrafen, og behandles på samme måde som alle andre terferenser. Interferensgrafen kan på denne måde benyttes til at abstrahere mange detaljer omkrg arkitekturen Registerallokerg som graffarvng Hvis der er k maskregistre, og vi kan graffarve terferensgrafen med k farver, svarer det til en allokerg af registrene: hvert virtuelle register er tildelt et maskregister (det vil sige har fået en farve), og hvis to virtuelle registre på noget punkt i kildeproceduren terfererer (det vil sige de er kantforbundne i grafen), så sørges der for, at de tildeles forskellige maskregistre (det vil sige, får forskellig farve). En optimal løsng af graffarvngsproblemet er altså, at fde en farvng, der benytter et antal farver, der svarer til det kromatiske tal for grafen. Det vil sige, vi omformulerer registerallokergsproblemet til et problem, der mimerer antallet af brugte registre for kildeproceduren. Registerallokergsproblemet søgte (se afsnit 2.2.5), at mimere antallet af hukommelsetilgange i det resultere program. Dette er et svært problem, da mange faktorer spiller d på antallet af hukommelsetilgange i det køre program. Vi omformulerer altså problemet til det mere håndgribelige, at mimere antallet af brugte registre. Den normale formulerg af graffarvngsproblemet er: fd det kromatiske tal for grafen. At fde en farvng der benytter dette antal farver er det vi søger. Afgørlighedsproblemet: Kan grafen farves med k farver? er ifølge [CAC + 81] N P-fuldstændigt. Det vil sige, vi skal ikke forvente at kunne fde en farvng af terferensgrafen, der benytter det færrest mulige antal farver. Når det handler om registerallokerg er det altså ikke så teressant at fde det kromatiske tal for grafen der ønskes farvet. Hvis vi givet et antal maskregistre k kan fde en farvng, der højst benytter k farver, er vi tilfredse. Bemærk her, at da de præfarvede knuder udgør en klike i grafen, vil det kromatiske tal altid være mdst k (se for eksempel [Bry92] kap. 11). Det der er relevant er altså hvor få farver vi kan klare os med, hvis vi ser bort fra de præfarvede knuder. Dette svarer til, at vi ikke kan sikre at vi benytter det færrest mulige antal maskregistre, men stiller os tilfredse med at kunne have plads til alle virtuelle registre i maskregistre dog forsøger vi at mimere antallet af benyttede maskregistre. Sammenfattet kan formulergen som graffarvng beskrives som angivet i defition 2.2. Defition 2.2 Registerallokerg ved graffarvng Givet en procedure P fra et kildeprogram og antallet af registre på den pågælde maskarkitektur, k, ønsker vi at fde en k-farvng af terferens-grafen for P. I beskrivelsen af registerallokerg som graffarvng i defition 2.2, har vi ignore-

12 2.4 Grundlægge metode 11 ret den mulighed, at den konstruerede terferensgraf har et kromatisk tal, der er højere det antal registre der er til rådighed (k). Hvis det er tilfældet, kan der naturligvis ikke fdes en k-farvng af grafen, og man siger at grafen ikke er farvelig. Dette svarer til at med formationen fra terferensgrafen er der ikke plads til de virtuelle registre i maskregistrene. Der må derfor dsættes spill-kode (se side 8). Da graffarvngsproblemet er N P-fuldstændigt, kan man heller ikke afgøre om den givne terferensgraf er farvelig. Det vil sige, der vil være grafer der erklæres som ikke farvelige, selvom de rent faktisk er det 4. Da terferensgrafen kun er et konservativt estimat af, hvordan de virtuelle registre terfererer (se afsnit 2.2.3), vil der ligeledes være kildeprogrammer for hvilke terferensgrafen vil blive angivet som ikke farvelig, selvom der godt kunne have været plads til de virtuelle registre i maskregistrene. Der er altså tilfælde hvor der spilles, selvom det ikke er nødvigt. I forhold til semantikken af kildeprogrammet er dette ikke noget problem - vi skal alligevel kunne håndtere at registre skal spilles. 2.4 Grundlægge metode I de foregåe afsnit har vi kun beskæftiget os med formulergen af registerallokerg. Nu vil vi beskrive en metode til rent faktisk at foretage allokergen udfra den givne beskrivelse af problemet. Den grundlægge algoritme for registerallokerg ved graffarvng stammer fra forskerholdet fra IBM Watson Research Center 5. Denne allokator er også kt som Yorktown allokatoren, eftersom IBM s ovennævnte forskngsafdelg befder sig i Yorktown Heights, New York. I den oprdelige artikel af Chait et al. ([CAC + 81]) er behandlgen af spill ret ad hoc-præget. Dette kommenteres i slutngen af artiklen, hvor der foreslås en anden metode til at håndtere spill, som tager udgangspunkt i terferensgrafen. Denne idé blev taget op, og i [Cha82] præsenteres den modificerede algoritme. Det er denne algoritme vi vil beskrive i det følge. Et overblik over algoritmen er afbilledet i figur 2.1. Betegnelserne for de enkelte tr vil ikke kunne fdes direkte i [CAC + 81] og [Cha82], men er dført af Briggs i [Bri92] i hans tolkng af artiklerne af Chait. Vi vil i det følge gennemgå de enkelte tr. Figur 2.1 Yorktown allokergs-algoritmen 4 I [CAC + 81] er det vist, at enhver graf kan opstå som terferensgraf for en kildeprocedure, hvilket viser eksistensen af de nævnte grafer. 5 Det vil sige, Chait et al. som beskrevet i [Cha82]

13 2.4 Grundlægge metode Renumberg Dette første tr går ud på at ddele brugen af de virtuelle registre i live ranges 6, som er beskrevet i afsnit Det er disse live ranges som dsættes i terferensgrafen. Hvordan man fder de forskellige live ranges i kildeproceduren er blandt andet beskrevet i [Bri92]. Som nævnt i afsnit vil vi begrænse os til kun at have én live range for hvert virtuelt register. Derfor er dette tr ikke så relevant for vores gennemgang Build Denne fase konstruerer terferensgrafen, der skal farvelægges i de næste tr af algoritmen. Hvordan grafen i praksis opbygges er beskrevet i for eksempel [Cha82] eller [App99] Coalesce Det overordnede prcip om at behandle registerallokerg som en separat del af oversættelsen (se afsnit 2.2.1) betyder som nævnt, at de tidligere faser i oversættelsesprocessen kan benytte et ubegrænset antal virtuelle registre, og der kan (se for eksempel [GA96] afsnit 1) være ganske mange MOVE-struktioner mellem sådanne virtuelle registre. Hvis antagelsen om at der er virkårligt mange registre til rådighed under kodegenerergen ikke skal resultere i unødvigt mange register-kopierger, må det kræves, at registerallokatoren er opmærksom på at fjerne overflødige register-til-register MOVE-struktioner. Det vil sige, hvis de to virtuelle registre v i og v j for en MOVEstruktion ikke terfererer, kan de slås sammen til ét og samme virtuelle register, som vi navngiver v ij, hvorved MOVE-struktionen ikke længere er nødvig dette betegnes coalescg. Når to virtuelle registre slås sammen til et, skal terferensgrafen naturligvis ændres. Det mest iøjnefalde resultat er, at to af knuderne i grafen er slået sammen til én. Hvis denne nye knude sættes til at terferere med alle knuder, som terfererede med mdst en af de oprdelige knuder, fås et konservativ estimat for hvilke knuder der terfererer med den nye knude. Grunden til at formationen ikke nødvigvis er præcis er, at der er fjernet en MOVE-struktion, og under opbygnigen af terferensgrafen tilføjes terferenser for hver struktion i kildeproceduren. I [Bri92] er der i afsnit angivet et eksempel, hvor den nye terferensgraf ikke er præcis. En løsng er at genopbygge terferensgrafen hver gang der fjernes en MOVE-struktion. Dette er dog ret dyrt, så normalt gås hele koden for kildeproceduren igennem, og der fjernes eventuelt flere MOVE-struktioner, og undervejs opdateres terferensgrafen konservativt, som beskrevet ovenfor. Hvis der efter et sådant gennemløb er fjernet nogle MOVE-struktioner returnerer vi til Build-stadiet, og gentager processen. Ifølge [BCT94] vil denne Build-Coalesce cyklus i praksis kun blive gentaget nogle få gange Spill Costs Dette skridt er optret til at farve grafen. For hvert virtuelt register i terferensgrafen, udregnes en omkostngsværdi for hvor dyrt det vil være at spille denne. Denne værdi bruges til at vælge hvilke virtuelle registre der skal spilles, hvis det skulle være nødvigt (se afsnit 2.4.5). 6 I Chait s formulerg kaldes de blot names.

14 2.4 Grundlægge metode 13 Overordnet er målet naturligvis at vælge at spille det register, som giver den mdste stigng i antallet af udførte LOAD-STORE struktioner for det resultere program. Dette estimeres ved at tildele spill costs, og foretage grådige valg, hvis det besluttes at der skal spilles. Den mest naive måde at dsætte spill-kode for et virtuelt register v der skal spilles, er at dsætte en LOAD-struktion før hver struktion der læser v, og efter hver skrivng til v at dsætte en STORE-struktion der kopierer v til hukommelsen. På denne måde kan prisen for at spille et virtuelt register v sættes til antallet af gange der læses og skrives til v. Dette antal kan ikke afgøres præcist, men ved at antage at en struktion udføres 10 gange så ofte hvis den er placeret i en løkke, kan det approksimeres. I Yorktown allokatoren benyttes groft sagt ovenståe metode til dsættelse af spill-kode, og den nævnte defiton af spill cost. Der er dog nogle forbedrger som er beskrevet i [Cha82]. Dette er en simpel måde at udregne ulempen/fordelen ved at spille det pågælde register. I afsnit 2.7 behandles andre måder at udregne spill costs Simplify Observationen der benyttes til at farve grafen er: lad G være en graf, som vi ønsker at farve med k farver, og antag at der fdes en knude v i G, af grad < k. Lad G være den graf der fås ved at fjerne v og alle kanter cidente med v fra G. Så gælder: G kan farves med k farver G kan farves med k farver Implikationen mod højre er oplagt. Antag at der er fundet en k-farvng af G. Da G er konstrueret fra G ved at fjerne en knude v at grad < k, vil der altid være mdst en farve ledig til også at farve v i G, som hermed altså også kan k-farves. Simplify processen undersøger repetativt knuderne i grafen G og alle knuder af grad < k, bliver lagt på en stak, samt fjernet fra grafen sammen med alle d- og udgåe kanter. Såfremt der kun er knuder, hvis grad er k tilbage i G, udvælges en af disse til at skulle spilles. Hvilken knude der vælges her afhænger af den valgte metode til at udregne spill omkostng se afsnit 2.7. I prcippet burde man her dsætte den nødvige spill-kode, og starte hele processen forfra. I stedet fortsættes med simplify processen, dtil grafen G er tom denne metode er billigere i køretid for registerallokergen. Hvis der er knuder der undervejs blev markeret til spill, genereres nu spill-kode for disse, og registerallokergen starter forfra. Hvis det ikke er tilfældet, fortsættes til næste fase: select Spill Code Såfremt en eller flere knuder i grafen er blevet markeret til spill, vil dette tr gennemgås. For hvert virtuelt register v der skal spilles, dsættes spill-kode. Den grundlægge metode til dette er (se for eksempel [Mog00] afsnit 8.6): i hver struktion i, der enten læser eller skriver v, erstattes v af v i. Efter hver struktion i der skriver til v dsættes en STORE-struktion der skriver værdien af v i til hukommelsen. Før hver struktion i der læser v, dsættes en LOAD-struktion der henter værdien fra hukommelsen til v i. Der dføres altså en masse nye virtuelle registre, som har kort levetid, i stedet for det register der skulle spilles. Dette er som også tidligere nævnt den mest grundlægge metode til at dsætte spill-kode i afsnit 2.8 behandles mere avancerede måder at dsætte spill-kode på.

15 2.5 Optimistisk farvng 14 Efter ændrg af kildeprogrammet så den kluderer spill-kode, er der kommet en del nye virtuelle registre, og det er derfor nødvigt at rekonstruere terferensgrafen. Dette gøres dog først efter at der er dsat spill-kode for alle de registre der blev markerede til spill i simplify-fasen. Ovenståe beskrivelse er under antagelsen af, at der er tale om en load-store arkitektur. Ved andre arkitektur-typer er det muligt at tilgå lageret direkte, f.eks. Intel s x86 assembler-struktionssæt som beskrevet i [Cor99b]. Der vil derfor her være tilfælde, hvor det ikke er nødvigt for eksempel at hente en spilled værdi d fra hukommelsen for at benytte den som argument til en struktion 7. Vi vil dog, for simplicitetens skyld, samt for at gøre implementationen nemmere antage, at vi har en load-store arkitektur, da Intel s IA-32 arkitektur uden problemer understøtter dette ligesåvel Select Denne del af algoritmen behandler stakken som simplify har opbygget. Knuderne afstakkes en ad gangen, og tildeles en farve. Da select først bliver aktiveret, når det lykkedes i simplify-fasen at tømme grafen for knuder uden at markere knuder til spill, og da der kun fjernes knuder af grad lavere k, vil der på ethvert tidspunkt i selectfasen være en ledig farve til den knude der betragtes. På denne måde er der fundet en k-farvng af terferensgrafen. Se for eksempel [Bri92] side for et eksempel på hvordan en farvng kan foregå. Der er foreslået adskillige forbedrger/ændrger til den algoritme, som er beskrevet i dette afsnit, nogle af disse beskrives i de følge afsnit. 2.5 Optimistisk farvng En af de vigtigste idéer præsenteret af Chait i artiklerne [CAC + 81] og [Cha82] er metoden brugt til at farve terferensgrafen. Denne metode er dog for konservativ: den producerer unødvigt meget spill. Da der er tale om heuristikker til farvngen, er det ikke muligt at konstruere en optimal farvng hver gang, men Chait s farvngsmetode kan forbedres, så den i mange tilfælde undgår unødvige spills. Dette er beskrevet af Briggs og andre i [PBKT89], [BCT94] og [Bri92]. Heri præsenteres en alternativ farvngsheuristik, som er en forbedrg af Chait s metode. Briggs bemærker to problemer ved Yorktown-allokatoren se for eksempel [BCT94] afsnit 3. Disse er: 1 For diamant-grafen vist i figur 2.2 vil Yorktown-allokatoren spille en af knuderne i grafen såfremt der søges en 2-farvng af denne. Dette er, som Briggs skriver, grundet Yorktown-allokatorens pessimistiske antagelse om at en knudes naboer alle får tildelt forskellige farver. For en 2-farvng af diamantgrafen betyder det, at én af knuderne vil spilles, selvom det ikke er nødvigt. 2 Det andet tilfælde hvori Briggs konstaterede en mangel i Yorktown-allokatoren var, som han skriver, ved oversættelse af en numerisk funktion, SVD, som er en sgulær værdi-dekomposition af Golub og Resch. Denne funktion består af en lang række dybt dlejrede løkker, omsluttet af mange virtuelle registre med lang 7 Det smarte her, at man sparer et register til at gemme den temporære variabel.

16 2.5 Optimistisk farvng 15 levetid. For disse vælger Yorktown-allokatoren at spille både virtuelle registre der forekommer i de dre løkker, og de lange ydre registre. Det viser sig, at der er ledige registre til rådighed i de dre løkker, hvorfor disse ikke behøver at spilles. Figur 2.2 Diamant-graf Det første problem opstår som nævnt, fordi Yorktown-allokatoren approksimerer x kan farves med x har grad < k. Dette er naturligvis en tilstrækkelig betgelse, men (som diamantgrafen viser) ikke en nødvig betgelse. Ved optimistisk at antage at nogle af en knude x s naboer vil få forskellige farver, kan man alligevel farve x. Det andet problem skyldes, at beslutngen om hvorvidt der skal spilles foretages, før allokatoren kan se, om det er nødvigt. For eksemplet med SVD betyder det at når allokatoren når til de dre virtuelle registre, markeres disse til spill, da de har den laveste spill cost. På dette tidspunkt er der ikke formation nok til rådighed til at allokatoren kan afgøre om det rent faktisk er nødvigt at spille eller ej efter hele allokergen kan det ses, at der er foretaget unødvige spills. Briggs foreslår en ny farvngsheuristik, som reparerer på de to nævnte problemer. Han kalder metoden for optimistisk farvng. Et overblik er vist i figur 2.3. Figur 2.3 Briggs-allokatoren (Optimistic Register Allocation) Denne modificerede algoritme beror på at udsætte beslutngen om, hvorvidt en given knude skal markeres til spill, og ændrer derfor på udformngen af simplify- og select-trene i algoritmen Simplify Først fjernes alle knuder i grafen for hvilke det gælder at antallet af naboer er < k. Såfremt det opdages at alle restere knuder i grafen har k naboer, vælges en kandidat til spill. Dette valg foretages på samme måde som i Yorktown-allokatoren,

17 2.6 Forbedret coalescg 16 udfra spill costs. Denne spill-kandidat lægges på stakken som alle andre knuder, og simplify køres igen for det restere af grafen dtil denne er tom. Det at knuden placeres på stakken alligevel er det optimistiske i metoden - man håber at nogle af en spill-kandidats naboknuder får samme farve, så der alligevel er en ledig farve Select Select-fasen kan nu ikke garantere at fde en farve til hver knude på stakken. Hvis den fder en knude, for hvilken der ikke er en ledig farve, må det være en af spillkandidaterne fra simplify-fasen. I dette tilfælde må knuden spilles, og select-fasen fortsættes dtil alle knuder har fået en farve, eller er markeret til spill. Hvis der er fundet knuder der skal spilles, dsættes spill code og allokergen starter forfra Resultat Den nye heuristik er en forbedrg af Chait s heuristik forstået på den måde, at hvis en graf kan k-farves med Yorktown-allokatoren, kan den også k-farves med den optimistiske farvng. Hvis Yorktown-allokatoren spiller registrene R, vil den optimistiske farvng resultere i en farvng, hvor de virtuelle registre der spilles er en delmængde af R. I [PBKT89] er der angivet detaljerede eksperimentelle data der viser, at den optimistiske farvng kan give en væsentlig forbedrg af antallet af virtuelle registre der spilles. 2.6 Forbedret coalescg Konservativ coalescg Den form for coalescg, som bliver brugt af Chait i Yorktown-allokatoren betegnes af George og Appel i [GA96] som aggresiv coalescg. Dette skyldes at Yorktownallokatoren fjerner alle MOVE-struktioner, hvor der ikke er terferens mellem de to virtuelle registre der dgår. I [Bri92] kapitel 5 dfører Briggs en anden strategi for coalescg, kaldet konservativ coalescg, som er deferet i defition 2.3. Defition 2.3 Konservativ coalescg To knuder v i og v j slås sammen, hvis og kun hvis den nye knude v ij har < k naboer af grad k (hvor k er antallet af farver der er til rådighed). Som beskrevet i afsnit fjernes under simplify-fasen først alle knuder af grad < k. Hvis der er flere knuder tilbage, har de grad k. For at en knude skal være tilbage efter alle af grad < k er fjernet, må den have haft k antal naboer alle af grad k. Derfor vil en knude der er dført ved konservativ coalescg aldrig blive markeret til spill Iterativ coalescg I artiklen [GA96] bemærkes det, at når to knuder i terferensgrafen slås sammen, vil den nye knude ofte have højere grad, de to der blev fjernet. Det vil sige, det bliver potentielt sværere at farve grafen. Derfor kan der opstå situationer (se figur 2.4), hvor en graf ikke kan farves med k farver efter coalescg, men hvor den oprdelige

18 2.6 Forbedret coalescg 17 graf godt kunne. Dette er uheldigt, da en MOVE-struktion antages at være væsentlig billigere, det at skulle spille et register. Denne situation vil kunne opstå, hvis der benyttes aggressiv coalescg. En anden tilgang er at benytte konservativ coalescg. Her vil man undgå at spille registre som resultat af coalescg 8. På figur 2.5 er vist et tilfælde, hvor konservativ coalescg i s forsigtighed ikke slår to knuder sammen, selvom det ikke ville være noget problem. Figur 2.4 (a) Interferensgraf der kan farves i to farver. Den stiplede lie betyder, at der fdes en MOVE-struktion med argumenter b og c. (b) Grafen efter coalescg af knude b og c. Grafen kan ikke længere farves med 2 farver nu skal der bruges 3. a a b c d bc d (a) (b) Figur 2.5 (a) Interferensgraf der kan farves i to farver. Den stiplede lie betyder, at der fdes en MOVE-struktion med argumenter b og c. Denne MOVE-struktion bliver ikke fjernet ved konservativ coalescg, da knuden bc får 2 naboer af grad 2. (b) Grafen efter coalescg af knude b og c. Grafen kan stadig farves med 2 farver. a a b c d bc d (a) (b) George og Appel var ikke tilfredse med at benytte hverken aggresiv eller konservativ coalescg til deres formål i [GA96] en registerallokator til en Standard MLoversætter. Derfor foreslog de en ny tilgang til coalescg: iterativ coalescg. En oversigt over den nye algoritme er vist i figur Idéen er, at ved at udføre simplify på knuder der ikke er MOVE-relaterede 10 som i den origale Chait-allokator (se afsnit 2.4.5) håber vi på, at reducere antallet af naboer af grad k for de MOVE-relaterede knuder. Hvis det lykkes, kan der foretages konservativ coalescg. Den nye allokator består af følge tr: Build Dette foregår som tidligere beskrevet, dog markeres hver knude i grafen som enten MOVE-relateret eller ej. Simplify Knuder der har grad < k og ikke er MOVE-relaterede fjernes fra grafen og lægges på en stak. 8 Motivationen for Briggs et al. i [BCT94] var at sikre effekten af rematerialization - se evt. afsnit Diagrammet er taget fra [GA96] 10 En knude er MOVE-relateret, hvis dens tilsvare virtuelle register dgår som argument til en MOVEstruktion på noget punkt i kildeproceduren.

19 2.6 Forbedret coalescg 18 Figur 2.6 Itereret coalescg Coalesce Her udføres konservativ coalescg. Der er herefter muligvis stadig unødvige MOVE-struktioner tilbage, og nogle knuder er muligvis ikke længere MOVE-relaterede. Derfor returneres til simplify-tret. Når de eneste knuder der er tilbage er MOVE-relaterede eller har grad k, stoppes simplify-coalesce løkken. Freeze Når processen kommer hertil, er der altså ikke flere MOVE-struktioner som vi kan fjerne ved konservativ coalescg. Derfor vælges en knude af grad < k der ikke er MOVE-relateret (hvis en sådan fdes). De MOVE-struktioner, som den valgte knude forekommer i, fryses (det vil sige det opgives at fjerne dem fra kildeprogrammet). Nu er der muligvis kommet flere knuder af grad < k der ikke er MOVE-relaterede, så derfor sprger vi tilbage til simplify tret. Potential spill Hvis der ikke er nogen knude at vælge i freeze-tret, vælges en spillkandidat, og der fortsættes til næste tr. Select & Actual spill Disse tr foregår på samme måde som beskrevet tidligere. På figuren er det antaget, at der benyttes optimistisk farvng (se afsnit 2.5), men Chait s origale farvngsheuristik kan benyttes istedet Resultater Som beskrevet i afsnit vil gen af de knuder, der er resultat af konservativ coalescg, blive markeret til spill. Som en konsekvens af dette, vises det i [GA96] afsnit 5, at hvis en graf G kan farves med Chait s simplify-heuristik, så vil konservativ coalescg på en graf fremkommet ved at foretaget et antal ændrger i G via simplify, ikke ændre ved det faktum af grafen er farvelig. Dette betyder, at den beskrevne algoritme er

20 2.7 Spill-omkostnger 19 fornuftig. Det bemærkes i [GA96], at hvis man benytter pessimistisk farvng, vil den nye algoritme ikke producere nye spills (i forhold til algoritmen fra afsnit 2.4), men hvis der benyttes optimistisk farvng, kan det ikke garanteres, at der er det samme antal spills. George og Appel anfører i deres artikel [GA96] resultaterne af nogle eksperimentelle undersøgelser af deres algoritme. De konkluderer, at deres tilgang fjerner mange flere MOVE-struktioer allokatorer, der udfører coalescg før simplify, og deres ændrger må derfor anses som en forbedrg. Deres undersøgelser foregår i et miljø, hvor der er mange MOVE-struktioner i koden fra optimergs- og kodegenerergsfaserne. Forskellen i køretid ved brug af iterativ coalescg må forventes at være størst i netop sådanne situationer - da det netop er MOVE-struktioner der fjernes. I en senere artikel beskriver Leung og George et problem med hensyn til køretiden for allokatoren ved brug af iterativ coalescg: i visse tilfælde vil allokatoren iterere unødigt mange gange mellem de tre faser simplify, coalesce og freeze. De beskriver i [LG], hvordan dette kan repareres. Ændrgen har gen betydng for selve allokergen, men forbedrer køretiden for allokatoren. 2.7 Spill-omkostnger Ved brug af en allokator der bruger pessimistisk farvng (beskrevet i afsnit 2.4.5) skal der i simplify-tret vælges en knude til spill. På samme måde skal der under selectfasen af en allokator med optimistisk farvng vælges en knude der potentielt skal spilles (se afsnit 2.5). Vi vil nu beskrive forskellige måder at afgøre hvilken knude der skal vælges Defition af spill cost Valget af knuder til spill-kandidater må være styret af et ønske om at mimere den del af køretiden for det resultere program, som bruges på at eksekvere spill-kode. Det vil sige, hvis vi kan estimere den forøgelse af køretiden, som det koster at spille et virtuelt register, har vi en god chance for at foretage kvalificerede valg. Der må naturligvis være tale om en relativ vurderg af de forskellige knuder de absolutte tider afhænger helt af den konkrete maske, og er som sådan uteressante. Til at approksimere de nævnte tider dfører Chait i [Cha82] en spill cost for et virtuelt register v: cost(v) = 10 dybde(i) + 10 dybde(i) (2.1) I uses(v) I defs(v) Her angiver dybde(i) hvor mange løkker struktion I er dlejret i og uses(v) (henholdsvis def s(v)) er mængden af struktioner der læser (henholdsvis skriver) v. Dette bruges som et estimat af, hvor mange gange LOAD- eller STORE-struktionerne dsat for at spille v bliver udført. Det antages altså, at en struktion udføres 10 gange så ofte, hvis den er de i en løkke Chait s metode Alle virtuelle registre kan på den ovenfor beskrevne måde tildeles en spill cost. Men der skal mere til at styre valget af knude under simplify- eller select-trene. I Chait s