This is the mail archive of the
mailing list for the GCC project.
RE: [PATCH] Workaround errata for the PMC-Sierra RM7000 cpu.
- From: "Moore, Catherine" <Catherine_Moore at mentor dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 31 Oct 2013 17:30:45 +0000
- Subject: RE: [PATCH] Workaround errata for the PMC-Sierra RM7000 cpu.
- Authentication-results: sourceware.org; auth=none
- References: <FD3DCEAC5B03E9408544A1E416F11242F9033EC0 at NA-MBX-04 dot mgc dot mentorg dot com> <87wqllpmuw dot fsf at talisman dot default> <FD3DCEAC5B03E9408544A1E416F11242F9034103 at NA-MBX-04 dot mgc dot mentorg dot com> <874n8pqby2 dot fsf at talisman dot default>
> -----Original Message-----
> From: Richard Sandiford [mailto:firstname.lastname@example.org]
> Sent: Thursday, October 10, 2013 1:21 PM
> To: Moore, Catherine
> Cc: email@example.com
> Subject: Re: [PATCH] Workaround errata for the PMC-Sierra RM7000 cpu.
> "Moore, Catherine" <Catherine_Moore@mentor.com> writes:
> >> -----Original Message-----
> >> From: Richard Sandiford [mailto:firstname.lastname@example.org]
> >> Subject: Re: [PATCH] Workaround errata for the PMC-Sierra RM7000 cpu.
> >> "Moore, Catherine" <Catherine_Moore@mentor.com> writes:
> >> > Hi Richard,
> >> >
> >> > This patch implements a workaround for errors on the PMC-Sierra
> >> > RM7000 cpu while executing the dmult or dmultu instruction. The
> >> > workaround is to insert three nops after the dmult/dmultu.
> >> Do you have any more details? E.g. does "dmult $4,$5;addiu $6,$7,1"
> >> cause problems? The VR41xx series had errata like these, but it was
> >> always between the multiplication and other references to HI/LO.
> > I've attached documentation describing the errata. The problem occurs
> > with dmult/dmultu followed by a load.
> >> Normally we've handled this by getting the assembler to insert the
> >> nops and compiling in .set reorder mode. That copes with inline asms too.
> >> I'm not opposed to doing it differently if there's a specific reason though.
> > No specific reason. Let me know if we need to change the
> The assembler's probably best, all other things being equal.
> Ideally opcodes/mips*.c would have a flag to mark load instructions, but all
> we have at the moment are flags to mark load delays, which means that LD
> and some other load instructions don't have them. So I can think of three
> (1) Turn INSN_LOAD_MEMORY_DELAY into INSN_LOAD_GPR and
> INSN_COPRO_MEMORY_DELAY into INSN_LOAD_COPRO. Add the flags to
> loads in the opcode table that don't currently have one.
> This would be the best approach, but I can understand why it might
> seem like too much effort.
I've decided to go with this approach and will post the patches to the binutils mailing list. I'll follow up here with the recognition of the mfix-pmc option by the driver program.
> (2) Stick with inserting three nops regardless. This could be done by
> making insns_between return 3 for insn1 being DMULT(U), regardless
> of insn2.
> (3) A slightly hacky approach would be to do (2), but check for memory
> instructions using:
> (insn2 == NULL || strchr (insn2->insn_mo->args, '('))
> That would conservatively match prefetches and stores too, but would
> at least avoid the nops in some cases. It's probably not worth the
> risk or hackiness though.