Re: STUB_MOVE in elfxx-mips.c

[Ian Lance Taylor <ian at wasabisystems dot com>]

cgd@broadcom.com writes:

> At 01 Oct 2003 09:38:17 -0700, Ian Lance Taylor wrote:
> > There was a processor from IDT which has this property.
> 
> Could that be construed to say:
> 
>         "we should support doing it either way, depending on what CPU
>         is being tuned for?"
> 
> because if you're going to violate peoples' expectations to implement
> an optimization for a specific processor (which ultimately makes the
> assembler implementation more complex), then shouldn't you afford that
> opportunity for other processors?

Sure.  As I said, it seemed to me at the time that `add' would never
be slower than `or', so it seemed reasonable to always use `add' as
the implementation of the `move' pseudo-op.  Which is what the
assembler does today.  And it still seems reasonable to me.

> No, I don't have a performance bias for either 'add' or 'or' for my
> parts.  However, I do have a strong bias against code the implements
> things in violation of peoples expectations, and, most especially code
> that tells you that two things are the same, when they're not (e.g.,
> disassembler).

You're quite right about the disassembler.  I would support a patch to
simply move the `move' pseudo-op to the end of the opcode table, so
that the move was disassembled as the actual instruction (and remove
the disassembly of `or' as `move').  This would presumably break the
testsuite somewhat.

Ian