ACM SIGPLAN ocenila GCC (diskuse)

[unicode]

Ale stejně je lepší investovat čas do clang

[Miloslav Ponkrác]

Není. Protože jeho architektura neumožňuje vymáčknout při kompilaci do binárky maximální optimalizace, tedy ani nemůže mít ani maximální rychlost.

Důvod, proč člověk používá jazyky jako C/C++/Fortran je mimo jiné ten, že chce vymáčknout z binárky maximální rychlost.

Až půjde do tuhého, gcc bude nakonec vždy rychlejší, protože nemá limitaci v možnostech implementace optimalizací by design jako llvm/clang.

Přijde doba, kdy se to řekne naplno a bude to obrovské „nečekané“ zklamání.

Proto je lépe dát hlavní energii gcc. To druhé si nechat jako možnost rychlé implementace nových jazyků, kde rychlost není klíčová.

Je dobré se občas zamýšlet nad vlastnostmi programů, ne jenom nad tím, že je něco cool, wow, a všude se o tom kladně píše.

Miloslav Ponkrác

[nyan]

Ano to vsechno je pravda - za predpokladu ze rychlost vysledne binarky je to nejdulezitejsi. Obavam se ale ze jiny lide muzou mit jine priority.

[roman]

A v cem presne je ta architektura tak zvlastni ze to neumoznuje? Podle mne je to blbost.

Ano, LLVM ma nektera omezeni, ale gcc taky nemuze delat vse. V podstate jsou 2 takova hlavni omezeni (o kterych vim), inliner nemuze pouzivat analyzy (na tom se pracuje, prepisuje se pass manager), codegen vidi jenom jeden basic block zaraz (na to jsou plany).

Gcc ma zase jine omezeni.

Ale zadna principielni/neresitelna omezeni llvm nema, narozdil od podle meho nazoru gcc, ktere ma tak vysoky technical debt ze je dle meho nazoru neopravitelne.

[Bedňa]

Lepšie ako porovnávanie pindíkov je slobodný grupen sex, aby sme mali možnosť to najlepšie vylepšiť.

[Honz]

Ale mělo by se střídat, někteří už dvakrát kouřili...

[Bedňa]

Hoď to do bugzilly.

[lertimir]

Zkusili jste někdo porovnat jaký je rozdíl vy výsledném kódu (rychlost, velikost) mezi gcc, clang a intel C++ compiler?

[Hans1024]

Phoronix porovnava gcc a clang kazdou chvili. Vetsinou v optimalizacich vede gcc a rychlejsi kompilaci ma clang.

[Jakub Galgonek]

Asi dost záleží na tom, co kompiluješ. Nějaké systematické srovnání jsem nedělal, ale během "flame war" na rootu jsem něco zkoušel. Třeba násobení matic přeložené g++ běželo 64 sekund, ale verze kompilovaná icc běžela pouhých 0.85 sekund. Ale třeba sadu RMSD mi g++ verze počítala 2.64 sekund, ale icc verze na to potřebovala 5.58 sekund.

[g.g]

Třeba násobení matic přeložené g++ běželo 64 sekund, ale verze kompilovaná icc běžela pouhých 0.85 sekund.

Tak tohle vypadá jako problém, který by zasloužil podrobnější diagnózu. ICC má možná (nevím...) o něco lepší autovectorizer, ale tohle zní jako patologický případ, nemyslíte? (Zkoušel jste to disassemblovat?)

[Jakub Galgonek]

Šlo o naivní násobení matic velikolsti 2000x2000. Co jsem tehdy koukal, tak těch pět řádků, co provádí samotné násobení, to rozvinulo na asi 1100 řádků assembleru. A více jsem to nezkoumal.

[Hans1024]

A s jakymi optimalizacemi jste to kompiloval?

[Jakub Galgonek]

Volby byly, tuším, -O3 -march=native a pouštěl jsem to na Core i7 (3630QM).

[Hans1024]

Hmm, leda me napada, ze by icc pouzival automaticky neco na zpusob -ffast-math. Ale ani to by asi neudelalo tak markantni rozdil. 64 vs 0.85 sekund - to skoro vypada, ze si icc proste spocital vysledky pri kompilaci - jestli teda byly ty matice nejak konstantne zadane.

[Hans1024]

Tak jsem se docetl, ze pry

ICC by default uses a ‘fast-math’ like mode.

[Jakub Galgonek]

Koukal jsem se znovu do té diskuze, to násobení bylo celočíselné, takže vliv -ffast-math v tom nebude. Když si nechám vygenerovat instrukce, výstup icc je mnohem delší, takže bych tipoval, že icc dělá (lepší) loop unroling. Další věcí je, že to násobení je dost naivní, pokud by druhá matice byla již transponovaná, g++ by to dalo za asi 2.2 sekundy.

[Jakub Galgonek]

Při kompilaci si to určitě nespočítal, protože data se načítala ze souboru.

[krab1k]

Vysvětlení je podle mě trochu jinde: ICC provádí loop interchange (ICC o těchto věcech informuje s flagem -opt-report=hlo). Přesněji cykly přes (i, j, k) nahradí cykly přes (i, k, j). Konkrétně tahle úprava optimalizuje přístup k prvkům matice B ve výrazu C[i][j] += A[i][k] * B[k][j].

Nejrychleji měnící se index je pak j, takže oproti původní verzi přistupujeme k prvkům, které jsou v paměti vedle sebe.

[Jakub Galgonek]

Díky, zkusil jsem to znovu přeložit a opravdu icc hlásí LOOP INTERCHANGE. Když ty smyčky předělám ručně, g++ to najednou zvládne za 3.16 sekund.

PS: Ten divně formátovaný kód není můj.

[g.g]

Hmm, a zkoušel jste použít -floop-interchange?

[Jakub Galgonek]

Ne, ani pro to nemám v gcc podporu. Ale tak doplním ji a zkusím.

[Jakub Galgonek]

Tak -floop-interchange u g++ na to nemá vliv.

[g.g]

Hmm. Tak to je asi buď námět na dotaz v mailing listu GCC, nebo případně na bug report, pokud to nedělá něco, co to dělat má.

[Miloslav Ponkrác]

„Zkusili jste někdo porovnat jaký je rozdíl vy výsledném kódu (rychlost, velikost) mezi gcc, clang a intel C++ compiler?“

Rychlost:

To je jednoduché. Intel C++ je daleko napřed přede vším. O něco horší je Microsoft C++. Ještě horší a pomalejší je gcc, ale už ne o mnoho, poslední verze gcc jsou mnohem lepší v optimalizaci.

A clang má postavenou architekturu tak, že to natvrdo a přímo omezuje výslednou množinu aplikovatelných optimalizací přímo v jeho designu. Takže pokud gcc nezaspí, bude clang vždy pomalejší a dávat horší binárky. By design má clang limitovánu rychlost výsledné binárky.

Velikost:

Co se týká velikosti, na to už dnes kašle pes. Žádný kompilátor neumí dobře optimalizovat na malou velikost, respektive se implementace této varianty v kompilátorech šidí. Není to třeba. Obecně platí, že nejrychlejší binárky jsou obvykle větší, než středně rychlé.

Miloslav Ponkrác

[JoHnY3]

Nasel by se nekde benchmark MSVC, GCC a idealne i ICC? Posledni co jsem videl bylo snad GCC 2.9 vs MSVC7.

[Miloslav Ponkrác]

Určitě jich najdete na webu mnoho. V zásadě je třeba porovnávat porovnávatelné.

GCC se hodně zlepšil, ještě před pár lety byla jeho optimalizace opravdu hodně špatná. Dnes už šlape na paty Microsoft C++.

Ve všech banchmarkách je ale gcc za msvc. Intel je zase vždy rychlejší, než msvc, a v krajním případě i dvojnásobně – měřeno průměrnými benchmarky.

Intel je velice dobrý v optimalizaci.

Z praktického používání: Msvc je dobrý na hlášení chyb, je v tom mnohem lepší, než gcc.

Ale potěšilo mě, že gcc udělalo v optimalizaci opravdu obrovský skok dopředu. Z trabanta před pár lety na Ferrari. Nicméně konkurence taky nespala, takže stále nikoho nepředběhl kromě clangu.

Miloslav Ponkrác

[Martin Mareš]

Ve všech banchmarkách je ale gcc za msvc. Intel je zase vždy rychlejší, než msvc, a v krajním případě i dvojnásobně – měřeno průměrnými benchmarky.

Pozor, tohle je dost zkreslené použitou sadou benchmarků. O ICC se tuší, že jejich vývojový tým tráví obrovské množství času optimalizováním překladu standardních benchmarků, takže na reálných programech dopadne srovnání překladačů často jinak, zvlášť pokud nekompilujete pro procesor od Intelu, ale od AMD :)

Mé osobní testy naznačují, že ICC je sice hodně dobré, ale že GCC ho v mnoha konkrétních případech předhoní. Zejména díky globálním optimalizacím, ve kterých se GCC za posledních pár let výrazně zlepšilo.

[Marvin]

By design má clang limitovánu rychlost výsledné binárky.

Jak konkretne?

[Miloslav Ponkrác]

Jakýkoli kompilátor, který si zafixuje mezijazyk je tímto omezen. Lépe se to programuje, ale kvalita výstupního kódu je tím limitována k horšímu.

A pak záleží na vyjadřovací síle toho mezijazyka, jestli vymáčknutelné maximum při optimalizace je o hodně horší, nebo jen mírně nižší, než u kompilátorů, které toto nedělají.

---

V zásadě existence gcc × clang startuje přesně to, co jsem před lety předpovídal, a za co je mi nadáváno.

Komerční firmy, stejně jako řada vývojářů, nebudou podporovat GPL licencované projekty. Raději si založí vlastní konkurenční pod méně restriktivní licencí.

Na clang se vrhla řada firem pro vývoj právě proto, že výsledek mohou použít ve svých projektech bez toho, aby projekt musel být také gpl.

Ale přesto, že na clang je vrhnuto hodně peněz a vývojářské síly, stále ne a ne rychlostně ve výsledné binárce natrhnout gcc zadek. Protože, jak už jsme psal, architektura, která používá pevně zafixovaný mezijazyk, prostě nejlepší kód nikdy nevygeneruje. Vždy bude horší, než od kvalitního kompilátoru, který toto v architektuře neudělal.

Miloslav Ponkrác

[Jakub Galgonek]

Zkusil jsem teď svůj kód pro výpočet sady RMSD přeložit ještě pod clang. No, výsledky jsou fakt zajímavé:

clang++ 3.4.1 : 1.84s
g++ 4.7.3     : 2.60s
icc 13.1.3    : 4.83s

Ve všech případech byl kód přeložen s parametry -O3 -march=native (pro Core i7 3630QM).

[Miloslav Ponkrác]

Jen neznalý člověk se může domnívat, že max. optimalizaci získá bez důsledného nastavení parametrů překladu.

Čím je kompilátor schopnější v optimalizaci, tím citlivější je na parametry překladu. Vlastně je to důkaz dobře optimalizujícího kompilátoru, že nemá volby jen pro srandu králíkům a citlivě to na ně reaguje.

Rychlost překladu je nepřímo úměrná kvalitě kódu. Proto defaultně dobré kompilátory moc neoptimalizují.

[deda.jabko]

Rychlost překladu je nepřímo úměrná kvalitě kódu. Proto defaultně dobré kompilátory moc neoptimalizují.

Jinak doufám, že si s touto větou děláte srandu. Jako vtip je to dobré.

[Jakub Galgonek]

Klidně mi nějakou kombinaci parametrů doporuč a já ji rád vyzkouším. Testovací program a data ti mohu poslat třeba na mail (jsou to jen čtyři soubory). Pár svých oblíbených parametrů jsem zkoušel, ale v podstatě bez efektu.

[Miloslav Ponkrác]

První inspirace:

http://willus.com/ccomp_benchmark2.shtml?p3

[Jakub Galgonek]

Tyhle základní flagy jsem už zkoušel - bez výrazného efektu. Zkusil jsem i nejnovější verzi icc (14.0.3), ale ta dopadla ještě hůře (5.19s).

[Miloslav Ponkrác]

Ještě jednu poznámku: Řada kompilátorů je schopna optimalizovat nejen při kompilaci, ale také při linkování. Tedy zoptimalizovat celý program globálně na konci. U Microsoft C++ jsem to zkoušel, a běžně to hodí 10 % rychlosti nahoru u praktických testů.

[Jakub Galgonek]

Myslíš -ipo? U icc 14.0.3 to stáhne na nějakých pět sekund. U té starší verze jsem nepozoroval rozdíl.

[g.g]

Jestli pořád ještě na GCC funguje Acovea, možná si to můžete nechat vygenerovat sám.

[Jakub Galgonek]

Vypadá to zajímavě, ale bohužel už docela zastarale/mrtvě.

[deda.jabko]

A pak záleží na vyjadřovací síle toho mezijazyka, jestli vymáčknutelné maximum při optimalizace je o hodně horší, nebo jen mírně nižší, než u kompilátorů, které toto nedělají.

LLVM i GCC pouzivaji IR zalozenou na SSA, ergo jejich moznosti optimalizovat jsou +/- stejne. IMHO kvalita vystupniho kodu je spis dana poctem clovekohodin, ktere byly do toho ktereho prekladace vlozeny.

[Miloslav Ponkrác]

Znovu zopakuji klíčový termín z toho, co jsem napsal: „pevně definovaný mezijazyk“.

Popřípadě upozorním na rozdíl mezi „pevně daný mezijazyk“ a mezijazyk, který je možné měnit.

Nějakou formu mezijazyka má každý kompilátor, protože na nějaké formě mezijazyka se ta optimalizace provádět musí.

---

Kvalita výstupního kódu samozřejmě závisí nejen na formě člověkohodim, ale také na fyzikálních zákonech a limitech architektury. Ne vše jde zlepšovat donekonečna dolarovými vycpávkami.

[deda.jabko]

Znovu zopakuji klíčový termín z toho, co jsem napsal: „pevně definovaný mezijazyk“.

Uvedomte si, ze vase tvrzeni o nevhodnosti pevne dane IR jsou jen vase domenky, ktere vydavate za fakt.

Ve skutecnosti IR LLVM je mnohem expresivnejsi nez v pripade GCC.

[Miloslav Ponkrác]

Vy jste schopen popřít i to, že ráno vychází Slunce.

Dejte si 2 zadání na překlad z češtiny do japonštiny.

1) Zadejte překladatelské firmě, že chcete zajistit perfektní překlad z češtiny do japonštiny. Detaily necháte na nich, ať si to vnitřně zařídí jak chtějí. (Obdoba gcc.)

2) Zadejte jedné překladatelské firmě, že chcete zajistit perfektní překlad z češtiny do eskymáčtiny. Zadejte druhé překladatelské firmě, že chcete zajistit perfektní překlad z eskymáčtiny do japonštiny. Máme zde pevný jazyk, na jehož neměnnosti trváme, v tomto případě eskymáčtinu. A pak ty dva překlady v simultánním tlumočení zřetězíme. (Odboda clang/llvm).

Myslím, že i nepočítačový člověk jasně chápe, který překlad dopadne lépe, bude kvalitnější.

Howgh.

Dál už toto téma nebudu dokazovat, protože je to jasné jako facka. Myslete si o tom co chcete, uvidíme za pár let, až bude llvm pomalu přiznávat a poleze to z něho jako z chlupaté deky, že existuje limit optimalizace, který nejde z principu překročit tak, jak byl postaven.

Miloslav Ponkrác

[deda.jabko]

To je jako cist nejakou bibli, hromada metafor a fakta zadna.

nepočítačový člověk jasně chápe

Takto to chape asi nepocitacovy clovek. Nicmene realita je malinko jina, protoze i IR v GCC je de facto pevne dana (jen to mozna nevite), takze tady popirate vlastne sam sebe.

Pocitacovy clovek vi, ze k ziskani dobreho vysledku jsou dulezite datove struktury a s nimi pracujici algoritmy. Jelikoz v LLVM i GCC se pouziva reprezentace zalozena na SSA, mnozina pouzitelnych optimalizacnich algoritmu je stejna.

[Miloslav Ponkrác]

Analogicky: Protože nejrychlejší sprinter světa, stejně jako 90letá šouravá babka po osteoporóze používá pro pohyb stejný zpsob, který reprezentují „2 nohy“, pak z toho vyplývá, že oba lidé budou stejně rychlí.

Přestaňte už s těmi hovadinami. Nedělejte ze sebe hlupáka, a chovejte se trochu inteligentně. Věřím, že jste chytrý člověk, jen zášť vůči mě z Vás dělá blba v diskusi.

[deda.jabko]

Kdyz nekdo placa blbosti a sve domenky vydava za fakta, neznamena to, ze mam vuci nemu zast.

[Miloslav Ponkrác]

Ještě by se dalo dodat, že kdyby llvm architektura umožňovala lepší optimalizaci, tak už jí šupito presto začne používat jak Intel, tak Microsoft. Ale oni nemají tendenci se jí inspirovat a dobře vědí proč.

Ale jak Intel, tak Microsoft se drží staré cesty, a optimalizují mnohem lépe, než open source kompilátory.

Když už máte drzé čelo, proč tito velcí hráči nepřecházejí na clang/llvm princip? Odpověď zní, protože neumožňuje udělat tak dobrý kompilátor.

[OldFrog {Ondra Nemecek}]

Tohle přirovnání je sice logické a pravděpodobné, ale samo o sobě nic nedokazuje. Jde přeci pouze o to, které informace se ztratí při překladu do mezijazyka a které informace dokáže kompilátor v mezijazyku při optimalizaci zohlednit.

Takže seriózním argumentem by bylo pouze porovnání těch mezijazyků a jejich dalšího zpracování u obou poropvnávaných kompilátorů.

[Miloslav Ponkrác]

Znovu. clang/llvm má pvně daný mezijazyk přímo jako součást standardu projektu. Když zjistíte jeho nedostatky, vylepšovat ho budete těžko.

Gcc, bez ohledu na to, co je v něm DNES, nemá pevně daný mezijazyk. Jeho změna či úprava je možná, ač to bude bolet.

Kromě toho, RTL v gcc je zaměřen na to, aby byl blízko strojového kódu, tedy co nejlépe optimalizovatlený.

Naopak llvm má „llvm assembler“ poněkud dále od strojového kódu.

---

Stejně tak stačí mezijazyky porovnat, trváte-li na tom:

https://gcc.gnu.org/onlinedocs/gccint/RTL.html http://llvm.org/docs/LangRef.html

---

Chápu, že se lidem strašně chce věřit, že jednou bude llvm stejně dobrý v optimalizacích jako gcc. Nebude. Clang/llvm nikdy gcc rychlostně nedožene, protože jeho mezijazyk není dělám proto, aby umožnil co nejlepší optimalizaci.

llvm má mezijazyk jako standarndí rozhraní a jako jeden jazyk, který můžete používat. Llvm má v zásadě úplně stejnou konmcepci jako .NET nebo Java. Principiálně se tyto 3 projekty od sebe nijak neliší. Zavedli nějaký „assembler“, který je schopen chroustat. Vše ostatní musí zařídit kompilátory.

A stejně tak jako Java, tak Microsoft, tak llvm nadšenci prohlašují a budou prohlašovat, že rychlostně překonají céčko a stroják, tak se tak nikdy nestalo a nikdy nestane.

Už jenom proto, že mezijazyk je pevný a jeho účelem je umožnit jednoduchou kompilaci, optimalizace je druhořadá při návrhu toho mezijazyka.

Ale když to řeknu naplno, llvm je kripl architektově a kripl možnostmi toho mezijazyka. A to se s ním ponese a nikdo to neodpáře.

A už se k tomu nebudu dále vyjadřovat. Čas ukáže tuhle pravdu jasně.

---

Miloslav Ponkrác

[deda.jabko]

clang/llvm má pvně daný mezijazyk přímo jako součást standardu projektu. Když zjistíte jeho nedostatky, vylepšovat ho budete těžko.

Kdyz se zjisti nedostatky v pripade IR u LLVM, tak se zmeni IR a vyda se nova verze a budou se muset upravit vsechny front-endy.

Kdyz se zjisti nedostatky v pripade IR u GCC, tak se zmeni IR a vyda se nova verze a budou se muset upravit vsechny front-endy.

Nejdete deset rozdilu.

Kromě toho, RTL v gcc je zaměřen na to, aby byl blízko strojového kódu, tedy co nejlépe optimalizovatlený

Uz jsme doma! Vite, pise se rok 2014 a GCC vypada uplne jinak, nez v minulem stoleti.

Stejně tak stačí mezijazyky porovnat, trváte-li na tom:

https://gcc.gnu.org/onlinedocs/gccint/RTL.html

Bylo by dobre podivat se o kapitolu vys: https://gcc.gnu.org/onlinedocs/gccint/Tree-SSA.html#Tree-SSA

Ale ja vam to vysvetlim, at se tu priste neztrapnujete: Kod je prolozen do interni reprezentace, ktera se oznacuje jako (GENERIC/GIMPLE), ktera je naprosto nezavisla na jazyku i cilove platforme (stejne jako v pripade LLVM), nad tim se dela spoooousta optimalizaci a pak je prelozena do RTL a az z toho se generuje binarka.

Llvm má v zásadě úplně stejnou konmcepci jako .NET nebo Java.

To je fakt hodne prehnane pripodoneni.

llvm má mezijazyk jako standarndí rozhraní a jako jeden jazyk, který můžete používa

LLVM ... odpovida back-endu gcc, clang ... front-endu v gcc. V cem je problem?

optimalizace je druhořadá při návrhu toho mezijazyka.

Zajimave... a pritom LLVM vzniklo puvodne jako vyzkumny projekt zamereny na optimalizace....

[OldFrog {Ondra Nemecek}]

Já nehájím žádný překladač, na mě pouze nepůsobí Vaše argumentace důvěryhodně. Okolnosti změny mezijazyka přece ještě nic nevypovídají o stávající rychlosti - možná tak o flexibilitě možných vylepšení optimalizace v budoucnu. Dokud bych si neověřil možnosti a omezení mezijazyka, tak bych Vám prostě nevěřil.

[kralyk z abclinuxu]

Gcc, bez ohledu na to, co je v něm DNES, nemá pevně daný mezijazyk.

Aha, a GENERIC+GIMPLE se mažou na chleba, že...

[deda.jabko]

Ještě by se dalo dodat, že kdyby llvm architektura umožňovala lepší optimalizaci, tak už jí šupito presto začne používat jak Intel, tak Microsoft. Ale oni nemají tendenci se jí inspirovat a dobře vědí proč.

Jako by se stalo. :-]] Ve skutecnosti GCC s verzi 4.0 presel na architekturu, ktera odpovida LLVM.

[Miloslav Ponkrác]

Vidíte, dáváte mi zcela zapravdu.

Gcc může přejít na jiný mezijazyk. Není to problém. Protože NENÍ NAPEVNO. Protože je možné mezijazyk změnit, vylepšit. A gcc to může udělat. Protože mezijazyk není API gcc kompilátoru. Po změně mezijazyka to uživatel gcc nijak nepozná navenek, jen to lépe optimalizuje.

Kdykoli gcc může mít lepší mezijazyk, když zjistí, že ho potřebuje.

Clang/llvm má mezijazyk jako součást API kompilátoru. Když ho bude chtít změnit, tak jedině tak, že llvm jako projekt zanikne jako celek. A pojede se od nuly jinde.

Já sice chápu, že deda.jablko mě osobně nesnáší, a proto bude v opozici, i když tvrdím to samé co on, ale už to deda.jablko fakt přehání, a nemusím si také všechno nechat líbit. A protože nejsem zastánce útoků ad hominem a dělání ze sebe blbého, jako dělá deda.jablko, a nechci se snížit na stejnou úroveň diskusi, tak už na deda.jablko reagovat nebudu. Myslím, že jsem vše podstatné napsal.

[deda.jabko]

Vidíte, dáváte mi zcela zapravdu.

Ne.

Když ho bude chtít změnit, tak jedině tak, že llvm jako projekt zanikne jako celek. A pojede se od nuly jinde.

Tohle je falesna dichotomie.

Já sice chápu, že deda.jablko mě osobně nesnáší,

To je nesmysl. Ve skutecnosti jste mi uplne lhostejny.

[g.g]

To je nesmysl. Ve skutecnosti jste mi uplne lhostejny.

Vsadím se, že kdybyste ho nesnášel, řekl byste mu právě tohle, jen abyste ho naštval.

[g.g]

Nejsem si úplně jist (a rozhodně se v tom nevyznám ), ale nepoužívá GCC více mezijazyků už teď, čistě proto, že na různých mezijazycích se jednotlivé optimalizace dělají různě efektivně?

[deda.jabko]

Ano.

[Martin Mareš]

A kdo vám nakukal, že celý překladač musí používat stejný mezijazyk? Například uvnitř GCC se jich používá vícero: RTL, Tree-SSA, GIMPLE, polyedrální reprezentace cyklů atd. Ani LLVM nic nebrání v tom, aby uvnitř některých optimalizačních průchodů změnilo reprezentaci programu tam a zase zpátky.

Jak vás tak poslouchám, viděl jste vůbec někdy nějaký překladač uvnitř?

[roman]

No, vidim ze pan Ponkrac ukazal ze compilerum naprosto nerozumi. Ja jen doplnim, stejne jako ruzne "jazyky" ma gcc, tak ruzne jazyky ma i llvm.

minimalne klasicke IR, SDAG, MInstr.

To jen pro doplneni.

[Miloslav Ponkrác]

„LLVM i GCC pouzivaji IR zalozenou na SSA, ergo jejich moznosti optimalizovat jsou +/- stejne.“

Jinak doufám, že si s touto větou děláte srandu. Jako vtip je to dobré.