[FUG-BR] [Off-Toppic] GCC

[Jean Everson Martina]

Bom pra dar meus dois centavos.

    Eu ja fiz este tipo de analise ha uns 2 anos num projeto de 
criptoanálise, onde nós tinhamos que fazer simulações de cifragem de 
2^48 vezes do AES por exemplo. Essa historia de colocar a função no meio 
do codigo economiza pelo menos 2 intruções. Tem outra opções legais, 
tais como --funrolloops, que desdobra todos os loops que tem o controle 
do numero de interações decidíveis em tempo de compilação. O tamanho do 
executavel aumenta consideravelmente, mas quando o tempo de carga é 
infimo quando comparado ao da execução, então carregar 20k ou 2M 
realmente não faz diferença. No nosso caso conseguiamos retirar mais de 
2^100 instruções executaveis de um codigo de 1500 linhas so usando as 
otimizações do GCC.
    Ainda assim usando -O3 e um saco de outras opções, ainda dava pra 
otimizar qualquer coisa na mão :)


Jean Martina
   

Joao Rocha Braga Filho wrote:
> On Jan 2, 2008 10:01 AM, Ricardo Nabinger Sanchez <rnsanchez at gmail.com> wrote:
>   
>> On Wed, 2 Jan 2008 00:23:21 -0200
>> "Joao Rocha Braga Filho" <goffredo at gmail.com> wrote:
>>
>>     
>>> Alguém já olhou a geração de código de um gcc atual?
>>>       
>> Sim.
>>
>>     
>>> Com a opção -O3, se uma função for "static" e só é chamada uma
>>> vez, ele some com ela introduzindo o código no local de chamada.
>>>       
>> static em funções diz ao compilador que ela é local àquela unidade de
>> compilação (.o), e portanto o símbolo gerado não será visível.  Sendo
>>     
>
> Sim.. e eu contava com a possibilidade da função sumir, mas ele sumiu
> até mesmo  com os símbolos e integrou até mesmo as funções grandes.
>
>   
>> assim, não tem porque o compilador criar uma entrada para ele na .symtab
>> se ninguém vai usar.  Em outras palavras, isto está OK.  :)
>>
>>     
>>> E tem mais. Uma printf para só imprimir uma string é trocada por
>>> uma puts, e com passagem de parâmetros por registradores, e não
>>> por pilha. Ele faz isto em muitas outras coisas. Eu já tinha ficado
>>> meio assombrado com o que ele fazia a alguns anos atrás, mas o
>>> pessoal ainda deu mais um capricho agora.
>>>       
>> Esse e mais um monte de truques.
>>     
>
> Como a printf com passagem de parâmetros por registrador. :^)
>
>   
>>> Eu descobri isto parando o compilador a etapa do assembler, com
>>> a opção -S. Estou usando a versão AMD64.
>>>       
>> Tem uma outra onde tu pode ver a saída de cada estágio, inclusive os de
>> otimização.  Gera um montão de arquivos, alguns que não tem como
>> entender sem conhecer a estrutura interna do GCC, mas interessantes
>> mesmo assim.
>>     
>
> Eu aprendi assembler do PDP 11/70 assim, com a opção -S. Comecei com
> o FORTRAN, e depois, quando comecei aprender C, fiz o mesmo. Ei ainda
> usava o adb, assembler debuger. Tinha cegado ao ponto de olhar para o
> assembler e ver na minha mente o código que o gerou. Mas com o nível de
> otimização atual isto é muito difícil.
>
> Lá pela versão 2.x o gcc já modificava loops por conta própria, e muitas
> outras coisas. Se você fizesse um loop de 0 a 10, e a variável de controle
> não fosse usada dentro do loop, ele invertia por conta própria, pois é mais
> fácil testar se é zero do que qualquer outra coisa.
>
> Eu achei uma pena a AMD não ter feito o processador de 64 bits dela
> ortogonal, como os PDP 11, os VAX e os Motorola 68K. Seria muito bom
> de entender o código assembler e geraria menos código.
>
>
> João Rocha.
>
>
>   
>> --
>> Ricardo Nabinger Sanchez                   rnsanchez at gmail.com
>> Powered by FreeBSD                  http://rnsanchez.wait4.org
>>
>>   "Left to themselves, things tend to go from bad to worse."
>>
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
>>     
>
>
>
>