RFC: Prefetch instruction support

[Jan Hubicka]

> On Tue, 11 Apr 2000, Jan Hubicka wrote:
> >Resulting code is:
> >
> >main:
> >	xorl	%edx, %edx
> >	movl	$1000, %ecx
> >	.p2align 4
> >.L6:
> >	prefetch	b+128(%edx)
> >	movl	b(%edx), %eax
> >	addl	%eax, %eax
> >	prefetchw	a+128(%edx)
> >	movl	%eax, a(%edx)
> >	addl	$4, %edx
> >	decl	%ecx
> >	jne	.L6
> >	ret
> 
> Why are you using +128 here? You miss to prefetch the first 128 bytes

I need to prefetch few cache lines forward, since the prefetch latency is large,
but I can execute up to 6 at time (for Athlon CPU). By prefetching 2 cache
lines forward I use advantage of 4 simultatenous prefetches.
(it ought to be actually 3 cache lines, but I hardcoded constant of 5, instead
of 6).

> of a and b. This not that critical but may limit the benefit on small
> loops.

This ought to be handled by 4 prefetch instructions before loop. I don't emit
them at moment, but I want to in very near future.

> The code will read 128bytes beyond the end of both a and b, which may
> trigger exceptions or just pulls in a swapped page.

At least for Athlon I believe prefetch instructions are non-trapping (at least
I've tried to prefetch NULL page and it did worked), basically
to allow such optimization.
So this is basically issue for loops with low (but unknown) iteration count, where
I prefetch some unnecesary data after the loop.  This shows as 5% slowdown in bzip2,
on random data that does string compare, that usually ends very soon.

Honza

> 
> Hartmut