This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Instruction scheduling for the R5900's 2 integer pipelines
- From: Woon yung Liu <ysai187 at yahoo dot com>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 5 Feb 2016 12:35:10 +0000 (UTC)
- Subject: Re: Instruction scheduling for the R5900's 2 integer pipelines
- Authentication-results: sourceware.org; auth=none
- References: <569E6367 dot 4020205 at redhat dot com> <684612341 dot 6391756 dot 1453284759877 dot JavaMail dot yahoo at mail dot yahoo dot com>
- Reply-to: Woon yung Liu <ysai187 at yahoo dot com>
Hi all,
Assuming that the answer to my earlier question is that I am doing things correctly, I need help with register allocation because GCC is now spewing out unrecognized insn errors when I compile for a different target (32-bit r3000).
It currently works fine when I compile for the r5900, as a 64-bit target.
The current (GCC 5.3.0) MIPS divmod<mode>4 pattern emits an expand that allocates a temporary register (hi+lo) and emits other instructions, depending if whether the target is a 32-bit or 64-bit MIPS target.
However, it uses gen_rtx_REG to allocate the hi+lo register, while I need it to freely allocate either one of the two (hi+lo or hi1+lo1) that the r5900 has. With the current design, it will only use hi+lo in all division ops (as with other MIPS).
I think that that I should be using gen_reg_rtx to allocate a pseudo register, but that isn't possible in that expand (will result in an assertion failure, due to can_create_pseudo_p).
Stuff I tried:
1. Change gen_rtx_REG to gen_reg_rtx. This results in an assertion failure as mentioned above.
2. Split the expand into two (32-bit and 64-bit), and change the new expands to require a scratch register (TI for 64-bit, DI for 32-bit). GCC will segment fault, so I guess that this isn't allowed?
3. Split the expand into two (32-bit and 64-bit), and allocate a suitable hard register with gen_rtx_REG in the insn (i.e. udivmod<mode>4) for the expand to use as a to-be-clobbered operand.
I am currently using the third design, which apparently fully works for the r5900 as a 64-bit target... but results in an unrecognized insn error when I target the 32-bit r3000. The code for the 32-bit expand looks okay, so the only thing that I can think of is that I am still doing things wrong here (i.e. perhaps the expand must have the same operands as the insn).
Does anyone have a better/more correct solution? How does one allocate a temporary pseudo register, while in an expand?
Thanks in advance.
Regards,
-W Y