This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]