LLVM vs. C—; ¿Cómo puede LLVM, fundamentalmente, no ser mejor para Haskell que C--?

clang ghc

Question

Me ha entusiasmado que LLVM sea ​​lo suficientemente bajo como para modelar cualquier sistema, y ​​lo vi como una promesa de que Apple lo estaba adoptando; pero nuevamente Apple no admite específicamente a Haskell ;

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

Que los LLVM no hayan resuelto el problema de la recolección de basura sin sobrecarga no es demasiado sorprendente. Resolver esto mientras se mantiene al margen del modelo de datos es una pregunta abierta en ciencias de la computación.

- LHC no utilizará LLVM.

Answer 1

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

Recuerde: no estaba claro hace 10 años que LLVM construiría toda la infraestructura que C-- no pudo. Desafortunadamente, LLVM tiene la infraestructura para el código optimizado y portátil, pero no la infraestructura para un 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 utiliza LLVM para la generación de código . Utilice 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

GHC ahora tiene oficialmente un backend LLVM, y resulta que es competitivo con GCC y nativos, y en realidad es más rápido en algunos casos . Y el proyecto LLVM ha aceptado la nueva convención de llamadas que David Terei creó para Haskell en LLVM, por lo que, sorprendentemente, los dos proyectos están trabajando juntos ahora.

Answer 3

Habiendo trabajado un poco con el nuevo backend de generación de código que manipula C--, puedo decir que hay varias razones por las que C-- puede ser mejor que LLVM, y también por qué no son exactamente lo mismo.

1. C-- opera a un nivel más alto de abstracción 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. Mientras buscamos activamente solucionar esto, LLVM sufre el mismo problema que sufrió el back-end de C: requiere que creemos puntos proc. ¿Qué son los puntos proc? Esencialmente, debido a que Haskell no usa la convención clásica de llamada call / ret, siempre que hagamos el equivalente moral de una llamada de subprocedimiento, debemos empujar una continuación en 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). Esta es una mala noticia 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 4

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

GHC ha tenido algunos problemas al intentar admitir varias versiones de LLVM. Hay una discussion activa en la lista de correo de ghc-dev 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-- ampliado con ciertos registros del lenguaje STG), y debido a las dificultades que se mencionan anteriormente, se están realizando optimizaciones redundantes que ralentizan la compilación.

Además, históricamente, y actualmente AFAIK, el proyecto LLVM no prioriza el suministro de una plataforma portátil, y algunos desarrolladores han dicho que es un IR de compilación y no una forma de lenguaje ensamblador portátil .

El LLVM IR que escribe para un objetivo intendente puede no ser del todo útil para un objetivo diferente. A modo de comparación, el sitio web de C-- en realidad se refiere a él como un ensamblaje portátil. "Usted sería mucho más feliz 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.

Así que podría pensar en C-- como una base común portátil para todos los frontales que tiene un poco más en común con CIL y el código de bytes Java y LLVM IR como una base común expresiva para todos sus backends que facilita la unificación baja - Optimizaciones de nivel comunes a múltiples objetivos. LLVM IR también proporciona la ventaja adicional de que el proyecto LLVM implementará muchos de esos niveles de optimización de bajo nivel. Dicho esto, de alguna manera, LLVM IR podría realmente considerarse un nivel más alto que C--, por ejemplo, LLVM IR tiene diferentes tipos, como en C-- todo es solo vectores de bits.