re: Compiler Optimizing assembler

In my experience, the benefits of assembly language optimization are
far more limited than the kind of improvements you see from compiler
optimizers for two reasons: The source program is far less abstract
leaving fewer optimization options available to the optimizer. For
example, can the optimizer reassign registers? Usually it cannot
since the register assignments are a mix of the programmer's
individual choices and some (undocumented) external interface
specification. Second, often the reason that compiler optimizers show
improvement is that the first cut at code generation has produced a
number of "silly" sequences that are easily recognized and
transformed. (I am talking about the final optimization passes that
might be applicable to assembly language: peephole pattern matching,
dead code elimination, etc.) Why do most compilers have dead code
elimination? Is it that programmers waste their time writing dead
code all day? No. Usually the compiler generates some code and as
the result of some later optimization it becomes dead. Hence the need
for a dead code eliminator. Since most moderately gifted assembly
language programmers avoid wasteful constructs in the first place, an
assembly optimizer will likely have less opportunity for improvement.


Having said that, you may find some pattern-matched code
transformations beneficial in those cases where a particular
instruction sequence occurs frequently because it had been optimal on
the hardware of the day, but a different sequence would prove better
for modern hardware. Once you have established the framework of the
pattern matcher and transformer, the cost of your investment would be
proportional to the number of patterns you target.


/Jack Raitto
--

Return to the comp.compilers page.
Search the comp.compilers archives again.