LLVM vs. C--; come può LLVM fondamentalmente non essere migliore per Haskell rispetto a C--?

Question

Sono stato entusiasta del fatto che LLVM sia stato sufficientemente basso per modellare qualsiasi sistema, e l'ho visto come promettente che Apple lo stava adottando; ma di nuovo Apple non supporta in modo specifico Haskell;

E, alcuni pensano che Haskell sarebbe stato meglio con C--:

Che LLVM'ers non hanno risolto il problema di zero spese generali garbage collection non è troppo sorprendente. Risolvere questo problema rimanendo indipendente dal modello di dati è una questione aperta in informatica.

- LHC won't be using LLVM.

Answer 1

Beh, c'è un progetto a UNSW di tradurre GHC Core LLVM

Ricordate: non era chiaro 10 anni fa che sarebbe LLVM costruire tutte le infrastrutture C - non è stato in grado di 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 quello di indirizzare LLVM da C-- ...

---

aggiornamento, come di GHC 7, GHC uses LLVM for code generation. Utilizzare il flag -fllvm. Ciò ha migliorato le prestazioni numeriche per alcuni programmi di basso livello. Altrimenti, le prestazioni sono simili al vecchio backend GCC.

Answer 2

GHC ora ha ufficialmente un backend LLVM, e risulta che è competitive with the GCC and native-codegen and actually faster in some cases. E il progetto LLVM has accepted the new calling convention creato da David Terei per Haskell su LLVM, così straordinariamente, i due progetti stanno attualmente lavorando insieme.

Answer 3

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

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

2. Mentre stiamo cercando attivamente di risolvere questo problema, LLVM soffre dello stesso problema del back-end via-C: ci richiede di creare punti proc . Cosa sono i punti proc? Essenzialmente, poiché Haskell non usa la classica convenzione di chiamata/ret call, ogni volta che facciamo l'equivalente morale di una chiamata di subprocedure, dobbiamo spingere una continuazione nello stack e poi saltare alla subprocedure. Questa continuazione di solito è un'etichetta locale, ma LLVM richiede che sia una procedura reale, quindi è necessario suddividere le funzioni in parti più piccole (ogni pezzo viene chiamato punto proc). Questa è una cattiva 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 utilizza lo stile SSA tradizionale con i phi-nodes: C-- utilizza un framework di tipo Hoopl che non richiede il mantenimento dell'invarianza SSA. Posso confermare: l'ottimizzazione della programmazione in Hoopl è molto divertente, anche se alcuni tipi di ottimizzazioni (l'inline delle variabili utilizzate una sola volta mi vengono in mente) non sono esattamente le più naturali in questa impostazione del flusso di dati.

Answer 4

Una questione in pratica è che LLVM è stato molto più di un obiettivo mobile.

GHC ha avuto qualche problema nel tentativo di supportare più versioni di LLVM. C'è uno discussion attivo sulla mailing list ghc-dev su questo.

Btw, attualmente il back-end di llvm in ghc è dopo che Haskell è stato tradotto in linguaggio cmm (che credo sia per lo più solo C-- esteso con alcuni registri dal linguaggio STG), e grazie a quanto sopra - difficoltà affrontate, vengono eseguite ottimizzazioni ridondanti che rallentano la compilazione.

Inoltre, storicamente, e attualmente AFAIK, il progetto LLVM non ha la priorità di fornire una piattaforma portatile, e alcuni sviluppatori hanno fatto un punto di articolazione che è is a compiler IR and not a form of portable assembly language.

L'IR LLVM che si scrive per un target intenend 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 their website. Quel sito web menziona anche un'interfaccia runtime per facilitare l'implementazione della raccolta dati inutili e la gestione delle eccezioni.

Quindi si potrebbe pensare a C-- come un terreno comune portatile per tutti i front-end che ha un po 'più in comune con il codice byte CIL e Java e LLVM IR come un terreno espressivo comune per tutti i tuoi backend ciò facilita l'unificazione delle ottimizzazioni a basso livello comuni a più obiettivi. LLVM IR offre inoltre il vantaggio aggiuntivo che il progetto LLVM implementerà molti di questi bassi livelli di ottimizzazione. Detto questo, in qualche modo LLVM IR potrebbe effettivamente essere considerato un livello più alto di C--, ad esempio LLVM IR ha tipi diversi dove come in C-- tutto è solo bit vettori.