This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Improve prefetch heuristics
- From: Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>
- To: "Fang, Changpeng" <Changpeng dot Fang at amd dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "rguenther at suse dot de" <rguenther at suse dot de>, "sebpop at gmail dot com" <sebpop at gmail dot com>
- Date: Mon, 3 May 2010 18:40:48 +0200
- Subject: Re: [patch] Improve prefetch heuristics
- References: <20100430010543.GA30055@kam.mff.cuni.cz> <1C13CD442679CE45A2E80AE9251D7EF921803A28@SAUSEXMBP01.amd.com>
Hi,
> You are right. It looks prune_ref_by_self_reuse has already adjusted the prefetch distance
> through prefetch_mod. The reason I observed the short prefetch distance may due to the induction variable
> "ap" in the issue_prefetch_ref logic:
>
> for (ap = 0; ap < n_prefetches; ap++) /* <---------------------------- */
> {
> /* Determine the address to prefetch. */
> delta = (ahead + ap * ref->prefetch_mod) * ref->group->step;
>
> When ap equals 0, the prune_self_reuse adjustment is essentially ignored. Applying the following patch
> can resolve the short prefetch distance problem:
>
> - for (ap = 0; ap < n_prefetches; ap++)
> + for (ap = 1; ap <= n_prefetches; ap++)
> {
> /* Determine the address to prefetch. */
> delta = (ahead + ap * ref->prefetch_mod) * ref->group->step;
I think there is some missunderstanding. The statement "When ap equals 0, the prune_self_reuse adjustment
is essentially ignored." does not make sense to me. Also, the change you propose only increases the prefetch
distance by a constant offset.
Zdenek