linux-mips
[Top] [All Lists]

Re: [PATCH] fast path for rdhwr emulation for TLS

To: nigel@mips.com
Subject: Re: [PATCH] fast path for rdhwr emulation for TLS
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Sat, 09 Sep 2006 22:56:41 +0900 (JST)
Cc: ralf@linux-mips.org, dan@debian.org, macro@linux-mips.org, linux-mips@linux-mips.org
In-reply-to: <4501AABC.1050009@mips.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20060711025342.GA6898@nevyn.them.org> <20060711.122014.52129937.nemoto@toshiba-tops.co.jp> <4501AABC.1050009@mips.com>
Sender: linux-mips-bounce@linux-mips.org
On Fri, 08 Sep 2006 18:39:08 +0100, Nigel Stephens <nigel@mips.com> wrote:
> > I asked on GCC bugzilla a few days ago but can not got feedback yet.
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126
> >   
> 
> In spite of the GCC issue, is this patch now at the point where it could
> be applied, or at least queued?

GCC 4.2 does not put RDHWR in delay slot now.  Also, there is a
"hackish fix" to prevent gcc move a RDHWR outside of a conditional
(from Richard Sandiford).

For kernel side, my patch can be still applied to current git tree as
is.

But I'm still looking for better solution (silver bullet?) for
cpu_has_vtag_icache case.

How about something like this (and do not touch tlbex.c)?

        LEAF(handle_ri_rdhwr_vivt)
        .set    push
        .set    noat
        .set    noreorder
        /* check if TLB contains a entry for EPC */
        MFC0    K1, CP0_ENTRYHI
        andi    k1, ASID_MASK
        MFC0    k0, CP0_EPC
        andi    k0, PAGE_MASK << 1
        or      k1, k0
        MTC0    k1, CP0_ENTRYHI
        tlbp
        mfc0    k1, CP0_INDEX
        bltz    k1, handle_ri   /* slow path */
         nop
        /* fall thru */
        LEAF(handle_ri_rdhwr)

I'm wondering if this could work on CONFIG_MIPS_MT_SMTC case...

---
Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>