From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Siarhei Volkau <lis8215@gmail.com>
Cc: linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
Paul Cercueil <paul@crapouillou.net>
Subject: Re: [PATCH] MIPS: Take in account load hazards for HI/LO restoring
Date: Mon, 29 Apr 2024 10:30:31 +0200 [thread overview]
Message-ID: <Zi9apwTq6mC47qv3@alpha.franken.de> (raw)
In-Reply-To: <Zi9X8cqTpWUR1Z6l@alpha.franken.de>
On Mon, Apr 29, 2024 at 10:18:57AM +0200, Thomas Bogendoerfer wrote:
> On Thu, Oct 12, 2023 at 07:20:27PM +0300, Siarhei Volkau wrote:
> > MIPS CPUs usually have 1 to 4 cycles load hazards, thus doing load
> > and right after move to HI/LO will usually stall the pipeline for
> > significant amount of time. Let's take it into account and separate
> > loads and mthi/lo in instruction sequence.
> >
> > The patch uses t6 and t7 registers as temporaries in addition to t8.
> >
> > The patch tries to deal with SmartMIPS, but I know little about and
> > haven't tested it.
> >
> > Signed-off-by: Siarhei Volkau <lis8215@gmail.com>
> > ---
> > arch/mips/include/asm/stackframe.h | 22 ++++++++++++----------
> > 1 file changed, 12 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/mips/include/asm/stackframe.h b/arch/mips/include/asm/stackframe.h
> > index a8705aef47e1..3821d91b00fd 100644
> > --- a/arch/mips/include/asm/stackframe.h
> > +++ b/arch/mips/include/asm/stackframe.h
> > @@ -308,17 +308,11 @@
> > jal octeon_mult_restore
> > #endif
> > #ifdef CONFIG_CPU_HAS_SMARTMIPS
> > - LONG_L $24, PT_ACX(sp)
> > - mtlhx $24
> > - LONG_L $24, PT_HI(sp)
> > - mtlhx $24
> > - LONG_L $24, PT_LO(sp)
> > - mtlhx $24
> > -#elif !defined(CONFIG_CPU_MIPSR6)
> > + LONG_L $14, PT_ACX(sp)
> > +#endif
> > +#if defined(CONFIG_CPU_HAS_SMARTMIPS) || !defined(CONFIG_CPU_MIPSR6)
>
> isn't that just #ifndef CONFIG_CPU_MIPSR6 ?
and if yes, I prefer to have the same structure as for the move to
registers later like
#ifdef CONFIG_CPU_HAS_SMARTMIPS
.. do the SMARTMIPS things
elif !defined(CONFIG_CPU_MIPSR6)
.. do normal hi/lo
#endif
that way it's more clear whats happening depending on selected
options.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
prev parent reply other threads:[~2024-04-29 8:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 16:20 [PATCH] MIPS: Take in account load hazards for HI/LO restoring Siarhei Volkau
2024-04-29 6:42 ` Siarhei Volkau
2024-04-29 8:18 ` Thomas Bogendoerfer
2024-04-29 8:30 ` Thomas Bogendoerfer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zi9apwTq6mC47qv3@alpha.franken.de \
--to=tsbogend@alpha.franken.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=lis8215@gmail.com \
--cc=paul@crapouillou.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.