Re: middle-end/7561: Prefetch merging code in gcc-3.1/gcc/loop.c incorect

Re: middle-end/7561: Prefetch merging code in gcc-3.1/gcc/loop.c incorect

[bangerth]

Synopsis: Prefetch merging code in gcc-3.1/gcc/loop.c incorect

State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Wed Dec  4 08:07:23 2002
State-Changed-Why:
    Janis, you had a patch for this some time back. Can you say
    what the status of this is?

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7561

Re: middle-end/7561: Prefetch merging code in gcc-3.1/gcc/loop.c incorect

[Wolfgang Bangerth]

The following reply was made to PR middle-end/7561; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Janis Johnson <janis187@us.ibm.com>
Cc: gcc-bugs@gcc.gnu.org, <redmond@ecf.utoronto.ca>, <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/7561: Prefetch merging code in gcc-3.1/gcc/loop.c
 incorect
Date: Fri, 6 Dec 2002 13:56:18 -0600 (CST)

 > It was put on hold while IBM figured out new priorities for me.  I plan
 > to get back to it soon, this time testing performance changes on
 > powerpc64-linux as well as ia64-linux.  I'll separate out fixes from the
 > other changes in case they can go in as bug fixes for 3.3.x and perhaps
 > 3.2.x.
 
 OK, thanks for your feedback. I put the PR back into "analyzed" mode.
 
 It would be great if you could extract correctness patches from your 
 changes and apply them. (I guess, prefetching can probably never be 
 "wrong", it can only be useless, but you know what I mean.)
 
 Thanks
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

Re: middle-end/7561: Prefetch merging code in gcc-3.1/gcc/loop.c incorect

[bangerth]

Synopsis: Prefetch merging code in gcc-3.1/gcc/loop.c incorect

State-Changed-From-To: feedback->analyzed
State-Changed-By: bangerth
State-Changed-When: Fri Dec  6 11:54:29 2002
State-Changed-Why:
    Janis' patches were put on hold, so this is not fixed.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7561

Re: middle-end/7561: Prefetch merging code in gcc-3.1/gcc/loop.c incorect

[Janis Johnson]

The following reply was made to PR middle-end/7561; it has been noted by GNATS.

From: Janis Johnson <janis187@us.ibm.com>
To: bangerth@dealii.org, anis187@us.ibm.com, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, redmond@ecf.utoronto.ca,
   gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: middle-end/7561: Prefetch merging code in gcc-3.1/gcc/loop.c incorect
Date: Fri, 6 Dec 2002 11:21:16 -0800

 On Wed, Dec 04, 2002 at 04:07:23PM -0000, bangerth@dealii.org wrote:
 > Synopsis: Prefetch merging code in gcc-3.1/gcc/loop.c incorect
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: bangerth
 > State-Changed-When: Wed Dec  4 08:07:23 2002
 > State-Changed-Why:
 >     Janis, you had a patch for this some time back. Can you say
 >     what the status of this is?
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7561
 
 It was put on hold while IBM figured out new priorities for me.  I plan
 to get back to it soon, this time testing performance changes on
 powerpc64-linux as well as ia64-linux.  I'll separate out fixes from the
 other changes in case they can go in as bug fixes for 3.3.x and perhaps
 3.2.x.
 
 Janis

Re: middle-end/7561: Prefetch merging code in gcc-3.1/gcc/loop.c incorect

[Janis Johnson]

The following reply was made to PR middle-end/7561; it has been noted by GNATS.

From: Janis Johnson <janis187@us.ibm.com>
To: redmond@ecf.utoronto.ca
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: middle-end/7561: Prefetch merging code in gcc-3.1/gcc/loop.c incorect
Date: Wed, 14 Aug 2002 09:46:02 -0700

 On Fri, Aug 09, 2002 at 05:58:32PM -0000, redmond@ecf.utoronto.ca wrote:
 > 
 > >Number:         7561
 > >Category:       middle-end
 > >Synopsis:       Prefetch merging code in gcc-3.1/gcc/loop.c incorect
 
 Wow, someone is looking at the prefetch optimization code!  I'm still
 catching up on mailing lists after a two-week vacation and didn't see
 your bug report until just now.
 
 In June I posted some changes to the way the prefetches are merged, and
 changed things in general to handle "sparse" prefetches, for which we
 prefetch only the cache lines containing data that will be used rather
 than every cache line within the section of the array being used.  I had
 asked Jan Hubicka to take a look at it, but that was when he was in the
 middle of lots of other things and I never heard anything from him.
 
 If you're interested in this optimization, please take a look at
 http://gcc.gnu.org/ml/gcc-patches/2002-06/msg00660.html.
 I can update the patch to apply to the current CVS tree, which I've been
 meaning to do anyway; I've been distracted by other things lately.  I've
 also got some other tweaks locally that help some of the SPEC CPU2000
 floating point tests.  The new code as written can't be used because
 it's much slower, but it's meant to demonstrate changes to how
 prefetches are used; once that looks OK it can be changed to do the
 same work more quickly.
 
 Janis Johnson
 IBM Linux Technology Center
 

middle-end/7561: Prefetch merging code in gcc-3.1/gcc/loop.c incorect

[redmond]

>Number:         7561
>Category:       middle-end
>Synopsis:       Prefetch merging code in gcc-3.1/gcc/loop.c incorect
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 09 11:06:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Rob Redmond, University of Toronto
>Release:        3.1
>Organization:
>Environment:
Intel Pentium3
Redhat Linux 7.2
>Description:
See  emit_prefetch_instruction() in gcc-3.1/gcc/loop.c

After examining a general induction variable (GIV) to determine if it is eligible for prefetching, emit_prefetch_instruction() compares the newly identified "prefetchable" GIV with all the previously identified "prefetchable" GIVs (which share a common basic induction variable (BIV)) to determine if they can be merged.

In the first case were two GIV's can be merged, the address of the new one is greater than that of the existing one, causing the existing prefetch's info to be replaced by info related to the new prefetch.

                if (index >= info[i].index && index - info[i].index < 4096)
                  {
                    info[i].write |= d.mem_write;
                    info[i].bytes_accesed += size;
                    info[i].index = index;
                    info[i].giv = iv;
                    info[i].class = bl;
                    info[num_prefetches].base_address = address;
                    add = 0;
                    break;
                  }

The code above (as it appears in loop.c) does not replace the base address of the existing prefetchable GIV.  Thus, by keeping the address of the lower addressed GIV, the higher addressed GIV will never be prefetched.  In fact, the comments before this code say to, "Just do the later and the earlier will get prefetched from previous iteration.", but this is not being done.

  In addition, since num_prefetches is not incremented when the new prefetch is merged, the assignment of the new prefetch's address to "info[num_prefetches].base_address" is replaced when the next non-mergeable prefetch instruction is identified.
>How-To-Repeat:
This problem is located in the GCC source code.
>Fix:
Change the array index in the line mentioned above from,
"info[num_prefetches].base_address = address" (line #3925) to
"info[i].base_address = address"
>Release-Note:
>Audit-Trail:
>Unformatted: