Re: MIPS gas relaxation still doesn't work

[Jim Wilson <wilson at redhat dot com>]

Your historical info is only partly accurate.

You are right about the beginning part.  In the beginning there was MIPS,
and MIPS wrote a toolchain that tried to be friendly to assembly language
programmers.  Because of this, some optimizations, mainly instruction
scheduling and delay-slot filling, were implemented in the assembler instead
of the compiler, so that they would be usuable to assembly language
programmers.  Since gcc/binutils usually follows conventions set by the
vendor, gcc/binutils did things the same way.

Later, gcc started using its own instruction scheduler and delay-slot filling
optimization passes, but we never fully moved away from relying on assembler
optimizations.

>The first GCC ports for MIPS were quick hacks using the MIPS
>assembler. They made liberal use of what were effectively macro
>instructions. 

I think this is inaccurate in a number of ways.  It is a gcc convention
to use the native assembler whenever possible, and be compatible with the
native assembler language.  We write our own assembler only when the native
one isn't good enough to bootstrap gcc, or when there is no other native
assembler, e.g. embedded and linux targets.  Similarly, we create our own
assembler language only when there isn't an existing one we can use.  So there
was nothing wrong with using the MIPS/SGI assembler for the original gcc ports.
Also, gcc followed the conventions set by the MIPS/SGI compilers, which used
macro instructions very heavily.  Thus gcc used macro instructions heavily
also.  In hindsight this was a mistake, but at the time it wasn't so obvious.

>Which got a whole lot worse when gcc/gas was hacked again for position
>independent code and the bulk of that work was done in the assembler.

I agree everything got a lot uglier when PIC support was added.  However,
it was SGI that did it first in the assembler, and gcc/gas just followed
exactly the conventions that were defined and implemented by SGI, in order
to maintain compatibility with SGI systems.

When we added PIC support for embedded systems, it was just more of the same.

>But getting the assembler macros out of the compiler is a long-overdue
>reform.

Definitely.

SGI eventually realized their original toolchain design was limiting their
performance, and when SGI introduced their 64-bit Irix6 workstations, they
used this as an excuse to write a new compiler from scratch in which all
optimizations were performed in the compiler, and no assembler optimizations
were used at all.  Gcc has unfortunately not made the switch over yet, but
people are working on it.  Once again, we are following conventions defined
by SGI.

Jim