Questions pour la compilation à LLVM

Question

J'ai joué avec LLVM en espérant apprendre à l'utiliser.

Cependant, mon esprit est bogué par le niveau de complexité de l'interface.

Prenez par exemple leur fonction Fibonacci

int fib(int x) { 
    if(x<=2) 
     return 1; 
    return fib(x-1) + fib(x-2); 
    } 

Pour obtenir ce à la sortie LLVM IR, il faut 61 lignes de code !!!

Ils incluent également BrainFuck qui est connu pour avoir le plus petit compilateur (200 octets). Malheureusement, avec LLVM, il est supérieur à 600 lignes (18 kb).

Est-ce la norme pour les backends du compilateur? Jusqu'à présent, il semble qu'il serait beaucoup plus facile de faire un assemblage ou un backend C.

Answer 1

Le problème réside avec C++ et non LLVM.

Utilisez un langage conçu pour la métaprogrammation, comme OCaml, et votre compilateur sera considérablement plus petit. Par exemple, this OCaml Journal article describes an 87-line LLVM-based Brainfuck compiler, this mailing list post describes complete programming language implementation including parser qui peut compiler la fonction Fibonacci (parmi d'autres programmes) et le compilateur entier est inférieur à 100 lignes de code OCaml en utilisant LLVM, et HLVM is a high-level virtual machine with multicore-capable garbage collection in under 2,000 lines of OCaml code using LLVM.

Answer 2

LLVM n'optimise-t-il donc pas l'IR en fonction de l'architecture spécifique implémentée en back-end? Le code IR n'est pas directement traduit 1: 1 dans le binaire final. Pour autant que je le comprenne, c'est comme ça que ça fonctionne. Cependant, j'ai seulement commencé à jouer avec le back-end (je le porte sur un processeur personnalisé).

Answer 3

LLVM nécessite un code standard, mais une fois que vous le comprenez, c'est vraiment très simple. Essayez de rechercher un frontal GCC simple, et vous vous rendrez compte à quel point LLVM est propre. Je recommanderais certainement LLVM sur C ou ASM. ASM n'est pas portable du tout, et générer du code source est généralement une mauvaise chose, car cela rend la compilation lente.

Answer 4

Les représentations intermédiaires peuvent être un peu verbeuses, comparées à l'assembleur non virtuel. J'ai appris cela en regardant .NET IL, bien que je ne suis jamais allé beaucoup plus loin que regarder. Je ne suis pas vraiment familier avec LLVM, mais je suppose que c'est le même problème. Cependant, cela a du sens quand on y pense. Une grande différence est que les IR doivent gérer beaucoup de métadonnées. En assembleur il y a très peu - le processeur définit implicitement beaucoup, et les conventions pour des choses comme les appels de fonctions sont laissées au programmeur/compilateur pour définir. C'est pratique, mais cela crée une grande portabilité et des problèmes d'interopérabilité.

Les représentations intermédiaires telles que .NET et LLVM veillent à ce que les composants compilés séparément puissent fonctionner ensemble - même les composants écrits dans différents langages et compilés par différents frontaux du compilateur. Cela signifie que les métadonnées sont nécessaires pour décrire ce qui se passe à un niveau supérieur à celui par exemple. poussées arbitraires, pops et charges qui pourraient être la manipulation des paramètres, mais pourraient être à peu près tout. Le gain est assez important, mais il y a un prix à payer.

Il y a aussi d'autres problèmes. La représentation intermédiaire n'est pas vraiment destinée à être écrite par des humains, mais elle est censée être lisible. En outre, il est censé être assez général pour survivre à un certain nombre de versions sans une refonte complètement à partir de zéro.Fondamentalement, dans ce contexte, explicite est presque toujours meilleur qu'implicite, donc la verbosité est difficile à éviter.