LLVM izstrādātājs Erich Keane piedāvājis būvēt ClangIR līdzi Clang bez papildu karodziņiem. Pati koda ģenerēšana no tā nemainās. Mainās būvējuma sastāvs: MLIR kļūst par obligātu Clang atkarību ikvienam, kas kompilē Clang no pirmkoda.
Cenu var nolasīt RFC sarakstē LLVM Discourse forumā. Sākumā tur runāja par aptuveni trešdaļas pieaugumu. Precizētie mērījumi rāda 75 līdz 130 % lielāku būvēšanas laiku atkarībā no konfigurācijas. Maksimālais atmiņas patēriņš aug par 209,6 %. Būvējuma mape no aptuveni 2 GB izaug līdz 4 GB. Ninja būvējumam nāk klāt ap 2134 papildu vienībām.
Kāpēc Clang vajadzīga vēl viena starprepresentācija
Šobrīd Clang no abstraktā sintakses koka ģenerē LLVM IR vienā solī. Tajā pazūd liela daļa C un C++ semantikas. Klašu struktūra, izņēmumu robežas un tipu informācija LLVM līmenī vairs nav atjaunojama, jo LLVM IR par tādām lietām neko nezina. Optimizētājs strādā ar to, kas pāri palicis.
ClangIR šo soli sadala. Vispirms Clang izveido uz MLIR balstītu attēlojumu, kas paliek tuvu avota kodam. Tikai pēc tam attēlojums tiek pazemināts līdz LLVM IR. Ideja nav jauna. Bruno Cardoso Lopes to LLVM forumā izklāstīja 2022. gada 20. jūnijā. Kopš tā laika kods pakāpeniski nonācis LLVM pirmkoda kokā, taču ārpus noklusējuma būvējuma konfigurācijas.
No tā izriet vairākas praktiskas lietas. Diagnostika var norādīt uz konstrukciju avota kodā; līdz šim tā rādīja uz jau saplacinātu instrukciju plūsmu. Statiskā analīze redz tipus, ko LLVM IR vairs neatšķir. Optimizētājs var paļauties uz C++ garantijām, kuras līdz šim tika izmestas, pirms tas vispār sāka darbu.
MLIR pamats atver arī otru virzienu. No MLIR kodu var pazemināt uz SPIR-V vai Vulkan. Tas padara ClangIR par iespējamu ceļu GPU un citu paātrinātāju koda ģenerēšanai, ko Clang līdz šim risināja ar atsevišķām rīku ķēdēm.
Ko priekšlikums maina CMake līmenī
Izmaiņu pieprasījums #221291 liek LLVM koka konfigurācijai MLIR pievienot automātiski, ja vien tas nav skaidri izslēgts. Kas negrib, tam paliek karodziņš -DCLANG_ENABLE_CIR=Off. Izmaiņu pieprasījumā ir viens commit un tas skar tikai būvējuma konfigurāciju.
Svarīgs ir otrs slānis. ClangIR būvēšana vēl nenozīmē ClangIR lietošanu. Lai kompilators tiešām ietu caur jauno starprepresentāciju, joprojām jāpadod -fclangir. Bez šī karodziņa ClangIR aizņem vietu diskā un neko vairāk nedara. Neviena esošā būvējuma izvade pēc šīs izmaiņas nemainās.
Keane norāda uz Flang kā precedentu. Flang jau tagad velk MLIR līdzi un tā būvējums krīt ar kļūdu, ja MLIR nav iekļauts. Recenzents boomanaiden154 tieši par to vaicāja izmaiņu pieprasījuma sarakstē.
Kur diskusija aizķērās
Iebildumi sanāca konkrēti. Izstrādātājs aengelke izmērīja būvēšanas laiku savās sistēmās un ieguva vairāk nekā divkāršojumu. Viņa arguments neaprobežojas ar skaitli. ClangIR optimizācijas pagaidām lielākoties skar standarta bibliotēkas kodu. Tās datu struktūras, ko lielie projekti raksta paši, no jaunā ceļa iegūst maz.
Būvēšanas laiks vairāk nekā divkāršojas. Tas pasliktina pieredzi izstrādātājiem ar vājāku aparatūru. Ieguvums šo cenu neatsver.
Izstrādātājs jhuber6 iebilda pret pašu obligāto MLIR atkarību. MLIR sastāv no lieliem failiem, kas uz vājākām mašīnām kompilējas lēni. Pilnvērtīga slodzes izpēte pirms priekšlikuma nav veikta.
Tom Stellard uzdeva vienkāršāko jautājumu: kāpēc ClangIR jābūvē visiem, ja pietiktu to ieslēgt CI būvējumos. Jauns LLVM lietotājs par karodziņu -DCLANG_ENABLE_CIR=Off neko nezina un vienkārši gaidīs divreiz ilgāku būvējumu.
Skaitļi šeit nav akadēmiski. Pilnu LLVM koku ar Clang no pirmkoda būvē distribūciju pakotņu uzturētāji, uzņēmumu iekšējās kompilatoru komandas un ikviens, kas kompilatorā labo kļūdu. Pieaugums par 75 līdz 130 % maina, cik reižu dienā to var atļauties izdarīt.
Cik tālu ClangIR reāli ir ticis
Testu skaitļi RFC sarakstē izskatās labi. LLVM test-suite SingleSource daļa ar -fclangir iziet vairāk nekā 98 % apmērā, MultiSource daļa iziet pilnībā. libcxx testu komplekts uzrāda 98 % veiksmes. Iekšējie testu komplekti dod 99 % un vairāk paritāti ar parasto Clang.
Viens skaitlis uz šī fona izceļas. Otrās pakāpes pašbūvējums, kur ClangIR kompilē pašu LLVM, tiek galā ar aptuveni 30 % darba. Tas ir mērs tam, cik daudz reāla C++ koda jaunais ceļš vēl nespēj pārstrādāt. Testu komplekti sastāv no maziem, mērķtiecīgiem gabaliem. LLVM pirmkods ir miljoni rindu ar šablonu metaprogrammēšanu un dziļām mantojuma hierarhijām.
Windows paliek malā
ClangIR trūkst mērķa microsoft, tāpēc Windows būvējumi izmaiņu pieprasījumā krīt. Uz to sarakstē norādīts kā lieta, kas jāsakārto pirms pieņemšanas. Otrs neatrisinātais punkts ir CI. ClangIR testi paildzina katru pārbaudes ciklu, ko LLVM infrastruktūra izpilda par katru iesūtīto izmaiņu.
Par diskusiju 6. septembrī rakstīja Michael Larabel portālā Phoronix. Izmaiņu pieprasījums #221291 joprojām ir atvērts.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.