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 <[EMAIL PROTECTED]> wrote:
>
>> On Wed, 2 Jan 2008 00:23:21 -0200
>> "Joao Rocha Braga Filho" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
>> 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
>>
>>
>
>
>
>
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
