This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [RFC,MIPS] Changing the mapping for the 'move' instruction
- From: pinskia at gmail dot com
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: 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>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 2 Mar 2015 02:05:13 -0800
- 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 Mar 2, 2015, at 2:00 AM, Matthew Fortune <Matthew.Fortune@imgtec.com> wrote:
>
> 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?
For all three octeons, both addu and or have the same latency and can be issued in either pipes. So this change will not effect any of the octeons.
Thanks,
Andrew
>
> Thanks,
> Matthew