Le problème technique principal de LLVM c'est qu'il n'est pas portable (le bytecode produit dépend de l'architecture prise en compte par le compilateur en amont, et on ne génère pas le même bytecode vers des architectures différentes); de plus, sa sémantique est assez mal spécifiée, repose beaucoup sur les spécificités de C (forcément la force de travail autour de LLVM vient de Clang aujourd'hui).
Ça n'empêche pas Brendan Eich de faire de la pub pour emscripten, l'évaluateur de bytecode LLVM codé en Javascript, mais aujourd'hui LLVM directement n'est pas une solution très viable pour cet usage (pour lequel il n'a pas été prévu).
[^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
Posté par gasche . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 2.
Le problème technique principal de LLVM c'est qu'il n'est pas portable (le bytecode produit dépend de l'architecture prise en compte par le compilateur en amont, et on ne génère pas le même bytecode vers des architectures différentes); de plus, sa sémantique est assez mal spécifiée, repose beaucoup sur les spécificités de C (forcément la force de travail autour de LLVM vient de Clang aujourd'hui).
Ça n'empêche pas Brendan Eich de faire de la pub pour emscripten, l'évaluateur de bytecode LLVM codé en Javascript, mais aujourd'hui LLVM directement n'est pas une solution très viable pour cet usage (pour lequel il n'a pas été prévu).