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: Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Sat, 6 Feb 2016 04:05:40 +0000 (UTC)
- Subject: Re: Instruction scheduling for the R5900's 2 integer pipelines
- Authentication-results: sourceware.org; auth=none
- References: <56B4C60B dot 6000809 at redhat dot com>
- Reply-to: Woon yung Liu <ysai187 at yahoo dot com>
Sorry, but I just realized what I had to go with the 3rd option. Other than the difficulties that I described earlier, it's mainly because the divmod split insn will output to a lo register.
When I allocate a hi+lo temporary register, that lo register must be a subset of it.
On Friday, February 5, 2016 11:56 PM, Jeff Law <law@redhat.com> wrote:
On 02/05/2016 05:35 AM, Woon yung Liu wrote:
> 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).
Conditionalize the paths based on can_create_pseudo_p.
Essentially up until the register reloading pass you can freely create
new pseudos. Once register reloading has begun, you can't create new
pseudos. Though you might also look into why something would be calling
the divmod expander after reload started -- that seems rather odd.
Jeff