QBE - backend del compilador: versión 1.3

• Se añadieron grandes optimizaciones de rendimiento, y QBE 1.3 alcanza más del 63% del rendimiento de compiladores comerciales en coremark vanilla, además de mejorar un 33% frente a qbe-1.2 en la suite de pruebas de Hare
• QBE 1.3 es la mayor versión desde la 1.0, con unas 7k líneas añadidas y 1.5k líneas eliminadas
• Las nuevas optimizaciones incluyen GVN/GCM, optimización de bucles, eliminación de if, simplificación de CFG y más, aunque solo se mantuvieron algunos pases ya comprobados
• El inlining se excluyó de este conjunto de optimizaciones porque no encaja bien con el modelo de compilación por streaming a nivel de función de QBE
• En una variante de coremark donde ee_isdigit se integra en línea y crcu8 se cambia por una implementación más simple y sin ramas, QBE alcanzó el 70% del rendimiento objetivo frente a gcc -O2
• La nueva herramienta en OCaml mgen compila patrones de IL estilo lispy a código de emparejamiento en C, lo que permite reemplazar o simplificar la lógica existente de selección de instrucciones hecha a mano
• mgen busca patrones de IL en bloques especiales de comentarios e inserta código C justo debajo; un ejemplo de uso actual está en isel.c
• El emparejamiento de DAG de instrucciones sigue un enfoque de numeración similar al del compilador Plan9 C de Ken Thompson, y también genera un matcher de bytecode simple que interpreta runmatch()
• Se añadió soporte para Windows ABI, por lo que al pasar -t amd64_win ahora es posible compilar para Windows
• El ensamblado que genera QBE sigue usando la sintaxis AT&T, y se indica que lo adecuado es compilarlo con el ensamblador de mingw
• Se mejoró el soporte para código independiente de posición, de modo que ahora puede enlazar con más fluidez objetos compartidos y generar objetos compartidos en la mayoría de los objetivos
• Con la nueva bandera de constante dinámica extern (DYNCONST), ahora es posible representar a nivel de IL el acceso indirecto a símbolos globales, como variables de bibliotecas dinámicas

[GN⁺]

Comentarios en Lobste.rs

• Llevo tiempo haciendo como hobby un SO pequeño al estilo TRIPOS/Amiga Exec
  No tiene protección de memoria, usa un mapa de memoria plano y el paso de mensajes es básicamente pasar punteros
  Para autoalojar un sistema así, es mucho más cómodo contar con un compilador pequeño que pueda generar PIE/PIC. Las bibliotecas al estilo Amiga obviamente tienen que ser PIC, y también ayuda que al cargar ejecutables en alguna parte del mapa de memoria compartida no haga falta aplicar tantos parches en tiempo de carga
  GCC y Clang pueden hacerlo, pero son demasiado grandes. La última vez que revisé, TCC no podía generar PIC, así que tendría que ver más a fondo QBE

  • Mi compilador de C puede generar PIC, por si te interesa: https://codeberg.org/lsof/antcc/
    Espero que no suene a autopromoción. De verdad me gustan mucho los compiladores pequeños y todavía hace falta más testing
  • Yo también estoy haciendo Ashet OS, un SO con mapa de memoria plano, todo como PIE y llamadas al sistema que son llamadas de función
    Ya está bastante avanzado y soporta varias plataformas
    Parece difícil que llegue pronto a autoalojarse. Necesita generación de código Thumb-2, y en la práctica la única forma de conseguirla es escribir yo mismo el compilador. Además, solo hay 8 MB de RAM disponibles aparte del código del kernel
    Usa un formato ejecutable propio, .ashex, generado a partir de archivos ELF. En ese proceso consume una sección especial que en esencia es un solo salto absoluto, y el cargador de apps la reescribe con las direcciones reales de las llamadas al sistema
    La dificultad de un sistema de memoria plana está en dar soporte limpio a objetos compartidos. Para compartir código entre distintas aplicaciones, hace falta soporte del compilador para que todo acceso a símbolos dinámicos se haga a través de variables guardadas en registros

• Me da mucho gusto ver la nueva palabra clave extern
  No aparece en las notas de la versión, pero también funciona junto con thread, lo que permite TLS initial-exec. Hace falta al acceder a variables globales thread-local definidas en otras bibliotecas compartidas, y lo necesita ctype.h de FreeBSD
  extern también hace falta en plataformas como macOS o Haiku para acceder a variables globales normales de bibliotecas compartidas, por ejemplo stderr. Ahora los compiladores basados en QBE podrán soportar muchos más sistemas operativos y casos de uso
  También se agradecen mucho las mejoras de rendimiento de Roland. Hizo un trabajo realmente excelente

• Si entendí bien esto, ¿ya incluye soporte oficial para Windows?
  ¿No era esa una de las limitaciones históricas y todavía importantes de QBE? Qué bueno verlo

• ¿La meta de este proyecto se traslapa con la de Cranelift? No me queda muy claro cuándo usarías QBE

  • QBE es algo así como el “OpenBSD” de los backends de compilador. Su filosofía es la simplicidad y el minimalismo, y según la descripción oficial, su meta es “ofrecer el 70% del rendimiento de un compilador optimizador industrial con el 10% del código”
    Sus competidores reales son Cranelift y LLVM
    Por desgracia, en el pasado se usó principalmente en lenguajes de hobby o implementaciones de compiladores. Por ejemplo, myrddin, que parecía un lenguaje nuevo de la familia C, ya parece estar muerto, y cproc sigue vivo como una implementación hobby de compilador de C
    Aun así, desde que Hare adoptó QBE ha habido más esperanza. La respuesta a la pregunta está aquí: https://harelang.org/documentation/faq.html#why-qbe-instead-of-llvm
  • Yo diría que no solo se traslapa con Cranelift, sino también con LLVM
    No conozco el tema tan a fondo, pero hay bastante material comparativo. Hasta donde sé, QBE apunta a ser un backend mucho más simple que los otros dos

• Está padrísimo que use un DSL pequeño para generar el matcher de selección de instrucciones