| To: | Atsushi Nemoto <anemo@mba.ocn.ne.jp> |
|---|---|
| Subject: | Re: [PATCH] fast path for rdhwr emulation for TLS |
| From: | Daniel Jacobowitz <dan@debian.org> |
| Date: | Mon, 10 Jul 2006 22:53:42 -0400 |
| Cc: | macro@linux-mips.org, linux-mips@linux-mips.org, ralf@linux-mips.org |
| In-reply-to: | <20060710.235553.48797818.anemo@mba.ocn.ne.jp> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <Pine.LNX.4.64N.0607071607520.25285@blysk.ds.pg.gda.pl> <20060708.011245.82794581.anemo@mba.ocn.ne.jp> <Pine.LNX.4.64N.0607071715360.25285@blysk.ds.pg.gda.pl> <20060710.235553.48797818.anemo@mba.ocn.ne.jp> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | Mutt/1.5.11+cvs20060403 |
On Mon, Jul 10, 2006 at 11:55:53PM +0900, Atsushi Nemoto wrote: > On Fri, 7 Jul 2006 17:58:44 +0100 (BST), "Maciej W. Rozycki" > <macro@linux-mips.org> wrote: > > mfc0 k0, CP0_CAUSE > > MFC0 k1, CP0_EPC > > bltz k0, handle_ri_slow /* if delay slot */ > > lui k0, 0x7c03 > > 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. 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. -- Daniel Jacobowitz CodeSourcery |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | SHT_REL bad size, Roman Mashak |
|---|---|
| Next by Date: | Re: [PATCH] fast path for rdhwr emulation for TLS, Atsushi Nemoto |
| Previous by Thread: | Re: [PATCH] fast path for rdhwr emulation for TLS, Atsushi Nemoto |
| Next by Thread: | Re: [PATCH] fast path for rdhwr emulation for TLS, Atsushi Nemoto |
| Indexes: | [Date] [Thread] [Top] [All Lists] |