LLVM vs. C & # 8212; ; ¿Cómo puede LLVM, básicamente, no ser mejor para Haskell que C--?

Question

Me ha entusiasmado que LLVM sea lo suficientemente bajo como para modelar cualquier sistema, y lo consideró prometedor que Apple lo estaba adoptando; pero, de nuevo, Apple no admite específicamente Haskell ;

Y, algunos piensan que Haskell estaría mejor con C-- :

  

Que los LLVM'ers no han resuelto el problema de la recolección de basura de sobrecarga cero   no es demasiado sorprendente   Resolviendo esto mientras se mantiene agnóstico del modelo de datos.   Es una pregunta abierta en informática.

- LHC no estar utilizando LLVM.

Answer 1

Bueno, hay un proyecto en UNSW para traducir GHC Core a LLVM

Recuerde: hace 10 años no estaba claro que LLVM construiría toda la infraestructura que C-- no podía. Desafortunadamente, LLVM tiene la infraestructura para código portátil y optimizado, pero no la infraestructura para un buen soporte de lenguaje de alto nivel, que C-- ha (s) d.

Un proyecto interesante sería apuntar a LLVM desde C-- ...

---

Actualización , a partir de GHC 7, GHC usa LLVM para la generación de código . Use la bandera -fllvm . Esto ha mejorado el rendimiento numérico para algunos programas de bajo nivel. De lo contrario, el rendimiento es similar al antiguo backend de GCC.

Answer 2

Después de haber trabajado un poco con el nuevo backend de generación de código que manipula C--, puedo decir que hay una serie de razones por las cuales C-- puede ser mejor que LLVM, y también por qué no son realmente iguales cosa.

1. C-- opera a un nivel de abstracción más alto que LLVM; por ejemplo, podemos generar código en C-- donde el puntero de pila es totalmente implícito, y solo manifestarlo más tarde durante el proceso de compilación. Esto hace que la aplicación de ciertos tipos de optimizaciones sea mucho más fácil, ya que la representación de nivel superior permite más movimiento de código con menos invariantes.

2. Si bien estamos tratando de solucionarlo, LLVM sufre el mismo problema que sufrió el back-end de via-C: requiere que creemos puntos de proceso. ¿Qué son los puntos de proceso? Esencialmente, debido a que Haskell no usa la convención clásica de llamadas call / ret, cada vez que hacemos el equivalente moral de una llamada de subprocedimiento, necesitamos empujar una continuación a la pila y luego saltar al subprocedimiento. Esta continuación suele ser una etiqueta local, pero LLVM requiere que sea un procedimiento real, por lo que necesitamos dividir las funciones en partes más pequeñas (cada pieza se denomina punto proc). Estas son malas noticias para las optimizaciones, que funcionan a nivel de procedimiento.

3. C-- y LLVM adoptan un enfoque diferente para la optimización del flujo de datos. LLVM usa el estilo tradicional de SSA con phi-nodes: C-- usa un marco genial llamado Hoopl que no requiere que mantengas el SSA invariante. Puedo confirmarlo: la programación de las optimizaciones en Hoopl es muy divertida, aunque ciertos tipos de optimizaciones (la incorporación de variables de un solo uso vienen a la mente) no son exactamente las más naturales en esta configuración de flujo de datos.

Answer 3

GHC ahora tiene oficialmente un back-end LLVM, y resulta que es competitivo con el CCG y codegen nativo y, de hecho, más rápido en algunos casos . Y el proyecto LLVM ha aceptado la nueva convención de llamadas David Terei creó para Haskell en LLVM, así que sorprendentemente, los dos proyectos están trabajando juntos ahora.

Answer 4

Un problema en la práctica es que LLVM ha sido mucho más un objetivo móvil.

GHC ha tenido algunos problemas al intentar admitir varias versiones de LLVM. Hay una discusión activa en el correo ghc-dev lista sobre esto.

Por cierto, actualmente el backend llvm en ghc es después de que el Haskell se traduzca al lenguaje cmm (que creo que en su mayoría es solo C-- extendido con ciertos registros del lenguaje STG), y debido a lo anterior Cuando se abordaron las dificultades, se están realizando optimizaciones redundantes que ralentizan la compilación.

También, históricamente, y actualmente AFAIK, el proyecto LLVM no prioriza el suministro de una plataforma portátil, y algunos desarrolladores han decidido articularlo es un compilador IR y no una forma de lenguaje ensamblador portátil .

El IR LLVM que escriba para un objetivo de asistente puede no ser útil para un objetivo previsto diferente. Para comparación, el sitio web de C-- en realidad se refiere a él como un ensamblaje portátil. " Estaría mucho más contento con un lenguaje de ensamblaje portátil que podría ser ... " es una cita de su sitio web . Ese sitio web también menciona una interfaz de tiempo de ejecución para facilitar la implementación portátil de la recolección de basura y el manejo de excepciones.

Entonces podría pensar en C-- como un terreno común portátil para todos los front-end que tiene un poco más en común con el código de bytes CIL y Java y LLVM IR como un terreno común expresivo para todos sus backends que facilita la unificación de las optimizaciones de bajo nivel comunes a múltiples objetivos. LLVM IR también proporciona la ventaja adicional de que el proyecto LLVM implementará muchas de esas optimizaciones de bajo nivel. Dicho esto, de alguna manera, LLVM IR podría considerarse en realidad un nivel más alto que C--, por ejemplo, LLVM IR tiene diferentes tipos donde, como en C--, todo son solo vectores de bits.