UNIVERSIDADE FEDERAL DO MATO GROSSO DO SUL

Transcrição

1 UNIVERSIDADE FEDERAL DO MATO GROSSO DO SUL Faculdade de Computação - FACOM Curso de Bacharelado em Ciência da Computação GERAÇÃO DE BACK-END LLVM PARA O PROCESSADOR ρ-vex Richard Stéffano Martins da Silva Orientação: Prof. Dr. Ricardo Ribeiro dos Santos Monografia apresentada ao curso de Graduação em Bacharelado em Ciência da Computação na Universidade Federal do Mato Grosso do Sul como requisito para a obtenção do título de Bacharel em Ciência da Computação. UFMS/FACOM - Campo Grande - MS - AGOSTO/2013

2 Sumário Lista de Figuras Lista de Tabelas iv v 1 Introdução 2 2 Infraestrutura de Compilação LLVM O Projeto LLVM Arquitetura Representação Intermediária Back-end LLVM Descrição da Arquitetura Alvo Seleção de Instruções Emissão de código Considerações Finais Back-end LLVM para o Processador ρ-vex O Processador Softcore ρ-vex Organização Conjunto de Registradores Conjunto de Instruções Linguagem de Montagem ρ-vex Desenvolvimento do Back-end LLVM para o Processador ρ-vex TargetMachine Registro da Máquina Alvo Descrição do Conjunto de Registradores Convenções de Chamada Descrição do Conjunto de Instruções iii

3 3.2.6 TargetLowering Seletor de Instrução VLIW Packetizer Emissão de Código Considerações Finais Experimentos e Resultados Validação do Back-End LLVM Avaliação de Desempenho Considerações Finais Conclusões e Trabalhos Futuros Propostas para Trabalhos Futuros A Código do Back-end LLVM para o Processador ρ-vex 33 A.1 Definição e registro da máquina alvo ρ-vex A.1.1 RVEXTagetMachine A.1.2 RVEXTargetInfo A.2 Conjunto e classes de registradores A.3 Conjunto de Instruções A.4 Lowering A.5 Seleção de Instruções A.6 Prólogo e Epílogo A.7 Packetizer A.8 Emissão de código Referências Bibliográficas 47 iv

4 Lista de Figuras 2.1 Visão em alto nível da infraestrutura LLVM Exemplo de código em C e em LLVM IR Fases do LLVM na geração de código Organização do processador ρ-vex Formato de instrução do processador ρ-vex Formatos de operações implementadas no processador ρ-vex Exemplo de instruções ρ-vex Visão das classes que compõe o back-end LLVM para o processador ρ-vex Trecho da especificação dos registradores ρ-vex Definição das classes de registradores ρ-vex Definição das classes de registradores ρ-vex Formato RTYPE Formato ISTYPE Formato BRANCH Formato RTYPE BS Formato MEMTYPE Definição das classes de registradores ρ-vex Visão do fluxo de validação do back-end LLVM para o ρ-vex Speedup do desempenho do back-end LLVM sobre o VEX C Compiler v

5 Lista de Tabelas 3.1 Tipos de imediatos Convenção de uso para o conjunto de registradores GR do ρ-vex Conjunto de programas utilizados para a validação do back-end LLVM Programas Compilados com o LLVM Programas Compilados com o VEX C Compiler

6 Capítulo 1 Introdução A geração de código para uma máquina alvo é uma tarefa extensa que envolve várias atividades de considerável complexidade computacional (problemas NP-completos) como: seleção de instruções, escalonamento de instruções, otimizações de código e alocação de registradores, entre outras. Diante dessa dificuldade, a literatura da área de compiladores não dispõe de muitas opções de infraestruturas de compilação que facilitam a reutilização de geradores de código para outros conjuntos de instruções e/ou máquinas alvo. A infraestrutura de compilação LLVM (Low Level Virtual Machine) [1, 2] é uma dessas opções uma vez que constitui-se em um framework parametrizável e extensível que possibilita a adaptação de algoritmos tradicionais - já implementados nessa infraestrutura - de geração de código para um conjunto de instruções e arquitetura. LLVM oferece um conjunto de interfaces e classes que podem ser estendidas para acoplar e reutilizar algoritmos, já estabelecidos para novas máquinas alvo. Nesse cenário, este trabalho estende a capacidade de geração de código dessa infraestrutura de compilação para o conjunto de instruções VEX [3, 4] e o processador ρ-vex [5, 6]. O objetivo principal deste trabalho em nível de graduação é projetar e desenvolver uma infraestrutura de geração de código (back-end), baseando-se no compilador LLVM, para compilar programas aptos para execução no processador soft-core VLIW (Very Long Instruction Word) [3, 7] e reconfigurável denominado ρ-vex. Para validar e avaliar esse novo mecanismo de geração de código para o processador ρ-vex, foi utilizado o conjunto de ferramentas de compilação e simulação VEX. Esse conjunto de ferramentas possibilitou validar a geração de código, por meio da simulação do código gerado em um simulador VEX e avaliar o desempenho por meio de estatísticas geradas pela ferramenta de simulação VEX. Diante do exposto, o texto desta monografia está organizado da seguinte forma: o Capítulo 2 apresenta a infraestrutura de compilação LLVM enfatizando as etapas e algoritmos de geração de código atualmente implementados e que fazem parte do compilador LLVM. no Capítulo 3 é apresentado o processador ρ-vex e o projeto e desenvolvimento da extensão do back-end LLVM para esse processador e conjunto de instruções VEX. O Capítulo 4 apresenta e discute todos os experimentos realizados e resultados obtidos visando à validação e avaliação do backend para o processador ρ-vex. 2

7 Introdução 3 As conclusões deste trabalho assim como proposições para desenvolvimentos de trabalhos futuros são apresentadas no Capítulo 5.

8 Capítulo 2 Infraestrutura de Compilação LLVM Este capítulo apresenta a infraestrutura de compilação LLVM, destacando o funcionamento e organização de um back-end LLVM bem como os procedimentos necessários para a geração de código para uma arquitetura e conjunto de instruções alvo. Na Seção 2.1 apresenta-se uma breve introdução ao projeto LLVM. Na Seção 2.2 discute-se a organização e funcionamento do LLVM. Na Seção 2.3 é apresentada a linguagem de representação intermediária do LLVM, a LLVM IR, assim como sua importância na geração de código e consequentemente no desenvolvimento deste trabalho. Por fim, na Seção 2.4, o back-end do LLVM é descrito. 2.1 O Projeto LLVM O projeto LLVM é uma coleção modular de componentes reutilizáveis para construção de compiladores e ferramentas para análise e otimização de código executável [1]. Teve inicio na Universidade de Illinois e desde então cresceu como um projeto consistente, contando atualmente com uma série de sub-projetos além de um número significativo de contribuintes espalhados por diversos países. O código do LLVM é escrito em C++ e está sob a licença University of Illinois at Urbana-Champaign (UIUC) Berkeley Software Distribution (BSD)-Style, que o torna um software open-source. A escolha do LLVM para o desenvolvimento deste trabalho está ligada principalmente a sua arquitetura, que por sua vez, possui componentes bem definidos e claramente separados proporcionando a integração de funcionalidades a componentes específicos e a extensibilidade do projeto com uma curva de aprendizado menor se comparada a outras infraestruturas de compilação (como o GCC). Outras vantagens do projeto LLVM são sua linguagem independente, comunidade de contribuidores ativa e documentação extensiva. 2.2 Arquitetura O LLVM possui uma arquitetura de três fases [8], consistindo de um front-end, otimizador e back-end. A Figura 2.1 representa em alto nível a infraestrutura do LLVM. O front-end fica responsável por analisar, validar e diagnosticar erros no código de entrada. Em seguida, transforma o código analisado para uma linguagem de representação intermediária 4

9 Infraestrutura de Compilação LLVM 5 Figura 2.1: Visão em alto nível da infraestrutura LLVM. (LLVM IR). Este processo é feito com um compilador estático tradicional. Atualmente, o LLVM utiliza o Clang como front-end. Opcionalmente, pode ser usada a ferramenta DragonEgg, que é um subprojeto do LLVM, e funciona como um plugin para o GCC substituindo seu otimizador e back-end por módulos correspondentes no LLVM [9]. Dado o código de entrada na forma da LLVM IR, ele é então (opcionalmente) melhorado através de uma série de passos de análise, dos quais são coletadas informações que podem ser utilizadas para a otimização do código. Finalmente, o back-end recebe o código resultante dos passos anteriores e o transforma em código assembly ou código nativo (já link-editado) para arquiteturas específicas de máquinas como X86, ARM, PowerPC, Mips, Sparc, Xcore, entre outras. 2.3 Representação Intermediária A representação intermediária do LLVM é o aspecto mais importante do projeto LLVM [8]. Ela é usada em todos os componentes da infraestrutura e tem como objetivo: ser um alvo fácil de geração de código; ser independente da linguagem fonte ou da linguagem alvo; suportar diversos tipos de análises e transformações eficientemente [2]. Em particular, a geração de código para uma arquitetura alvo é feita a partir de um programa nessa representação (como visto na seção anterior). Logo, seu entendimento é fundamental no processo de escrita de um back-end LLVM. A LLVM IR é baseada em formatos de instruções Reduced Instruction Set Computer (RISC) e na forma Static Single Assignment (SSA) [10]. Dessa forma, é próxima de uma linguagem de montagem, porém suficientemente alto nível para que o conjunto de análises e otimizações tradicionais presentes na literatura possam ser implementados [1]. Sendo uma linguagem tipada, suporta tipos primitivos e compostos habituais apresentados em linguagens de programação como C, além de vetores de inteiros (e de ponto flutuante) de tamanho fixo. Programas nessa linguagem são compostos de módulos, cada um dos quais equivale a uma unidade de compilação. Cada módulo é composto por funções, variáveis globais e entradas da tabela de símbolos. Os módulos podem ser combinados com o linker do LLVM (llvm-ld). Uma função é uma lista de blocos básicos, cada um iniciado com um rótulo. Um bloco básico é uma lista de instruções, que por sua vez podem ser classificadas como: instruções de término, operações binárias, operações bit a bit, instruções de memória, entre outras. Na Figura 2.2 há um exemplo de código em C e a respectiva versão em LLVM IR.

10 Infraestrutura de Compilação LLVM 6 Figura 2.2: Exemplo de código em C e em LLVM IR. 2.4 Back-end LLVM Um back-end LLVM consiste em um conjunto de componentes reutilizáveis responsáveis por transformar o código na representação intermediária em código assembly ou diretamente em código binário executável. Destes componentes destacam-se: Conjunto de interfaces abstratas que especificam propriedades da arquitetura alvo; Classes que modelam o código de máquina independente da arquitetura alvo. Por exemplo: instruções, funções e registradores; Algoritmos independentes da arquitetura alvo, implementados como passos da geração de código. Os algoritmos de alocação de registradores são um exemplo. O processo de geração de código para uma arquitetura alvo baseia-se em uma série de passos de análise e transformação, responsáveis por gradualmente produzir o código de máquina final. A Figura 2.3 representa uma visão abstrata dos estágios do back-end LLVM. Front-end LLVM Back-end Seleção de Instrução Escalonamento Otimização Alocação de Registradores Inserção de código Prólogo/Epílogo Otimizações tardias Emissão de código Fast ListScheduling Fast Linear Scan PBQP Greedy Assembly Código nativo Figura 2.3: Fases do LLVM na geração de código. A geração de código está dividida nos seguintes estágios [1]:

11 Infraestrutura de Compilação LLVM 7 Seleção de instrução: o primeiro passo do procedimento de geração de código transforma a representação intermediária em um grafo de instruções legalizado, que é uma representação da LLVM IR na forma de grafo, utilizando apenas instruções nativas da arquitetura alvo; Escalonamento: recebe o grafo de instruções e determina uma ordem para elas. O código é então emitido na forma SSA; Otimização em código de máquina baseado em SSA: fase opcional que opera sobre a forma SSA produzida no passo anterior. Um exemplo de otimização nessa fase é a peephole [?]; Alocação de registradores: todas as referências a registradores virtuais são eliminadas substituindo-os por registradores físicos. Também é realizada a emissão de intruções de leitura e escrita na memória, quando necessário; Inserção de código prólogo/epílogo: códigos de prólogo e epílogo podem ser inseridos nessa fase. As localizações de referências abstratas são removidas; Otimizações tardias: otimizações que operam no código final de máquina são realizadas nessa fase; Emissão de código: a fase final tem como saída o código em formato assembly ou em código de máquina. Além destes, um back-end em particular pode adicionar mais passos no processo para algum requisito específico (como otimizações de código específicas da arquitetura, escalonamento de instruções preferenciais, entre outros). Nas próximas seções, serão discutidos em mais detalhes os componentes pertecentes ao gerador de código que são relevantes para o desenvolvimento de um novo back-end LLVM Descrição da Arquitetura Alvo As descrições de todas as características da arquitetura alvo são concentradas em um conjunto de classes que implementam interfaces abstratas em C++, definidas no módulo de geração de código do LLVM. Os métodos virtuais destas interfaces permitem que a parte genérica do gerador de código consiga trabalhar com os detalhes de cada arquitetura. A implementação de certas interfaces para cada back-end LLVM é uma tarefa mecânica, envolvendo a definição de muitos métodos que retornam informações simples ou repetitivas. Para introduzir diversas funcionalidades que facilitam este tipo de tarefa, o projeto LLVM utiliza uma linguagem de descrição de dados denominada TableGen [1]. A linguagem de descrição TableGen é responsável por transformar uma descrição textual de características da arquitetura alvo em código C++, utilizado pelo back-end. Com a TableGen são descritos: conjunto de registradores; conjunto de instruções; convenções de chamada; regras de escalonamento (itinerários); e demais informações estáticas das arquitetura; Uma especificação no formato TableGen consiste de um arquivo contendo descrições de dois tipos de entidades básicas: registros e classes. Um registro é um identificador associado a uma lista de atributos e seus respectivos valores. Uma classe funciona como um template para a

12 Infraestrutura de Compilação LLVM 8 construção de registros, agregando informações que se repetem entre diversos registros. Os valores podem ser de tipos primitivos como inteiros, booleanos e strings, como também de tipos compostos, como grafos completos. Por exemplo: pode-se definir uma classe que descreve um formato de instruções e suas características (como tipo e número de operandos), e instanciar tal classe para cada instrução pertencente a esse formato, onde uma instancia (registro) define as caracteristicas unicas dessas instruções (como mnemônico, operação, etc) Seleção de Instruções A etapa de seleção de instruções é responsável por transformar as instruções da representação intermediária em instruções da arquitetura alvo. Existem várias maneiras descritas na literatura para realizar esse passo da geração de código. O LLVM utiliza um seletor de instruções baseado em um grafo acíclico direcionado, denominado SelectionDAG. O SelectionDAG é uma abstração do código na representação intermediária, que permite uma seleção de instrução utilizando técnicas automáticas, além de ser adequado em outras fases da geração de código, em especial, no escalonamento de instruções. Os nós de um SelectionDAG pertencem a duas classes: nós de operação e nós de ordenação. Os primeiros representam uma operação de código, onde os seus operandos são arestas direcionadas para os nós que definem os operandos. Os nós de ordenação são nós fictícios inseridos para controle de fluxo. A seleção de instruções apresenta as seguintes etapas: Construção do DAG: a primeira versão do SelectionDAG é construída diretamente do código em LLVM IR. Esta primeira versão é denominada ilegal pois utiliza instruções e tipos de dados que não são suportados pela arquitetura alvo; Otimizações genéricas (A): são realizas simplificações no SelectionDAG; Legalização: transforma o SelectionDAG e elimina o uso de instruções e tipos de dados não pertencentes a arquitetura alvo. Otimizações genéricas (B): novamente são realizadas simplificações no SelectionDAG para eliminar as redundâncias que possam vir a ser introduzidas pelo processo de legalização do grafo. Seleção: transforma o SelectionDAG em um grafo no qual todos os nós padrões utilizam instruções da arquitetura alvo. Escalonamento: realiza uma ordenação completa para as instruções do SelectionDAG legalizado. Após este processo, o código já utiliza instruções da plataforma alvo, porém ainda utiliza registradores virtuais e apresenta redundâncias que serão eliminadas em passos de otimização posteriores Emissão de código Após a alocação de registradores e as otimização no código, o gerador de código do LLVM emitirá um arquivo texto contendo o código final em linguagem de máquina. Para produzir este

13 Infraestrutura de Compilação LLVM 9 arquivo, o gerador consulta uma classe do back-end responsável por informar as características sintáticas da linguagem de montagem. O componente emissor assume um conjunto mínimo de diretivas e construções para: declarar e definir dados, instruções, macros, rótulos, etc. 2.5 Considerações Finais Este capítulo apresentou todas as informações acerca da infraestrutura de compilação LLVM necessárias para o desenvolvimento de um back-end. O entendimento da estrutura e funcionamento do LLVM é de fundamental importância, pois estes conceitos formam a base deste trabalho. O Capítulo 3 detalha o processo de desenvolvimento do back-end LLVM para o processador ρ-vex, assim como todas as informações pertinentes ao processador necessárias para tal atividade.

14 Capítulo 3 Back-end LLVM para o Processador ρ-vex Este capítulo apresenta e discute o projeto e desenvolvimento do back-end para o processador ρ-vex na infraestrutura de compilação LLVM. Apresentar-se-ão desde as principais características do processador ρ-vex até os detalhes da implementação do back-end desenvolvido. A Seção 3.1 apresenta o processador ρ-vex e as características importantes para a construção do back-end. A Seção 3.2 detalha as especificações do back-end. 3.1 O Processador Softcore ρ-vex O ρ-vex [5, 6] é um processador VLIW (Very Long Instruction Word) de código aberto, que permite a extensibilidade de sua arquitetura junto a operações reconfiguráveis. A arquitetura do processador ρ-vex é baseado na Instruction Set Architecture (ISA) VEX [3, 4], que por sua vez é inspirada na ISA da família de processadores HP/ST Lx [3] (o mesmo usado para processadores ST200) e oferece uma plataforma tecnológica escalável para processadores embarcados VLIW. Assim como outros processadores baseados na ISA VEX, o ρ-vex pode ser amplamente utilizado em sistemas embarcados através da extesão de sua arquitetura. Acompanham o processador um conjunto de ferramentas de geração de código e simulação, que contêm um compilador C, bibliotecas ANSI C, ferramentas para facilitar o processo de profiling de código, um simulador em software (disponibilizado pela HP [4]) e o montador ρ- ASM. Apesar da existência de ferramentas para geração e simulação de código VEX, tais ferramentas não suportam a compilação e simulação de uma variedade de programas para o processador ρ-vex. Outra limitação está na ausência de ferramentas de link-edição, forçando a remoção de todas as chamadas de funções presentes em bibliotecas externas. Todas as funções em um programa devem ser expandidas inline na função main de forma a preservar o endereçamento global de variáveis. Nas próximas subseções a organização do processador ρ-vex é descrita em detalhes. 10

15 Back-end LLVM para o Processador ρ-vex Organização O processador ρ-vex implementa uma arquitetura Harvard [?] e possui uma arquitetura VLIW minimalista, que não possui unidade de gerenciamento de memória nem unidade para cálculo de números de ponto-flutuante, o endereçamento na memória é realizado com referências absolutas, não há implementação de caches, mecanismos de predição de desvios e não há bancos de registradores distribuídos. Apesar das limitações de sua atual implementação, o processador ρ-vex possui uma arquitetura extensível e reconfigurável possibilitando a adição de novas funcionalidades e consequentemente o suporte a novas aplicações. A microarquitetura do ρ-vex consiste em uma via de dados de quatro estágios, onde as operações são buscadas, decodificadas e despachadas para unidades de execução individuais. Após processadas, os resultados das instruções são armazenados na memória de dados ou conjunto de registradores. Como sua configuração é baseada em uma máquina VEX 1-cluster padrão [3], o ρ-vex dispõe das seguintes unidades funcionais: quatro unidades lógicas e aritméticas (ALUs), duas unidades de multiplicação 16 por 32 bits (MULs), uma unidade de controle (CTRL) e uma unidade de memória (MEM). A Figura 3.1 apresenta a organização do processador ρ-vex. PC GR CTRL A Memória de Instruções A M Fetch Decode Execute Writeback A M A Memória de Dados ρ-vex BR MEM Figura 3.1: Organização do processador ρ-vex Conjunto de Registradores A arquitetura do ρ-vex possui dois bancos de registradores: Registradores Gerais (General Registers, ou GR) e registradores de branch (Branch Registers, ou BR). Os registradores gerais formam um conjunto de 32 registradores de 32 bits, indexados de 0 a 31, usados por instruções lógico-aritméticas e de memória. Os registradores de branch formam um conjunto de 8 registradores de 1 bit, indexados de 0 a 7, usados para armazenar resultados booleanos de operações de comparação e lidos em operações de desvio condicional. Não existe uma convenção de uso de registradores específica para o ρ-vex que segue a convenção da ISA VEX. Dessa forma, para este trabalho foram definidas convenções de uso para os registradores da arquitetura. Na Seção 3.2 a convenção utilizada é descrita em detalhes.

16 Back-end LLVM para o Processador ρ-vex 12 Tipo de imediato Tamanho Immediate switch Sem imediato N/A 00 Short immediate 9 bit 01 Branch offset immediate 12 bit 10 Long immediate 32 bit 11 Tabela 3.1: Tipos de imediatos Conjunto de Instruções O conjunto padrão de operações VEX consiste de 73 operações (excluindo NOP no operation), sendo 42 operações de lógica e aritmética, 11 operações de multiplicação e divisão de inteiros, 11 operações de controle e 9 operações de memória. Além disso, não há suporte a números em ponto flutuante [3]. Para a implementação do processador ρ-vex, o conjunto original de instruções foi estendido com mais duas operações: STOP e LONG IMM. A primeira informa para o processador ρ-vex parar de buscar instruções da memória de instruções. A segunda é usada quando operandos long immediate são usados. Opcodes para duas operações de transferência de dados inter-clusters (SEND e RECV) descritos na ISA VEX foram reservados, mas não são usados, já que a atual implementação do ρ-vex suporta apenas 1-cluster de uma máquina VEX. Uma instrução ρ-vex possui tamanho de 16 bytes (128 bits) e seu formato é apresentado na Figura 3.2. Ela é formada por quatro sílabas (operações), cada uma com quatro bytes (32 bits). Sua organização é dada a seguir: A sílaba zero pode conter uma operação lógico-aritmética ou de controle; As sílabas um e dois podem conter operações lógico-aritmética ou de multiplicação/divisão; A sílaba três pode conter uma operação lógico-aritmética ou de memória; As posições das sílabas na instrução ρ-vex são equivalentes a quantidade de unidades funcionais disponíveis para uso e suas respectivas posições no estágio de execução sílaba 3 sílaba 2 sílaba 1 sílaba 0 0 {ALU, MEM {ALU, MUL {ALU, MUL {ALU, CTRL Figura 3.2: Formato de instrução do processador ρ-vex. A Figura 3.3 mostra os possíveis formatos das operações. Nos sete bits mais significativos encontram-se o campo dos opcodes. Cada sílaba tem um campo de immediate switch, consistindo de 2 bits, que por sua vez descrevem o tipo do imediato que a operação contém (a Tabela 3.1 apresenta os tipos de imediatos que podem ser utilizados). Nos bits 22 a 2 estão presentes os operandos usados pela operação que podem ter organizações específicas conforme o valor presente no campo immediate switch. Os últimos dois bits de cada operação estão definidos como bits L e F, respectivamente. O bit L (last) informa se a operação é a última sílaba da instrução. O bit F (first) informa se a operação

17 Back-end LLVM para o Processador ρ-vex bit opcode bit dst GR 6 bit src1 GR 6 bit src2 GR 3b dst BR L F 7 bit opcode bit dst GR 6 bit src1 GR 9 bit short immediate L F 7 bit opcode bit link register 12 bit branch offset immediate 3b dst BR L F 7 bit opcode bit dst GR 6 bit src1 GR 10 bit long immediate [0-9] F LONG_IMM 22 bit long immediate [10-31] - L F Figura 3.3: Formatos de operações implementadas no processador ρ-vex. é a primeira sílaba da instrução. Sua existência é justificada como informação necessária para implementação de possíveis compressores/codificadores de instruções. Os últimos dois formatos destacados dos demais pertencem ao formato de long immediate: um operando de quatro bytes (32 bits) utilizado por uma operação. Este formato utiliza duas sílabas para conseguir representar uma instrução com um operando long immediate. Este formato não esta disponível na atual versão do ρ-vex, apenas planejado como futura melhoria. Operações lógico-aritmética e de multiplicação/divisão geralmente são compostas de 2 operandos que produzem 1 resultado: dois registradores como operandos (GR) e um registrador (GR ou BR) como resultado. As operações lógico-aritmética, ADDCG, DIVS, SLCT e SLCTF, em especial, operam com 3 registradores como operandos, sendo 2 registradores GR e um registrador BR. Nesse caso, os 3 bits menos significativos do opcode são destinados ao endereçamento do terceiro operando, o registrador BR. As operações ADDCG e DIVS, também utilizam um segundo registrador para resultado do tipo BR. As operações de controle são compostas de um ou dois operandos. As operações GOTO e CALL manipulam apenas um operando, sendo que o operando é um registrador GR ou um imediato (endereço). As operações BR, BRF, RETURN e RFI manipulam dois operandos, sendo que um operando é um imediato e outro um registrador BR (BR e BRF) ou GR (RETURN e RFI). As operações de memória, por sua vez, são compostas de 2 operandos e 1 resultado: um registrador GR como primeiro operando, um imediato (endereço) como segundo operando e um registrador GR como resultado Linguagem de Montagem ρ-vex A linguagem de montagem ρ-vex é a mesma usada no VEX. Para compreender a notação dessa linguagem, considere o exemplo presente na Figura 3.4. O primeiro símbolo, c0, denota o cluster no qual a operação será executada (neste caso, cluster zero). O(s) operando(s) de destino é(são) dado(s) por uma lista de símbolos à esquerda do símbolo =, enquanto que o(s) operando(s) de origem é(são) listados(s) à direita do símbolo =. Neste caso, um único operando de destino é o registrador BR de índice 3 do cluster zero. O identificador do cluster é opcional nos símbolos dos operandos quando representam registradores. Entretanto, o identificador do cluster sempre está presente para reforçar a identificação do cluster cujo registrador operando será usado na execução. Os símbolos ;; indicam o fim de um grupo de operações a serem emitidas em um mesmo ciclo. Instruções que possuem várias operações simplesmente listam cada operação em linhas separadas, com um duplo sinal de ponto-e-vírgula

18 Back-end LLVM para o Processador ρ-vex 14 c0 cmpne $b0.3 = $r0.4, $r0.5 # instr 0, op 0 c0 sub $r0.16 = $r0.6, 3 # instr 0, op 1 ;; ## fim da primeira instruç~ao c0 shl $r0.13 = $r0.13, 3 # instr 1, op 0 c0 shr $r0.15 = $r0.15, 9 # instr 1, op 1 c0 ldw.d $r0.14 = 0[$r0.4] # instr 1, op 2 ;; ## fim da segunda instruç~ao Figura 3.4: Exemplo de instruções ρ-vex. como separador de instruções. Na Figura 3.4 observa-se um trecho de código em linguagem de montagem VEX no qual há duas instruções: a primeira com duas operações paralelas e a segunda com três. 3.2 Desenvolvimento do Back-end LLVM para o Processador ρ-vex O desenvolvimento de um back-end LLVM capaz de converter a LLVM IR em código de máquina de uma arquitetura específica consiste da criação e implementação de alguns arquivos e classes. A Figura 3.5 mostra a hierarquia de classes do back-end LLVM implementado para o processador ρ-vex. As classes em azul são classes pré-existentes do LLVM. As classes em verde são classes implementadas para a geração de código para o processador ρ-vex. As classes em amarelo são classes geradas automaticamente a partir da descrições feitas com a TableGen. Figura 3.5: Visão das classes que compõe o back-end LLVM para o processador ρ-vex. O processo de desenvolvimento de um back-end LLVM pode ser dividido em alguns passos, descritos a seguir:

19 Back-end LLVM para o Processador ρ-vex 15 Extensão da classe TargetMachine que descreve características da arquitetura alvo. Essa classe será o ponto principal de ligação entre o módulo de geração de código do LLVM e a nova arquitetura; Descrição do conjunto de registradores. A estrutura TableGen será usada para gerar código para a maioria das informações acerca do conjunto de registradores (definição, classe, aliases, etc). Entretanto, deve ser escrito código adicional, estendendo a classe TargetRegisterInfo, que por sua vez irá descrever informações importantes utilizadas pela alocação de registradores, além das possíveis interações entre registradores; Descrição do conjunto de instruções. Assim como na descrição do conjunto de registradores, a TableGen ficará responsável por gerar código referente às definições de instruções (formato, número de operandos, itinerários, etc), além dos padrões de matching utilizados na seleção de instrução. A classe TargetInstrInfo também deve ser estendida para a arquitetura alvo, objetivando manter informações não estáticas do conjunto de instruções da arquitetura; Descrição da seleção e conversão da LLVM IR na forma de um grafo acíclico dirigido (DAG) para instruções nativas da arquitetura. A partir das definições dos padrões de instrução na descrição do conjunto de instruções, a TableGen gera métodos de seleção utilizados para a realização de matching de padrões entre instruções nativas e instruções da LLVM IR. É preciso também descrever regras para conversão de instruções e tipos de dados da LLVM IR sem suporte nativo na arquitetura. Essas regras podem ser descritas estendendo as classes SelectionDAGISel (para realizar matching de padrões e seleção de instrução de DAG para DAG específicas para a arquitetura) e TargetLowering (para substituir ou remover operações e tipos de dados não suportados); Implementação de um emissor de código que converte a LLVM IR final em formato de código de máquina para a arquitetura alvo. Classes como AsmPrinter e TargetAsmInfo devem ser estendidas para que a emissão de código seja concluída. As definições do formato assembly de cada instrução são feitas, particularmente, na descrição do conjunto de instruções. As alterações realizadas em cada um dos passos descritos serão detalhadas nas subseções a seguir TargetMachine Cada arquitetura alvo deve oferecer uma interface específica através da qual possa ser acessada pelo módulo de geração de código do LLVM. Esta classe é chamada de RVEXTargetMachine. Ela é uma implementação da classe LLVMTargetMachine e o ponto principal de comunicação entre o LLVM e o back-end ρ-vex. Nessa classe, todas as características da arquitetura alvo são obtidas, tais como conjunto de registradores, conjunto de instruções, organização da pilha, conjunto de itinerários para arquitetura, etc. Além disso, o passo de seleção de instrução da arquitetura e demais passos adicionais específicos (no caso do ρ-vex, a utilização de VLIW Packetizer, que será tratado em detalhes em 3.2.8) são registrados e adicionados ao fluxo de execução do gerador de código LLVM. Outras informações também são definidas na classe RVEXTargetMachine:

20 Back-end LLVM para o Processador ρ-vex 16 Representação de dados na arquitetura: no construtor da classe RVEXTargetMachine é definida uma string que determina a representação dos dados na arquitetura. Isto inclui tamanho de dados suportados, alinhamento de acordo com a Application Binary Interface (ABI) e alinhamento preferencial. Para o ρ-vex, os dados podem ser representados em 8, 16 e 32 bits. Um ponteiro tem tamanho fixo de 32 bits. O modelo de endereçamento de dados utilizado pelo ρ-vex é o big-endian. Versões diferentes do processador, assim como suas funcionalidades presentes ou omitidas. Apenas um modelo de processador é informado no back-end LLVM para o ρ-vex Registro da Máquina Alvo O TargetRegistry é um mecanismo do LLVM para gerenciamento e pesquisa de alvos (arquitetura ou linguagem) em tempo de execução. Cada back-end deve declarar uma instância global da classe Target, que será usada para representar a máquina alvo durante o registro. Após o registro, o objeto Target é preenchido com referências a importantes componentes do back-end (incluindo a classe RVEXTargetMachine), e uma string contendo o nome (ou uma tripla composta de strings com o nome da arquitetura, nome do fabricante e nome do sistema operacional) é salvo em uma lista de pesquisa Descrição do Conjunto de Registradores A descrição dos registradores da arquitetura consiste de uma especificação TableGen e uma implementação da classe TargetRegisterInfo para a arquitetura. Na primeira, são definidos, tipicamente, todos os registradores da arquitetura e as classes para os grupos de registradores que são tratados da mesma forma para alguma instrução. Na segunda são definidas informações sobre o conjunto de registradores que serão utilizadas pela alocação de registradores. Nessa última são descritas as interações entre os registradores. Cada registrador é um objeto da classe Register, que por sua vez consiste de um conjunto de dados referente ao objeto (registrador) instanciado. Informações como nome, nome para o formato assembly da máquina alvo e namespace são definidas nessa classe. É possível especificar o conceito de sub-registradores. Entretanto, tais funcionalidades não foram necessárias para a especificação dos registradores ρ-vex. A implementação do back-end LLVM para o ρ-vex define duas subclasses da classe Register, RVEXGRReg e RVEXBRReg, para as definições dos registradores gerais (GRs) e registradores de branch (BRs), respectivamente. Ambas as classes sobrescrevem o campo namespace (para a identificação do registrador como componente do back-end LLVM para o ρ-vex) e adicionam um campo composto de 5 bits, para a RVEXGRReg, e 3 bits, para a RVEXBRReg, usados para a identificação de cada registrador dentro do banco de registradores. Cada registrador físico concreto da arquitetura deve ser definido como uma instância de uma dessas classes supramencionadas. O identificador e o nome do registrador são passados como argumentos. A Figura 3.6 mostra um trecho da especificação TableGen dos registradores ρ-vex. Outra atividade importante na descrição do conjunto de registradores é a definição da classe de registrador e os registradores físicos que a compõe. A classe RegisterClass é estendida para cada classe presente no conjunto de registradores da arquitetura. Nela são definidas o namespace da classe, uma lista de tipos de valores (dados) suportados pelos registradores da classe, o alinhamento requerido para o armazenamento, a carga dos registradores em memória

21 Back-end LLVM para o Processador ρ-vex 17 let Namespace = "RVEX" in { class RVEXGRReg<bits<5> num, string n> : Register<n> { field bits<5> Num = num; class RVEXBRReg<bits<3> num, string n> : Register<n> { field bits<3> Num = num; def R0 : RVEXGRReg< 0, "$r0.0">; def R1 : RVEXGRReg< 1, "$r0.1">;... def B0 : RVEXBRReg< 0, "$b0.0">; def B1 : RVEXBRReg< 1, "$b0.1">;... Figura 3.6: Trecho da especificação dos registradores ρ-vex. e os registradores que fazem parte da classe. A Figura 3.7 apresenta as definições das classes de registradores do ρ-vex. def GRRegs : RegisterClass<"RVEX", [i32], 32, (add (sequence "R%u", 0, 31))> { def BRRegs : RegisterClass<"RVEX", [i1], 32, (add (sequence "B%u", 0, 7))> { let Size = 32; Figura 3.7: Definição das classes de registradores ρ-vex. O passo final da descrição do conjunto de registradores é a implementação da classe TargetRegisterInfo. Essas informações podem variar de acordo com as versões de processador suportadas pelo back-end da arquitetura definidas diretamente no formato Table- Gen. A classe RVEXRegisterInfo possui métodos que retornam informações como: o conjunto de registradores usados como callee-saved (getcallesavedregs()), conjunto de registradores reservados (getreservedregs()) e os registradores usados como ponteiro de pilha (getstackpointer()) e ponteiro do quadro de pilha (getframepointer()). Outros métodos implementados pela classe são: eliminatecallframepseudoinstr(). Este método manipula as pseudo instruções ADJCALLSTACKDOWN e ADJCALLSTACKUP, que são inseridas antes e depois de cada chamada de função durante a fase de seleção de instruções. Ambas possuem um imediato como operando que indica quantos bytes os argumentos de uma chamada de função ocupam na pilha. Normalmente, este valor é zero já que usualmente os argumentos são passados em registradores, possibilitando a simples remoção dessas instruções do bloco básico. Se a chamada de função tem um quadro de tamanho fixo, os espaços necessários para todos os argumentos são inclusos e consequentemente alocados na emissão de prólogo da função, portanto, nenhuma ação adicional é necessária. A única situação contrária é quando a chamada de função contém objetos de tamanho variável na pilha, tornando impossível

22 Back-end LLVM para o Processador ρ-vex 18 Registradores Classe Uso $r0.0 Constante Sempre zero $r0.1 Especial Ponteiro de pilha $r0.2 (N/A) Retorno de ponteiro de struct $r0.3-$r0.6 (N/A) Argumentos e valores de retorno $r0.7-$r0.25 (N/A) Temporários $r0.26-$r0.29 Preservados Temporários (callee-save) $l0.0 Especial Ponteiro de link $r0.31 Especial Para uso do Assembler Tabela 3.2: Convenção de uso para o conjunto de registradores GR do ρ-vex. determinar o tamanho máximo do quadro de pilha em tempo de compilação. Neste caso, ADJCALLSTACKDOWN e ADJCALLSTACKUP devem ser substituídas por subtração e uma adição ao ponteiro da pilha, respectivamente. No back-end LLVM para o ρ-vex ainda não há suporte ao último caso, portanto, essas instruções são removidas. eliminateframeindex(). Este método é chamado para cada instrução que referencia uma palavra de dados em um slot da pilha. Todos os passos anteriores ao gerador de código tratam o endereçamento da pilha como um índice abstrato e um imediato de deslocamento. O objetivo desta função é traduzir essa referência em um par registrador-deslocamento. Como na atual implementação do back-end LLVM para o ρ-vex só há suporte para quadros de tamanho fixo, o ponteiro de pilha é usado como registrador base. Ressalta-se ainda que o ρ-vex não possui suporte a deslocamentos maiores que 9 bits atualmente e, por isso, em casos que isso ocorre é causado uma exceção, interrompendo a geração de código Convenções de Chamada A forma como os registradores são utilizados durante a geração de código, como os argumentos são passados para uma função e como os valores de retorno são recebidos de uma função, são características específicas de uma arquitetura. A ABI define um conjunto de regras que devem ser rigorosamente satisfeitas. A ABI definida na ISA VEX especifica as convenções de chamada para processadores nela baseados. Entrentanto, tais convenções não são completamente aplicáveis ao processador ρ-vex tendo em vista suas limitações (como o número de registradores, por exemplo). Para este trabalho, algumas mudanças (simplificações) na convenção de chamada da ABI VEX foram realizadas, a começar pela convenção de uso dos registradores. Na Tabela 3.2 é apresentada a convenção de uso aplicada no back-end ρ-vex. Outra questão importante é como são realizadas as chamadas de funções e consequentemente o uso da pilha para passar argumentos e retornar valores. Na adaptação da ABI VEX para o processador ρ-vex, os argumentos de funções são primeiramente alocados em uma lista conceitual, que é então mapeada em uma combinação de registradores e pilha, onde os primeiros 16 bytes da lista de argumentos são passados em registradores, e o restante é passado na pilha. Cada 4 bytes é chamado de slot de argumento. Argumentos menores que 4 bytes, e também ponteiros, são alinhados dentro de um slot de argumento, e argumentos maiores que 4 bytes são alinhados em um limite de 8 bytes, dentro de dois slots de argumento. Para o retorno de função, valores de retorno menores que 4 bytes são retornados no registrador $r0.3 e valores de retorno

23 Back-end LLVM para o Processador ρ-vex 19 maiores que 4 bytes são retornados nos registradores $r0.3 e $r0.4. Valores de retorno agregados menores que 16 bytes são alinhados em múltiplos de 4 bytes e retornados em registradores gerais sucessivos, a partir do registrador $r0.3. Por fim, valores de retorno maiores que 16 bytes são retornados em um buffer, alocado pela função chamador e um ponteiro para esse buffer é passado no registrador $r0.2. No LLVM as convenções de chamada são descritas utilizando a classe CallingConv da Table- Gen que, por sua vez, consiste de uma lista de ações que são analisadas em ordem para cada argumento ou valor de retorno de uma subrotina. A Figura 3.8 apresenta os registros RetCC RVEX e CC RVEX. O primeiro descreve a convenção para os valores de retorno, e o segundo descreve a convenção para a chamada de subrotina com argumentos. def RetCC_RVEX : CallingConv<[ CCIfType<[i32], CCAssignToReg<[R3, R4, R5, R6]>>, CCAssignToStack<4, 4> ]>; def CC_RVEX : CallingConv<[ CCIfType<[i8, i16], CCPromoteToType<i32>>, CCIfType<[i32], CCAssignToReg<[R3, R4, R5, R6]>>, CCAssignToStack<4, 4> ]>; Figura 3.8: Definição das classes de registradores ρ-vex. Apesar de não existir suporte a chamadas de função na versão do ρ-vex usada neste trabalho, a descrição foi necessária devido ao seu uso no estágio de seleção de instrução. Especificamente, no passo de conversão da LLVM IR em SelectionDAG denominado lowering (que será detalhado na Subseção 3.2.6) Descrição do Conjunto de Instruções A descrição, manipulação e transformação de instruções constitui a parte central do back-end. O gerador de código precisa de informações completas e detalhadas sobre os nomes, opcodes, operandos, comportamento e efeitos de cada instrução dentro da arquitetura alvo. A descrição do conjunto de instruções é distribuída em arquivos TableGen, onde são definidos a estrutura abstrata que represente as instruções da máquina alvo junto a formatos genéricos para conjuntos de instruções semelhantes (RVEXInstrFormats.td) e uma descrição de uma instrução concreta (RVEXInstrInfo.td). É importante observar que uma instrução LLVM corresponde a uma sílaba VLIW do processador ρ-vex. Para definição do conjunto de instruções de uma arquitetura no LLVM, o primeiro passo é a extensão da classe Instruction, que contém, entre outros, os seguintes campos: Operandos de saída: contêm o valor (ou valores) resultado da execução da instrução; Operandos de entrada: contêm os valores usados pela instrução como argumentos de entrada; Formato Assembly: usado pelo emissor de código, contém o formato que representa a instrução em código de máquina;

24 Back-end LLVM para o Processador ρ-vex 20 Padrão: contêm o padrão referente a uma instrução LLVM IR na forma de SelectionDAG, que é usado pelo seletor de instrução para produzir uma instância de uma instrução da arquitetura alvo correspondente. Como extensão de Instruction, a classe InstRVEX é uma classe abstrata que descreve características genéricas a cada definição de instrução concreta do processador ρ-vex como o tamanho, namespace e formato da instrução. Os formatos são subclasses que determinam a codificação comum a um grupo de instruções. Como visto na Subseção 3.1.3, o ρ-vex possuiu 4 formatos genéricos de operação, com extensões específicas para algumas operações (como é o caso das instruções de ALU: ADDCG, DIVS, SLCT e SLCTF; das instruções de CTRL: GOTO, CALL, BR, BRF, RETURN e RFI; e das instruções de MEM: LDW, LDH, LDHU, LDB, LDBU, STW, STH e STB). São definidos três formatos para operações de ALU e MUL, um formato para operações de CTRL e um formato para operações de MEM. Tendo em vista esses casos, foram definidas as classes RTYPEInst, ISTYPEInst, BRANCHInst, RTYPE BSInst e MEMTYPEInst, que representam os seguintes formatos, respectivamente: RTYPE (Register): formato comum para a maioria das instruções de ALU e para todas as instruções de MUL. O formato RTYPE (Veja a Figura 3.9) é utilizado por instruções apenas com operandos do tipo registrador e define os campos para, opcode (op), immediate switch (SS), resultado em registrador GR (dst), operandos (src1 e src2 ), resultado em registrador BR para operações de comparação (dstbr) e flags para indicar se a operação é a primeira ou última operação de uma instrução VLIW (L e F ). Como os três operandos são registradores, o campo de immediate switch é declarado com 0 (no immediate value). ISTYPE (Short Immediate): assim como o formato RTYPE, é utilizado pela maioria das instruções de ALU e todas instruções de MUL. O formato ISTYPE (Veja a Figura 3.10) é utilizado por instruções compostas de um imediato como operando e define os campos de opcode (op), immediate switch (SS), resultado em registrador GR (dst), primeiro operando em registrador GR (src1 ), segundo operando do tipo imediato (imm9 ) e flags para indicar se a operação é a primeira ou última operação de uma instrução VLIW (L e F ). O campo immediate switch é declarado com 1 (short immediate).; ILTYPE (Long Immediate): formato para instruções compostas de um imediato maior que 9 bits (não suportados pelo formato ISTYPE). Não é suportada na atual versão do ρ-vex, mas foi descrita no back-end para futuras implementações; BRANCH (Branch Offset Immediate): formato comum para as instruções de CTRL. O formato BRANCH (Veja a Figura 3.11) é utilizado pelas instruções GOTO, CALL, BR, BRF, RETURN e RFI e define os campos opcode (op), immediate switch (SS), registrador de link (lr), endereço de desvio (imm12 ), registrador de branch para desvios condicionais (srcbr), e flags para indicar se a operação é a primeira ou última operação de uma instrução VLIW (L e F ). O campo immediate switch é declarado com 2 (branch offset immediate); RTYPE BS (Register BS): formato para as instruções ADDCG, DIVS, SLCT e SLCTF (Veja Figura 3.12). Seus campos são definidos de acordo com a especificação de tais instruções na Subseção 3.1.3; MEMTYPE (Memory): formato para instruções de MEM (Veja a Figura 3.13). Define os campos opcode (op), immediate switch (SS), resultado em registrador GR (dst), endereço

25 Back-end LLVM para o Processador ρ-vex 21 de memória em registrador (addr), imediato de deslocamento (imm9 ) e flags para indicar se a operação é a primeira ou última operação de uma instrução VLIW. O campo immediate switch é declarado com 1 (short immediate). Figura 3.9: Formato RTYPE. Figura 3.10: Formato ISTYPE. Figura 3.11: Formato BRANCH. Figura 3.12: Formato RTYPE BS. Figura 3.13: Formato MEMTYPE. Também é definido um formato, denominado PSEUDOInst, para pseudo instruções inseridas pelo LLVM durante a geração de código (como ADJCALLSTACKDOWN e ADJCALLSTACKUP por exemplo). Essas instruções são usadas em passos específicos para auxiliar na geração de código e, após seu uso, são removidas (ou substituídas por instruções da arquitetura alvo) antes da emissão de código. Embora a descrição da codificação seja apenas relevante se a arquitetura suportar compilação Just-in-Time (o que não é o caso do ρ-vex) foi decidido respeitá-la na descrição do conjunto de instruções. Após a descrição dos formatos, é necessário definir uma instrução concreta. Tal instrução é uma instância de um formato definido anteriormente. A Figura 3.14 exemplifica a descrição de uma instrução ρ-vex. Note que, em sua definição, a instrução declara o opcode da instrução, o tipo do resultado e dos operandos que a compõe (no caso, registradores), o formato assembly usado na emissão de código, o padrão usado para a seleção de instrução e o itinerário (usado no escalonamento de instruções).

26 Back-end LLVM para o Processador ρ-vex 22 def ADDrr : RTYPEInst< 65, // Opcode (outs GRRegs:$dst), // Resultado (ins GRRegs:$src1, GRRegs:$src2), // Operandos "add $dst = $src1, $src2", // Formato assembly [(set (i32 GRRegs:$dst), // Padr~ao (add (i32 GRRegs:$src1), (i32 GRRegs:$src2)))], iialu>; // Itinerário Figura 3.14: Definição das classes de registradores ρ-vex. A classe RVEXInstrInfo contém informações não estáticas referentes ao conjunto de instruções. Essas informações constituem-se em métodos que auxiliam na análise, transformação e inserção de certas instruções de máquina. Esses métodos só são chamados após o escalonamento de instruções, quando já não existe mais o SelectionDAG. Operações como análise e conversão de branch (quando existem dois branchs seguidos e o segundo pode ser removido caso o primeiro seja incondicional), inserção de instruções para mover dados de um registrador virtual para um registrador físico, inserção de NOPs (no operation) e manipulação de memória, são realizadas por métodos definidos na classe RVEXInstrInfo TargetLowering O processo de preparar o programa de entrada para o estágio de seleção de instruções, convertendo-o de formato lista de instruções para um grafo acíclico dirigido (SelectionDAG) é chamado de lowering. Este é o primeiro passo do procedimento de geração de código. Para cada instrução da LLVM IR uma instância da classe SDNode (nó do SelectionDAG) é criada. Um SDNode contém as seguintes informações: Opcode: um inteiro que identifica a instrução representada pelo nó; Resultados (definitions): lista de resultados; Operandos (uses): lista de operandos do nó que é composta de SDValues, o qual encapsula um ponteiro para o nó de dependência e o índice do valor do nó afetado pela dependência. O esforço principal na construção do SelectionDAG vem das classes SelectionDAGBuild e TargetLowering. A classe RVEXTargetLowering, subclasse de TargetLowering, oferece a sua super classe informações da arquitetura, incluindo classes de registradores e tipo de dados suportados (tipos de 32 bits para registradores gerais e tipos de 1 bit para registradores de branch) e método de escalonamento preferêncial (escalonamento para arquiteturas VLIW). Outra informação importante definida na classe RVEXTargetLowering é a de quais instruções não podem ser reduzidas a instruções nativas de forma automática, requerendo intervenção manual. Essas instruções podem ser substituídas por instruções equivalentes (da própria LLVM IR) capazes de serem convertidas em instruções da arquitetura alvo. Ou então, em casos onde a instrução não é suportada devido ao tipo de dado dos operandos, é feita uma divisão (ou expansão) desses tipos para tipos suportados.

27 Back-end LLVM para o Processador ρ-vex 23 Na atual versão do back-end, algumas das interverções feitas são na redução das instruções de multiplicação MULHS, MULHU, SMUL LOHI e UMUL LOHI com operandos de 32 bits para instruções equivalentes com operandos menores. As duas primeiras realizam multiplicação (MULHS com sinal e MULHU sem sinal) entre dois operandos de um tipo com N bits, produzindo um valor de 2N bits onde o resultado é apenas os N bits mais significativos do valor. As duas últimas funcionam de forma semelhante (SMUL LOHI com sinal e UMUL LOHI sem sinal) retornando tanto a parte mais significativa quanto a parte menos significativa, ou seja, o valor total com 2N bits. As unidades de multiplicação do ρ-vex não suportam multiplicações 32 por 32 bits e o conjunto de instruções VEX não oferece formas de manipular operações de maneira a obter resultado equivalente às instruções da LLVM IR descritas anteriormente com operandos de 32 bits. Consequentemente a instrução MUL (multiplicação simples retornando o valor total) com operandos de 32 bits também não é suportada diretamente pelo ρ-vex. Nesse caso, são criadas duas instruções ρ-vex para realizar operação semelhante, mas essa intervenção é feita já na seleção de instruções, diretamente de uma instrução LLVM IR para instrução ρ-vex. Instruções de divisão e módulo ainda não são completamente suportadas pelo back-end LLVM para o ρ-vex. Essas instruções, por hora, são reduzidas em instruções de multiplicação pelo seletor de instruções. É importante destacar que em alguns casos o seletor de instruções não consegue fazer manipulações de forma a produzir instruções equivalentes, necessitando de tratamento específico (em software), o que ainda não é feito na atual versão do ρ-vex Seletor de Instrução Como visto na Subseção 2.4.2, o estágio de seleção de instrução é o momento em que o programa fonte é convertido da representação intermediária para instruções da máquina alvo. A maior parte das informações usadas na seleção de instruções são geradas automaticamente pela TableGen (a partir das definições do conjunto de instruções da arquitetura). Entretanto, há casos em que o seletor de instruções não consegue definir uma conversão válida para uma operação ou tipo de dados. No back-end LLVM para o ρ-vex os seguintes casos são convertidos manualmente: Imediatos maiores que 9 bits: imediatos (ou constantes) maiores que 9 bits gerados pelo LLVM são filtrados na seleção de instrução. É feita uma manipulação, em software, do tipo de dado de forma a passar o seu conteúdo para um registrador. Operações OR e SHL do ρ-vex são inseridas no código final; Instruções de multiplicação: as unidades de multiplicação VEX só realizam multiplicações 16 por 32 bits. Nesse caso, são geradas duas instruções ρ-vex para obter-se resultado equivalente, mas mesmo assim com perda da parte significativa (a partir do bit 31). A mesma situação ocorre com operandos de 32 bits cada um VLIW Packetizer O VLIW Packetizer é um componente LLVM criado para possibilitar o suporte a arquiteturas VLIW. Nele, o conjunto de instruções é analisado de forma a criar pacotes (bundles) de instruções sem nenhuma dependência entre elas, mapeadas em unidades funcionais disponíveis da arquitetura. O processo de criação de bundles inicia com a criação de um autômato finito determinístico a partir dos itinerários definidos no conjunto de instruções. O autômato representa

28 Back-end LLVM para o Processador ρ-vex 24 os estágios do processo de análise e escolha da próxima instrução que irá compor um bundle. O back-end LLVM para o ρ-vex utiliza esse componente em seu fluxo de geração de código Emissão de Código A fase final da geração de código é a emissão do programa resultante das fases anteriores em formato de código de máquina da arquitetura alvo. O processo de emissão consiste na leitura de cada instrução gerada e a chamada de métodos auxiliares para a impressão do código de máquina correspondente. Tais métodos utilizam informações geradas pela TableGen tornando o processo de emissão de código simples e automático. As únicas alterações feitas pelo back-end LLVM para o ρ-vex nessa fase são referentes a impressão das informações que compõem o cabeçalho de um arquivo no formato assembly para o ρ-vex. 3.3 Considerações Finais Este capítulo abordou o processo de desenvolvimento do back-end LLVM para geração de código para o processador ρ-vex. Nessa apresentação foi possível observar as características e limitações do processador ρ-vex e o desafio de gerar código para um processador com várias restrições para execução de código. A apresentação do back-end LLVM foi detalhada visando apresentar todas as características que devem ser levadas em conta quando da geração de backends LLVM para outras arquiteturas. O Capítulo 4 apresenta e discute os experimentos e resultados obtidos com a validação e avaliação do código gerado pelo LLVM para o processador ρ-vex.

29 Capítulo 4 Experimentos e Resultados Este capítulo apresenta o processo de validação do back-end ρ-vex, além da análise de desempenho dos códigos gerados em comparação com o VEX Toolchain [3], principal ferramenta para geração e simulação de código para máquinas baseadas na ISA VEX, e que acompanha o processador ρ-vex. Na Seção 4.1, os passos para a validação são apresentados em detalhe. Na Seção 4.2 é feita uma análise comparativa dos resultados obtidos com back-end LLVM e com VEX toolchain na geração de código para o processador ρ-vex. 4.1 Validação do Back-End LLVM O processo de validação do back-end ρ-vex, consistiu na geração de código para um conjunto de programas já adaptados para o processador ρ-vex. Tais programas já foram organizados de forma a respeitarem as limitações da atual versão do processador. O conjunto de programas utilizados é composto por 21 programas, dos quais 9 fazem parte do Trimeran Compiler Suite (Simple benchmarks) [11], e os demais (binary tree, counting sort, double linked list, floyd warshall, kruskal, linked list, local var, longlong, mergesort, parms test, prim e struct test) são implementações de algoritmos clássicos de ordenação e manipulação de estruturas de dados. A Tabela 4.1 apresenta os programas utilizados e uma breve descrição de cada um. Deve-se observar que programas maiores de benchmarks conhecidos (como SPEC, Media- Bench e Mibench, por exemplo) não foram utilizados nos experimentos devido a ausência de ferramentas de link-edição disponíveis para o processador ρ-vex. Isso obriga a remoção de todas as chamadas a funções presentes em bibliotecas externas, como manipulação dinâmica de grande quantidade de memória, impressão e leitura de textos em tela e arquivos, entre outras. Outra limitação reside no fato de que o ρ-vex não suporta imediatos maiores que 9 bits, como visto na Subseção 3.2.7, e com isso não é possível realizar o carregamento e armazenamento de dados em endereços de memória muito distantes entre si. Isso se torna um problema quando um programa possui muitas funções e realiza um trabalho intenso de pilha com chamadas de funções com muitas variáveis locais, gerando um stack frame muito extenso. Também é impossível a essas funções endereçarem e acessarem variáveis globais do programa, que se encontram em uma posição muito distante na pilha com relação ao stack frame da função em execução. Dessa forma, todas as funções em um programa devem ser expandidas inline internamente na função main de forma a preservar o endereçamento global de variáveis, cuidando para que o 25

30 Experimentos e Resultados 26 Programas binary tree counting sort dag double linked list eight fact2 fib mem fir floyd warshall hyper kruskal linked list local var longlong mergesort mm dyn nested parms test prim strcpy struct test Descrição Balanceamento de árvores Ordenação Desvios internos à loop (if-then-else) Estrutura de dados Desvios internos à loop (label-goto) Fatoração utilizando loop Calculo de número Fibonacci utilizando vetor Filtro de Resposta de Impulso Finito Algoritmo de caminho mínimo Desvios internos à loop (if-then-continue) Árvore geradora mínima Estrutura de dados Variáveis locais utilizando vetor Variáveis do tipo long long Ordenação Matriz alocada dinamicamente Encadeamento de loops Passagem de parâmetros Árvore geradora mínima Cópia de strings Estrutura de dados Tabela 4.1: Conjunto de programas utilizados para a validação do back-end LLVM. tamanho da pilha de variáveis locais não ultrapasse a capacidade de deslocamento do imediato de 9 bits. Os códigos gerados para o ρ-vex pelo VEX Toolchain, assim como pelo back-end LLVM, precisam respeitar as limitações do processador. Para isso, a geração de código com o VEX Toolchain segue um padrão, composto de um modelo de máquina 1 e parâmetros de compilação que possibilitam a geração de código funcional para o ρ-vex. O modelo de máquina utilizado descreve todas as características do processador ρ-vex. Os parâmetros utilizados na compilação impõem algumas condições para a geração de código: -fno-xnop: faz com que instruções XNOP não sejam emitidas no código gerado. Ao invés de XNOPs, são emitidas instruções NOP. Isso se deve ao fato de que instruções XNOPs são instruções de controle de pipeline e o processador ρ-vex é um processador multiciclo; -fexpand-div: faz com que o compilador substitua chamadas a bibliotecas internas para divisão de inteiros por código inline para tais operações. Como descrito anteriormente, o ρ-vex não suporta chamadas externas; -mglob preserved registers=0: utilizado devido a um bug presente na atual versão do VEX Toolchain, onde, em alguns casos, o compilador gera código com registradores não definidos no modelo de máquina. Isso acontece pois o compilador mantém as definições de 1 Determina os recursos da máquina para qual será gerado código, como o número de unidades funcionais e quais os tipos disponíveis, banco de registradores e a quantidade de registradores que os compõe, quantidade de clusters VEX utilizados, etc.

31 Experimentos e Resultados 27 uso de registradores do conjunto de registradores original para conjunto de registradores menores, assim, os registradores preservados eram mantidos e emitidos incorretamente em modelos de máquina onde não estavam presentes. A correção é feita definindo o número de registradores preservados como 0. As compilações com LLVM não utilizam nenhum parâmetro ou passo adicional, devido às características do back-end serem específicas do ρ-vex. Com isso, todas as limitações do processador já foram incorporadas no back-end LLVM durante o desenvolvimento. A Figura 4.1 apresenta o fluxo de validação do back-end LLVM para o ρ-vex. Dado um programa em C (.c), o primeiro passo (1) é compila-lo com o LLVM, o Compilador C do VEX Toolchain (VEX C Compiler) e o GCC. As saidas do LLVM e do VEX C Compiler são códigos assembly VEX (.s) e cada uma será parâmetro de entrada para o segundo passo do fluxo de validação (2) que consiste na geração de binários executáveis para a máquina host (máquina na qual está instalado o VEX Toolchain) utilizando a ferramenta de simulação VEX (VEX Simulator), também presente no VEX Toolchain [12, 5, 4]. O simulador VEX transforma o código assembly em um programa em C, que por sua vez é compilado para a arquitetura da máquina host (com o GCC) gerando um binário executável (.out) e possibilitando a utilização de ferramentas de depuração nativas (no caso o GDB [?]) para a análise da memória, valores dos registradores e valores de retorno (LLVM return, VEX C return e GCC return). Como o GCC é nativo a máquina host, a saida de sua compilação já é um binário executável. Os binários executaveis resultantes do processo de geração de código com cada compilador (LLVM, VEX C Compiler e GCC) são então depurados com o GDB e suas saídas (escritas em memória ou em registradores) são comparadas, finalizando o processo de validação (3). Assim, considerou-se que os programas gerados pelo LLVM são validos se suas saídas são iguais às saídas dos programas gerados pelo VEX C Compiler e GCC. Deste processo, 7 programas não foram considerados validos e consequentemente não foram utilizados para avaliação de desempenho. Os programas eight, hyper e fir apresentam instruções de divisão e módulo, e devido as limitações da atual versão do back-end LLVM para o ρ-vex (como visto na Subseção 3.2.6) tais instruções não são tratadas corretamente durante a seleção de instrução. Nos programas fact2, mergesort e strcpy a LLVM IR apresenta instruções de comparação com operandos de tamanhos específicos sem equivalentes diretos nas instruções VEX. Casos como esse ainda não são tratados no back-end. O programa prim tem codígo gerado com um deslocamento de pilha maior que 9 bits, sendo assim desconsiderado durante a validação. Figura 4.1: Visão do fluxo de validação do back-end LLVM para o ρ-vex.

32 Experimentos e Resultados 28 A próxima Seção apresenta a análise de desempenho realizada sobre os códigos (validos) gerados pelo back-end LLVM em relação a os códigos gerados pelo VEX C Compiler. 4.2 Avaliação de Desempenho As Tabelas 4.2 e 4.3 apresentam os resultados de caracterização e desempenho sobre os códigos gerado pelo LLVM e pelo VEX Toolchain. Nota-se que a maioria dos programas gerados com o VEX Toolchain apresentam desempenho melhor (menor valor na coluna Total de Ciclos) em relação aos mesmos gerados pelo LLVM. Esse fato, de certa forma, já era esperado, devido ao compilador do VEX Toolchain ser uma implementação mais madura e otimizada, enquanto o back-end LLVM para ρ-vex ainda implementa somente funcionalidades básicas de geração de código. A Figura 4.2 apresenta o speedup de desempenho do back-end LLVM sobre o VEX C Compiler. Figura 4.2: Speedup do desempenho do back-end LLVM sobre o VEX C Compiler. Programas Total Ciclos Ciclos Op. Ger. Op. Exec. Inst. Ger. Inst. Exec. Miss Mem. Miss Mem. de Ciclos de Exec. de Stall Inst. (%) Dados (%) binary tree ,77 9,09 counting sort ,69 3,98 dag ,2 50 double linked list ,17 0,17 fib mem ,27 6,92 floyd warshall ,75 1,95 ifthen linked list ,04 0,05 local var test ,08 8,33 longlong ,32 29,41 mm dyn ,5 4,46 nested ,01 17,02 parms test ,32 21,74 struct test ,9 10,2 Tabela 4.2: Programas Compilados com o LLVM. Nos programas gerados pelo back-end LLVM que obtiveram pior desempenho (counting sort, dag, fib mem, floyd warshall, ifthen, local var test, longlong, mm dyn e struct test) deve-se destacar algumas características da geração de código: