This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patch applied to sh.md: add prefetch pattern
- From: amylaar at spamcop dot net (Joern Rennecke)
- To: dj at redhat dot com (DJ Delorie)
- Cc: gcc-patches at gcc dot gnu dot org, joern dot rennecke at superh dot com
- Date: Fri, 21 May 2004 22:15:08 +0100 (BST)
- Subject: Re: patch applied to sh.md: add prefetch pattern
> > > Ok, thanks. Question: does the SH *chip* have faulting and
> > > nonfaulting opcodes, or just one type?
> >
> > It has only nonfaulting prefetches.
> > (Although it has different types: data and instruction prefetches,
> > SHmedia and SHcompact opcodes.)
> > But if you like your code to fault, you can load into any free register...
>
> The opcode that's faulting is:
>
> 1410: 801003f0 ld.b r1,0,r63
>
> This is what your prefetch pattern is generating. This looks like a
> "load into any free register" to me. Is there something I don't know
> that makes this a non-faulting load?
r63 is special. When you read it, it is always zero. And when it appears
as the destination of a load, this is not an ordinary load, doesn't
block (i.e. it is a prefetch), and it doesn't fault either.
> > > I'm thinking, if the chip
> > > doesn't fault, then having the simulator fault might be considered a
> > > debugging aid rather than a bug.
> >
> > Sorry, I can't follow you there. How is that helpful?
>
> For the same reasons SIGSEGV is useful on Linux. It (sometimes) tells
> you where your program is accessing memory it shouldn't.
A common way to use prefetch is to load an address that is somehat ahead of
the current access while you are reading an array. So when you get close
to the end, it will become an out-of-bounds array access. This memory
might not even be mapped, so you don't want the prefetch to fault.