This is the mail archive of the
mailing list for the binutils project.
Re: [RFC,MIPS] Changing the mapping for the 'move' instruction
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>, Ralf Baechle <ralf at linux-mips dot org>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>, Ian Lance Taylor <iant at google dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 2 Mar 2015 18:44:13 +0000 (GMT)
- Subject: Re: [RFC,MIPS] Changing the mapping for the 'move' instruction
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320FE4CA6 at LEMAIL01 dot le dot imgtec dot org>
On Mon, 2 Mar 2015, Matthew Fortune wrote:
> 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.
This is referring to the R10k line of chips I believe (R10000, R12000,
R14000), the state of the art superscalar MIPS implementation at one time.
> 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.
I don't object.
In fact I had a case I was hit by the "wrong" kind of MOVE being used
where it took me a bit before I realised what the problem was as the
disassembler dumps MOVE rather than the name of the underlying ALU
operation. Consequently it was not immediate to me from the disassembly
that a MOVE operation was actually done with 32-bit ADDU on a 64-bit
target, leading to unwanted data truncation. I don't remember how it
happened that 32-bit ADDU ended up being used on a 64-bit target, but a
likely cause was a temporary ISA level override in Linux kernel code.
Of course that is a lame reason by itself to give up an optimisation,
which is why I considered it an acceptable price to pay. However using OR
or a similar operation (another candidate is `AND dest, src, src') would
indeed have avoided the problem and if it turns out now that addition no
longer has an advantage for modern hardware, then I think it only adds
another argument in favour to switching back.
> 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.
I think you actually meant `-mtune=' here, didn't you?
> Does anyone know of specific cores/range of cores that are optimized
> based on move being encoded as addu?
Ralf, I seem to remember we had a discussion on it once, long ago -- can
you recall any details?