QBE - Backend de compilador: versão 1.3

• Otimizações de desempenho significativas foram adicionadas, e o QBE 1.3 atinge mais de 63% do desempenho de compiladores comerciais no coremark puro, além de mostrar melhora de 33% em relação ao qbe-1.2 no conjunto de testes do Hare
• O QBE 1.3 é o maior lançamento desde a 1.0, incluindo cerca de 7 mil linhas adicionadas e 1,5 mil linhas removidas
• As novas otimizações incluem GVN/GCM, otimizações de loop, eliminação de if, simplificação de CFG e outras, mas apenas alguns passes já validados foram mantidos
• O inlining ficou de fora deste conjunto de otimizações porque não se encaixa bem no modelo de compilação em streaming por função do QBE
• Em uma variação do coremark com ee_isdigit inline e crcu8 trocado por uma implementação mais simples e sem desvios, o QBE alcançou 70% do desempenho-alvo em relação ao gcc -O2
• A nova ferramenta em OCaml mgen compila padrões de IL em estilo lispy para código C de correspondência, permitindo substituir ou simplificar a lógica manual existente de seleção de instruções
• O mgen encontra padrões de IL em blocos especiais de comentários e insere código C logo abaixo; o uso atual pode ser visto em isel.c
• A correspondência de DAG de instruções segue uma abordagem de numeração semelhante à do compilador Plan9 C de Ken Thompson, e também gera um matcher simples em bytecode interpretado por runmatch()
• Foi adicionado suporte à Windows ABI, permitindo compilar para Windows ao passar -t amd64_win
• O assembly gerado pelo QBE continua usando sintaxe AT&T, e é recomendado compilá-lo com o assembler do mingw
• O suporte a código independente de posição foi melhorado, permitindo ligação mais suave com objetos compartilhados e a geração de objetos compartilhados na maioria dos alvos
• Uma nova flag extern de constante dinâmica (DYNCONST) permite representar, no nível de IL, acesso indireto a símbolos globais como variáveis de bibliotecas dinâmicas

[GN⁺]

Comentários do Lobste.rs

• Estou criando um pequeno SO no estilo TRIPOS/Amiga Exec como projeto de hobby de longa data
  Não há proteção de memória, o mapa de memória é plano e a passagem de mensagens basicamente se resume a passar ponteiros
  Para tornar esse tipo de sistema self-hosting, é muito mais prático ter um compilador pequeno que consiga gerar PIE/PIC. Bibliotecas no estilo Amiga obviamente precisam ser PIC, e também é bom não precisar fazer muitos patches no momento do carregamento ao colocar o executável em algum ponto do mapa de memória compartilhada
  GCC e Clang conseguem fazer isso, mas são grandes demais. Da última vez que vi, o TCC não conseguia gerar PIC, então preciso olhar melhor para o QBE

  • Meu compilador C consegue gerar PIC, então talvez te interesse: https://codeberg.org/lsof/antcc/
    Espero que isso não soe como autopromoção. Eu realmente gosto da área de compiladores pequenos, e ela precisa de mais testes
  • Eu também estou criando o Ashet OS, um SO com mapa de memória plano, tudo em PIE e em que chamadas de sistema são chamadas de função
    Ele já avançou bastante e suporta várias plataformas
    Provavelmente ainda vai demorar para chegar a ser self-hosting. Preciso de geração de código Thumb-2, e na prática a única forma de conseguir isso é escrevendo meu próprio compilador. Há também a limitação de ter apenas 8 MB de RAM utilizável, excluindo o código do kernel
    Uso um formato de executável próprio, .ashex, criado a partir da conversão de arquivos ELF. Nesse processo, consumimos uma seção especial que na prática é um único salto absoluto, e o carregador de aplicativos a reescreve com os endereços reais das chamadas de sistema
    A dificuldade em um sistema de memória plana está em oferecer suporte limpo a objetos compartilhados. Para compartilhar código entre aplicações diferentes, é preciso suporte do compilador para que todo acesso a símbolos dinâmicos seja feito por meio de variáveis armazenadas em registradores

• Fiquei muito feliz com a adição da nova palavra-chave extern
  Isso não aparece nas notas da versão, mas ela também funciona junto com thread, o que permite initial-exec TLS. Isso é necessário ao acessar variáveis globais thread-local definidas em outras bibliotecas compartilhadas, e é necessário para o ctype.h do FreeBSD
  extern também é necessário para acessar variáveis globais normais de bibliotecas compartilhadas em plataformas como macOS e Haiku, por exemplo stderr. Agora compiladores baseados em QBE poderão suportar muito mais sistemas operacionais e casos de uso
  As melhorias de desempenho do Roland também são muito bem-vindas. Foi um trabalho realmente excelente

• Se entendi isso direito, então agora há suporte oficial ao Windows?
  Essa não era uma das grandes limitações históricas — e ainda atuais — do QBE? Muito bom ver isso

• O objetivo deste projeto se sobrepõe ao do Cranelift? Não consigo ter muita noção de quando usar QBE

  • QBE é algo próximo do “OpenBSD” dos backends de compilador. Simplicidade e minimalismo são a filosofia e, segundo a descrição oficial, o objetivo é “fornecer 70% do desempenho de compiladores otimizadores industriais com 10% do código”
    Os concorrentes são de fato Cranelift e LLVM
    Infelizmente, no passado ele foi usado principalmente em linguagens e implementações de compiladores de hobby. Por exemplo, myrddin, que parecia uma nova linguagem da família do C, agora aparentemente está morto, e cproc ainda é uma implementação de compilador C de hobby ativa
    Ainda assim, desde que Hare adotou o QBE, surgiram mais expectativas. A resposta para a pergunta está aqui: https://harelang.org/documentation/faq.html#why-qbe-instead-of-llvm
  • Eu diria que ele também se sobrepõe em objetivos não só ao Cranelift, mas ao LLVM
    Não conheço tão a fundo, mas há bastante material comparativo por aí. Pelo que sei, o QBE busca ser um backend muito mais simples do que os outros dois

• Acho muito legal a abordagem de usar uma pequena DSL para gerar o matcher de seleção de instruções