This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Workaround errata for the PMC-Sierra RM7000 cpu.
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Moore\, Catherine" <Catherine_Moore at mentor dot com>
- Cc: "gcc-patches\ at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 10 Oct 2013 18:21:09 +0100
- 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>
"Moore, Catherine" <Catherine_Moore@mentor.com> writes:
>> -----Original Message-----
>> From: Richard Sandiford [mailto:email@example.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.
>> 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.
(2) Stick with inserting three nops regardless. This could be done by
making insns_between return 3 for insn1 being DMULT(U), regardless
(3) A slightly hacky approach would be to do (2), but check for memory
(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.