This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] Workaround errata for the PMC-Sierra RM7000 cpu.



> -----Original Message-----
> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
> Sent: Thursday, October 10, 2013 1:21 PM
> To: Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Workaround errata for the PMC-Sierra RM7000 cpu.
> 
> "Moore, Catherine" <Catherine_Moore@mentor.com> writes:
> >> -----Original Message-----
> >> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
> >> 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.
> 
> Thanks.
> 
> >> 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
> implementation.
> 
> 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
> options:
> 
> (1) Turn INSN_LOAD_MEMORY_DELAY into INSN_LOAD_GPR and
>     INSN_COPRO_MEMORY_DELAY into INSN_LOAD_COPRO.  Add the flags to
> all
>     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.
> 
> Thanks,
> Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]