This is the mail archive of the
mailing list for the GCC project.
Re: patch applied to sh.md: add prefetch pattern
- From: <tm_gccmail at kloo dot net>
- To: DJ Delorie <dj at redhat dot com>
- Cc: joern dot rennecke at superh dot com, gcc-patches at gcc dot gnu dot org
- Date: Fri, 21 May 2004 11:46:57 -0700 (PDT)
- Subject: Re: patch applied to sh.md: add prefetch pattern
On Fri, 21 May 2004, DJ Delorie wrote:
> > > One of my internal builds is failing prefetch tests because this "new"
> > > pattern faults on an invalid address. The GCC docs say that this
> > > pattern must not fault on invalid addresses. Is the pattern wrong, or
> > > is the simulator wrong?
> > The simulator is wrong.
> Ok, thanks. Question: does the SH *chip* have faulting and
> nonfaulting opcodes, or just one type? I'm thinking, if the chip
> doesn't fault, then having the simulator fault might be considered a
> debugging aid rather than a bug.
Whoa, wait, hold on.
Has someone actually tested the prefetch implementation and measured the
When I was at Sega, we did a lot of tests on the SH7750 PREF
instruction. Basically, we came to the conclusion it was nearly useless.
This is from memory, but anyway:
On a well-designed processor, you can access the cache (e.g. perform loads
and stores as long as it's a cache hit) while the cache is prefetching.
On the SH7750, we empirically determined you cannot access the cache while
the cache is prefetching. Not at all. So basically, you need to try to
perform register-register ops for about 28 (4-1-1-1 burst, * 2 for half
speed bus, * 2 for dual issue) instructions after the PREF in order to
In fact, if you run the caches in split-cache mode, you can't even access
the RAM half of the cache while the other half of the cache is
I haven't checked, but I believe this is true for all of the SH4 series,
e.g. the 7751, the 7760, and the 7761.
So basically, PREF is almost a zero-win on the SH4 series.