LLVM vs. C & # 8212; ; come può fondamentalmente LLVM non essere migliore per Haskell di C--?

StackOverflow https://stackoverflow.com/questions/815998

Domanda

Sono stato entusiasta di LLVM abbastanza basso da modellare qualsiasi sistema, e lo ha visto come promettente che Apple lo stesse adottando; ma poi di nuovo Apple non supporta specificamente Haskell ;

E alcuni pensano che Haskell starebbe meglio con C-- :

  

Che i LLVM non hanno risolto il problema della garbage collection a costo zero   non è troppo sorprendente.   Risolvendo questo problema rimanendo agnostici sul modello di dati   è una domanda aperta in informatica.

- LHC no usando LLVM.

È stato utile?

Soluzione

Bene, c'è un progetto all'UNSW per tradurre GHC Core in LLVM

Ricorda: 10 anni fa non era chiaro che LLVM avrebbe costruito tutta l'infrastruttura che C non era in grado di fare. Sfortunatamente, LLVM ha l'infrastruttura per il codice portatile e ottimizzato, ma non l'infrastruttura per un buon supporto linguistico di alto livello, che C-- ha (s) d.

Un progetto interessante sarebbe indirizzare LLVM da C-- ...

Aggiornamento , a partire da GHC 7, GHC utilizza LLVM per la generazione di codice . Usa il flag -fllvm . Ciò ha migliorato le prestazioni numeriche per alcuni programmi di basso livello. Altrimenti, le prestazioni sono simili al vecchio backend GCC.

Altri suggerimenti

Avendo lavorato un po 'con il nuovo backend di generazione di codice che manipola C--, posso dire che ci sono una serie di ragioni per cui C-- può essere migliore di LLVM, e anche perché non sono proprio affatto la stessa cosa.

  1. C-- opera a un livello di astrazione superiore a LLVM; ad esempio, possiamo generare codice in C, dove il puntatore dello stack è del tutto implicito e manifestarlo solo in seguito durante il processo di compilazione. Ciò rende molto più semplice l'applicazione di alcuni tipi di ottimizzazioni, poiché la rappresentazione di livello superiore consente un maggiore movimento del codice con meno invarianti.

  2. Mentre stiamo attivamente cercando di risolvere questo problema, LLVM soffre dello stesso problema che ha subito il backend via-C: ci richiede di creare punti proc. Cosa sono proc punti? Essenzialmente, poiché Haskell non utilizza la classica convenzione di chiamata call / ret, ogni volta che effettuiamo l'equivalente morale di una chiamata di sottoprocedura, dobbiamo inserire una continuazione nello stack e quindi passare alla sottoprocedura. Questa continuazione di solito è un'etichetta locale, ma LLVM richiede che si tratti di una procedura effettiva, quindi è necessario suddividere le funzioni in pezzi più piccoli (ogni pezzo viene chiamato punto proc). Questa è una brutta notizia per le ottimizzazioni, che funzionano a livello di procedura.

  3. C-- e LLVM adottano un approccio diverso all'ottimizzazione del flusso di dati. LLVM usa lo stile SSA tradizionale con i nodi-ph: C-- usa un fantastico framework chiamato Hoopl che non richiede di mantenere l'invariante SSA. Posso confermare: la programmazione delle ottimizzazioni in Hoopl è molto divertente, anche se alcuni tipi di ottimizzazioni (mi viene in mente l'inserimento di variabili usate una volta) non sono esattamente le più naturali in questa impostazione del flusso di dati.

Un problema in pratica è che LLVM è stato molto più di un bersaglio mobile.

GHC ha riscontrato dei problemi nel tentativo di supportare più versioni di LLVM. È attiva una discussione sulla mailing di ghc-dev elenco su questo.

A proposito, attualmente il backend llvm in ghc è dopo che l'Haskell è stato tradotto nel linguaggio cmm (che credo sia principalmente solo C-- esteso con alcuni registri dal linguaggio STG), e a causa di quanto sopra dovrebbe essere- affrontate le difficoltà, ci sono ottimizzazioni ridondanti in corso che rallentano la compilazione.

Inoltre, storicamente, e attualmente AFAIK, il progetto LLVM non dà priorità alla fornitura di una piattaforma portatile, e alcuni sviluppatori hanno affermato che è un compilatore IR e non una forma di linguaggio assembly portatile .

L'IR LLVM che scrivi per un target previsto potrebbe non essere affatto utile per un target diverso. Per fare un confronto, il sito Web C-- in realtà si riferisce ad esso come assemblaggio portatile. " Saresti molto più felice con un linguaggio di assemblaggio portatile che potrebbe essere ... " è una citazione da il loro sito web . Quel sito web menziona anche un'interfaccia di runtime per facilitare la implementazione portatile della garbage collection e la gestione delle eccezioni.

Quindi potresti pensare a C-- come un terreno comune portatile per tutti i front-end che ha un po 'di più in comune con il codice byte CIL e Java e LLVM IR come un terreno comune espressivo per tutti i tuoi backend che facilita l'unificazione di ottimizzazioni di basso livello comuni a più target. LLVM IR offre anche il vantaggio aggiuntivo che il progetto LLVM implementerà molte di quelle ottimizzazioni di basso livello. Detto questo, in qualche modo LLVM IR potrebbe effettivamente essere considerato di livello superiore rispetto a C--, ad esempio LLVM IR ha tipi diversi dove, come in C, tutto è solo un po 'di vettori.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top