This is the mail archive of the
mailing list for the binutils project.
[RFC,MIPS] Changing the mapping for the 'move' instruction
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>, "Maciej W. Rozycki (macro at linux-mips dot org)" <macro at linux-mips dot org>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>, Ian Lance Taylor <iant at google dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 2 Mar 2015 10:00:47 +0000
- Subject: [RFC,MIPS] Changing the mapping for the 'move' instruction
- Authentication-results: sourceware.org; auth=none
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:
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.
The RFC is basically whether anyone objects to changing this back to
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?