[PATCH] checked in prefetch support for mips

[cgd@broadcom.com]

At 19 Jun 2002 17:00:18 -0700, Eric Christopher wrote:
> > * Err, uh, even with this "non-simple" algorithm, I think you're
> >   getting the hints wrong.  8-)
> > 
> 
> In what way?
>
> >   locality seems to go from 0 (not much locality) to 3 (high degree of
> >   locality), right?
> > 
> >   So, in terms of the pref codes:
> > 
> > 	0/1 are "normal"
> > 	4/5 are "streamed" (low locality)
> > 	6/7 are "retainted" (high locality)
> > 
> 
> Yep.

I thought it was obvious from a quick read and the info that I
provided and the diff, so I didn't explain further.  8-)

anyway, your locality value to pref value mapping was going:

    locality arg	desired locality	pref hint
    0			little			0/1		(normal)
    1			some			4/5		(streamed)
    2			some more		4/5		(streamed)
    3			lots			6/7		(low)


> > * you never use use prefx; is that just because there's not enough
> >   flexibility in the prefetch RTL node to allow it, or ???
> > 
> 
> Correct. I don't believe indexed addressing works for this.

unfortunate.  8-S


> > * lastly, it might be nice to have MD builtins that let code generate
> >   pref/prefx w/ arbitrary hints...  that way people could code the
> >   'exact' prefetches that they want, and could also generate nudge or
> >   prepare_for_store in a scheduler-friendly way...
> > 
> 
> You should read the prefetch examples. They are most enlightening. :)

Eh?  I looked at the documentation (including the examples), and
nothing jumped out at me that touched this point.

(How, for instance, would i generate a MIPS 'pref 30, ...' instruction
in a scheduler-friendly way?)


> > -/* ISA has data prefetch instruction.  */
> > -#define ISA_HAS_PREFETCH	((ISA_MIPS4				\
> > -				  || ISA_MIPS32				\
> > +/* ISA has data prefetch instruction.  (MIPS IV and MIPS V have prefetch
> > +   instructions, but they are not architecturally standard.  Add checks
> > +   for specific CPUs to this list and to mips_emit_prefetch() as needed.  */
> > +#define ISA_HAS_PREFETCH	((ISA_MIPS32				\
> >  				  || ISA_MIPS64)	       		\
> 
> The comment part is ok, I don't like removing mips4 because it _did_
> have a prefetch instruction. I'll assume, that since the docs I have
> mention mips4 and don't mention any functional changes that the current
> support should be at least sufficient.

I just looked at r10k docs (t5.ver.2.0.book.pdf) and rm7k docs, and
both -- pre-mips32/mips64, and IIRC "mips IV +" -- chips do alien
things with prefetch instructions.

Specifically:

	r10k:
		0/1 -> prefetch into LRU
		4/5 -> prefetch into way 0 of the cache
		6/7 -> prefetch into way 1 of the cache

	rm7k it looks like all of the ones covered here effectively
	turn into "load."

Note that even the mips64 spec, which defines well the hint encodings
and their meanings, however, says:

	"Any action, including doing nothing, is permitted as long as
	it does not change architecturally visible state or alter the
	meaning of the program."

I'm not quite sure how that should be interpreted in light of the fact
that the pref hint table assigns "well-defined" meanings for each
code.  8-)

Anyway, I do think it's clear that, if were one to go by the meanings
given in the MIPS64 spec (uh, page 243 8-), the pref codes you're
currently using for given locality meanings are incorrect.


chris