| To: | Atsushi Nemoto <anemo@mba.ocn.ne.jp>, ralf@linux-mips.org |
|---|---|
| Subject: | Re: [PATCH] fast path for rdhwr emulation for TLS |
| From: | Nigel Stephens <nigel@mips.com> |
| Date: | Fri, 08 Sep 2006 18:39:08 +0100 |
| Cc: | dan@debian.org, macro@linux-mips.org, linux-mips@linux-mips.org |
| In-reply-to: | <20060711.122014.52129937.nemoto@toshiba-tops.co.jp> |
| Organization: | MIPS Technologies |
| 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> <20060711.122014.52129937.nemoto@toshiba-tops.co.jp> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | Thunderbird 1.5.0.2 (X11/20060501) |
moto wrote: > >> 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 > In spite of the GCC issue, is this patch now at the point where it could be applied, or at least queued? Nigel |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: 64-bit 2.6.17.7 SMP hangs in __cpu_up()., Ralf Baechle |
|---|---|
| Next by Date: | Re: [PATCH] fast path for rdhwr emulation for TLS, Atsushi Nemoto |
| Previous by Thread: | 64-bit 2.6.17.7 SMP hangs in __cpu_up()., Kaz Kylheku |
| Next by Thread: | Re: [PATCH] fast path for rdhwr emulation for TLS, Atsushi Nemoto |
| Indexes: | [Date] [Thread] [Top] [All Lists] |