Difficulté à comprendre l'asymétrie de compatibilité entre le texte LLVM IR et la représentation binaire entre versions

Question

En lisant divers articles sur LLVM et sa propre documentation, j'ai vu des références à une propriété que je trouve étrange concernant la rétrocompatibilité de son IR.

Une grande partie de la documentation concernant l'IR mentionne qu'elle est instable et peut se casser à peu près n'importe quand. Cependant, il a également souvent mentionné que le bitcode IR est plus rétrocompatible (comme dans «souvent valide sur plusieurs versions») que le texte IR pour une version LLVM spécifique donnée. D'après ce que je comprends, la transformation bytecode -> bitcode est à peu près un mappage direct. Sachant cela, pourquoi/comment le texte IR est-il moins compatible? Je n'arrive pas à trouver la documentation sur le mécanisme réel qui conduit ce comportement.

Un exemple d'une telle déclaration sur la compatibilité IR peut être trouvée ici: http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

Answer 1

Prenant la parole en tant que développeur et non celui qui a développé LLVM.

Comme vous pouvez l'imaginer, le bitcode ressemble plus à une machine virtuelle qui a une instruction spécifique de 64 bits qui, jusqu'à ce que les instructions de l'ordinateur quantique soient populaires, changeront rarement. Comme les nouvelles puces 64 bits sont livrées avec des améliorations incrémentielles, ce n'est pas une chirurgie majeure pour 'ajouter' une nouvelle manipulation de bitcode. L'IR, d'autre part, est une représentation textuelle qui passera par une ou plusieurs passes pour arriver au code binaire ou au code machine. Pour supporter de nouvelles capacités il y a évidemment un net 'add' (nouvelles instructions) ainsi que des modifications à l'existant. Cela aura non seulement un impact sur les parseurs/émetteurs IR, mais potentiellement de nombreux modèles de données intermédiaires/éphémères utilisés entre eux. Clairement, cela aurait également un impact sur l'API LLVM C/C++. Des propositions très coûteuses pour maintenir la rétrocompatibilité en effet.

Answer 2

Je pense que les développeurs LLVM ont choisi pour promettre plus de compatibilité pour le bitcode car il y a des cas d'utilisation plus évidents qui bénéficient d'un bitcode rétrocompatible que pour la représentation textuelle.

Vous pouvez par exemple stocker et distribuer des bibliothèques en tant que bitcode LLVM et les charger dans une sorte d'interpréteur de compilation juste-à-temps pour une langue utilisateur. Il peut être gênant d'avoir à mettre à jour le bitcode à chaque fois que l'interpréteur est mis à jour. Bitcode est une interface machine, plus utile avec une compatibilité bien définie. LLVM IR est plus souvent utilisé pour le débogage, la documentation ou les tests internes de LLVM, où il est plus pratique de modifier un code défaillant lorsque des modifications (peu fréquentes) sont apportées à la représentation. Il semble moins probable que le code intermédiaire soit stocké à long terme ou distribué largement. Le maintien de la compatibilité descendante peut avoir un impact négatif tant sur l'implémentation (voir par exemple un analyseur C++) que sur l'évolution future d'un langage (pensez aux difficultés des langages de programmation modernes pour gérer les décisions rétrospectivement imprudentes du passé), La communauté LLVM a choisi de le faire uniquement lorsqu'il y a des avantages évidents. Je ne pense pas qu'il y ait une raison technique inhérente aux formats, puisque les deux formats doivent être analysés et manipulés correctement.