LLVM vs. C & # 8212; ; comment LLVM ne peut-il fondamentalement pas être meilleur pour Haskell que C--?

Question

J'ai été enthousiasmé par le fait que LLVM soit suffisamment bas pour modéliser n'importe quel système, et l'a vu comme prometteur que Apple l'adoptait; mais là encore, Apple ne prend pas spécifiquement en charge Haskell ;

Et certains pensent que Haskell aurait intérêt à utiliser C-- :

  

Que les LLVM'ers n'ont pas résolu le problème de la récupération de place nulle   n'est pas trop surprenant.   Résoudre ce problème tout en restant agnostique du modèle de données   est une question ouverte en informatique.

- Le LHC ne le fera pas utiliser LLVM.

Answer 1

Eh bien, il y a un projet chez UNSW pour traduire GHC Core en LLVM

Rappelez-vous: il n’était pas clair il y a 10 ans que LLVM construirait toute l’infrastructure que C-- n’a pas pu. Malheureusement, LLVM dispose de l’infrastructure nécessaire pour obtenir du code portable optimisé, mais pas de celle qui prend en charge les langages de haut niveau, C-- ha (s) d.

Un projet intéressant serait de cibler LLVM à partir de C-- ...

.

Mise à jour , à partir de GHC 7, GHC utilise LLVM pour la génération de code . Utilisez l'indicateur -fllvm . Cela a amélioré les performances numériques de certains programmes de bas niveau. Sinon, les performances sont similaires à celles de l’arrière-plan GCC.

Answer 2

Après avoir travaillé un peu avec le nouveau système de génération de code qui manipule C--, je peux dire qu'il existe un certain nombre de raisons pour lesquelles C-- peut être meilleur que LLVM, et aussi pourquoi ils ne sont pas vraiment les mêmes. chose.

1. C-- fonctionne à un niveau d'abstraction plus élevé que LLVM; Par exemple, nous pouvons générer du code dans C-- où le pointeur de pile est entièrement implicite et ne le manifester que plus tard au cours du processus de compilation. Cela facilite grandement l’application de certains types d’optimisation, car la représentation de niveau supérieur permet plus de mouvement de code avec moins d’invariants.

2. Bien que nous cherchions activement à résoudre ce problème, LLVM souffre du même problème que celui rencontré par le backend via-C: il nous oblige à créer points de processus. Que sont les points de processus? Essentiellement, comme Haskell n'utilise pas la convention classique appel / appel, chaque fois que nous établissons l'équivalent moral d'un appel de sous-procédure, nous devons insérer une continuation dans la pile, puis passer à la sous-procédure. Cette continuation est généralement une étiquette locale, mais LLVM requiert que ce soit une procédure réelle. Nous devons donc décomposer les fonctions en morceaux plus petits (chaque morceau étant appelé un point de processus). C'est une mauvaise nouvelle pour les optimisations, qui fonctionnent au niveau de la procédure.

3. C-- et LLVM adoptent une approche différente de l'optimisation du flux de données. LLVM utilise le style SSA traditionnel avec les nœuds phi: C-- utilise un framework génial appelé Hoopl qui ne vous oblige pas à maintenir l’invariant SSA. Je peux le confirmer: les optimisations de programmation dans Hoopl sont très amusantes, bien que certains types d’optimisations (notamment l’inclusion de variables uniques utilisées) ne soient pas tout à fait naturels dans ce paramètre de flux de données.

Answer 3

GHC a maintenant officiellement un backend LLVM, et il s'avère que c'est est compétitif avec le GCC et le codegen natif et est plus rapide dans certains cas . Et le projet LLVM a accepté la nouvelle convention d'appel David Terei a créé pour Haskell sur LLVM. Les deux projets fonctionnent donc de manière étonnante.

Answer 4

L’un des problèmes rencontrés dans la pratique est que LLVM est une cible beaucoup plus mobile.

GHC a eu du mal à prendre en charge plusieurs versions de LLVM. Il existe une discussion sur le mailing ghc-dev liste à ce sujet.

Btw, actuellement le backend llvm dans ghc est après que Haskell ait été traduit en langage cmm (qui, je crois, est principalement juste C - étendu avec certains registres du langage STG), et à cause de ce qui va être décrit plus haut. difficultés résolues, des optimisations redondantes sont en cours, ce qui ralentit la compilation.

De plus, historiquement et actuellement, autant que je sache, le projet LLVM n'accorde pas la priorité à la fourniture d'une plate-forme portable, et certains développeurs ont tenu à préciser qu'il est un compilateur IR et non une forme de langage d'assemblage portable .

Il est possible que l’IR LLVM IR que vous écrivez pour une cible prévue ne soit pas du tout utile pour une autre cible. À titre de comparaison, le site Web C-- le désigne en fait comme un ensemble portable. "Vous seriez beaucoup plus heureux avec un langage d'assemblage portable qui pourrait être ... " est une citation de leur site Web . Ce site Web mentionne également une interface d’exécution facilitant la mise en œuvre portable de la récupération de place et de la gestion des exceptions.

Vous pouvez donc considérer C-- comme un terrain commun portable pour tous les frontaux, qui a un peu plus de choses en commun avec CIL et le code octet Java, et LLVM IR comme un terrain commun expressif pour tous vos backends qui facilite l'unification des optimisations de bas niveau communes à plusieurs cibles. LLVM IR offre également l’avantage supplémentaire que le projet LLVM implémentera une grande partie de ces optimisations de bas niveau. Cela étant dit, à certains égards, LLVM IR pourrait en fait être considéré comme étant de niveau supérieur à C--, par exemple, LLVM IR a différents types où, comme dans C--, tout n’est que des vecteurs bits.