[RFC,MIPS] Changing the mapping for the 'move' instruction

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Hi all,

The MIPS move instruction is an alias which currently maps as follows:

move dest, src
32-bit GPRS -> addu dest, src, $0
64-bit GPRS -> daddu dest, src, $0

This behaviour was introduced with binutils-gdb commit 8d67dc307 which
was made way back on "Tue Nov 26 15:59:18 1996" by Ian Lance Taylor.
The main purpose of the commit was to implement MIPS16 support.

Prior to this point the MIPS move instruction mapped to:

or dest, src, $0

(This mapping is also the one which happens to be listed in
'See MIPS Run'; not that it holds any real weight)

The only reference I can find for using d?addu over or is in this post:

http://www.sourceware.org/ml/binutils/2000-09/msg00455.html

<extract>
Some of the advanced MIPS chips have two addition pipelines, but only
one logical pipeline.  Using addu/daddu means that it is more likely
that the instruction will execute in parallel with other instructions.
This was actually pointed out by some MIPS hardware vendor, but I
don't remember which one.
<end>

The RFC is basically whether anyone objects to changing this back to
use 'or'?

This issue was identified during performance analysis of a recent
64-bit design by Imagination and the use of addu for 32-bit moves
can inhibit some pipeline forwarding optimisations as the addu has
to sign extend in 64-bit implementations. I suspect there are ways
to deal with this in hardware but regardless it seems sensible to
use the same instruction for move in 32-bit and 64-bit code.

Assuming there are cores that would specifically benefit from other
encodings for move instructions... then I think we can legitimately
hang that off a specific -march= option as it is likely to be an
exception rather than the rule.

Does anyone know of specific cores/range of cores that are optimized
based on move being encoded as addu?

Thanks,
Matthew