Re: assembly optimizations...

[Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>]

tranx nouvel wrote:
> and i notice a simple optimization was missing :
>         addl $16,%esp
>         addl $-12,%esp

The problem is that the value of %esp isn't tracked like an ordinary
register, so redundant computations aren't combined.

>         pushl $4
>  ; we could even have thought merge the previous one doing movl $4,$-4(%esp)
>  ; but i admit it would be a much harder algorithm

No, that isn't possible in most environments.  You can receive signals
or interrupts (depending on the environment), which may clobber memory
below %esp at any time.

Therefore movl $4,-4(%esp) is right out.  (A compilation flag to enable
such behaviour is a possibility though, if you are absolutely sure the
stack below %esp is preserved (e.g. sigaltstack() can guarantee this).

>         call __builtin_new
>         addl $16,%esp
>         movl $3,(%eax)
>         addl $-8,%esp
> ; this one can be optimized with the previous one

This is one case where a simple peephole optimiser looking for
sequential stack operations wouldn't work -- but a slightly better one
would of course.

> once again ...
> again ...

Yes there are a lot of them aren't there?

> I so on the page relative to misoptimized assembly gcc output, that we
> encounter the same kind of mergeables operations when accessing some
> contiguous memory that can be merged and assigning them constants.
> 
> Is there an optimisations in gcc that check mergeable assembly
> operations planed ?

The problem with %esp in particular is that you can't optimise it like
other registers.  Precisely because you have to assume memory below %esp
may be clobbered at any time.  It seems likely someone will address this
because there are so many obviously redundant instructions.

Mergeing contiguous memory accesses is a different optimisation that I
don't think would help in your example.

-- Jamie