linux-mips
[Top] [All Lists]

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

To: dan@debian.org
Subject: Re: [PATCH] fast path for rdhwr emulation for TLS
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Tue, 11 Jul 2006 12:20:14 +0900 (JST)
Cc: macro@linux-mips.org, linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <20060711025342.GA6898@nevyn.them.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.LNX.4.64N.0607071715360.25285@blysk.ds.pg.gda.pl> <20060710.235553.48797818.anemo@mba.ocn.ne.jp> <20060711025342.GA6898@nevyn.them.org>
Sender: linux-mips-bounce@linux-mips.org
On Mon, 10 Jul 2006 22:53:42 -0400, Daniel Jacobowitz <dan@debian.org> wrote:
> > I noticed that checking for CP0_CAUSE.BD is unneeded, since we are
> > checking the instruction code anyway and "rdhwr" does not have a delay
> > slot.  I removed the checking on the "take 2" patch I just sent.
> 
> Isn't BD "this instruction is in a delay slot", not "this instruction
> has a delay slot"?  It affects where we go when we return.
 
Well, the BD means "the exception occurred on a delay slot of this
(which EPC points) instruction".  If rdhwr was in a delay slot, EPC
points the preceding jump/branch instruction.  This fast path is
reading a instruction at the EPC (regardless BD), so it must not be
"rdhwr" and fall back to slow path.

> BTW, if the fast emulation can't handle rdhwr in a delay slot, please
> report a bug on GCC asking it not to put rdhwr in delay slots by
> default.  It's probably worthwhile.

If rdhwr was on a delay slot, the slow emulation will be more slower.
So I think rdhwr should not be put on delay slot anyway regardless
fast emulation.

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

---
Atsushi Nemoto

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