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

["Maciej W. Rozycki" <macro at linux-mips 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:
> 
> 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>

 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?

  Maciej