El uso de código de bytes LLVM para las bibliotecas (en lugar de archivos de objetos nativos)

Question

¿Cuáles son las implicaciones en

• portabilidad (convención de llamada: ¿realmente importa en un nivel LLVM cuando solamente poner en funciones de la biblioteca OS C o)
• tiempo de enlace
• optimizaciones

me gustaría compilar un lenguaje de juguete con LLVM, debido a todas las partes duras ya que están presentes (optimización, generación de código objeto), pero estoy luchando con un concepto que me gustaría conservar si vale la pena: los archivos de la biblioteca deberían ser redistribuibles, utilizables como lib estáticos y compartidos (para vincular, en el caso compartido, un archivo real o dll se generará cuando la aplicación final esté vinculada).), portátil. Creo que esto reduciría parte del tiempo de compilación (ya que la generación del código nativo y quizás la optimización solo se realiza una vez, en el tiempo del enlace binario final). Imagino que el vinculador se ocupará de llamar a la convención (si es posible) y la conversión a una biblioteca compartida si así lo solicita. En una adición muy extendida, quizás LLVM podría aprovecharse como , no como el enlace, y usar LLVM JIT para ejecutar el bytecode generado directamente, eliminando por completo los tiempos de enlace al escribir el código.

suena esto

1. Factible?
2. ¿Lo vale usted? Sé que el tiempo de enlace de C/C++ es comparativamente largo, lo que es problemático cuando se reconstruye con frecuencia. ¿Qué ocurre con la optimización de tiempo de enlace libre (cfr /GL y -flto, ya que esencialmente se vincularán bytecode LLVM, que luego se convertirá en un binario nativo).

Esto puede ser una pregunta vaga, si tengo que aclarar algo, por favor pregunte.

Answer 1

He hecho algo similar a esto en el pasado. Una cosa que debes tener en cuenta es que el código de bits LLVM no es "portátil" porque no es completamente independiente de la máquina. Los archivos de Bitcode tienen conocimiento de cosas como el tamaño de punteros, etc. que son específicos del procesador al que se apunta.

Dicho esto, en el pasado he compilado programas y sus bibliotecas de soporte para codificar los bits y vincular los archivos de código de bits entre sí antes de generar un archivo de ensamblaje para todo el programa. Tiene razón en que las convenciones de llamadas no son importantes para las llamadas que son internas, pero las llamadas realizadas fuera (o desde fuera) aún requieren que se siga el ABI.

Es posible que pueda diseñar su lenguaje de juguete de forma que pueda evitar el código de bit dependiente del procesador, pero deberá tener mucho cuidado.

Me di cuenta de que la vinculación de los archivos de código de bits juntos llevó bastante tiempo, especialmente a altos niveles de optimización. Eso puede haberse acelerado por ahora, lo hice con LLVM desde hace 2 o 3 años.

Un último punto: dependiendo del procesador de destino probablemente necesite el equivalente de libgcc.a o compiler-rt para manejar cosas que al procesador no le pueden gustar las cosas de coma flotante o de 64 bits si el procesador no lo hace t tiene instrucciones que realizan esas operaciones.