[Bug tree-optimization/77654] New: restrict pointer attribute not preserved with -fprefetch-loop-arrays

[doug.gilmore at imgtec dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77654

            Bug ID: 77654
           Summary: restrict pointer attribute not preserved with
                    -fprefetch-loop-arrays
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doug.gilmore at imgtec dot com
  Target Milestone: ---

Compiling the test example:

void daxpy(int n, double da, double * __restrict dx, double * __restrict dy)
{
        int i;

        for (i = 0;i < n; i++) {
                dy[i] = dy[i] + da*dx[i];
        }
}

via:

mips-img-linux-gnu-gcc -fprefetch-loop-arrays daxpy.c -c -O2 -save-temps
-fsched-verbose=9 -fdump-rtl-sched2

The following code is generated for the main loop:

$L4:
        ldc1    $f2,0($5)
        pref    6,0($2)
        ldc1    $f8,-120($2)
        addiu   $2,$2,32
        ldc1    $f6,-144($2)
        addiu   $5,$5,32
        ldc1    $f4,-136($2)
        addiu   $3,$3,4
        maddf.d $f8,$f2,$f0
        ldc1    $f2,-128($2)
        sdc1    $f8,-152($2)
        ldc1    $f1,-24($5)
        maddf.d $f6,$f0,$f1
        sdc1    $f6,-144($2)
        ldc1    $f1,-16($5)
        maddf.d $f4,$f0,$f1
        sdc1    $f4,-136($2)
        ldc1    $f1,-8($5)
        maddf.d $f2,$f0,$f1
        bne     $3,$8,$L4
        sdc1    $f2,-128($2)

Due to the __restrict attributes on the pointer declarations, after
scheduling we should see that loads through $5 should move above the
stores through $2.  However, during the transformation done by the
phase that is enabled by -fprefetch-loop-arrays, the points-to
information is lost.  This prevents the loads to move above the stores
during scheduling.

The attached uses logic borrowed from IVS phase:

0002-Ensure-points-to-information-is-maintained-for-prefe.patch

After applying the patch, the points-to information is maintained,
which results in good code being generated after scheduling (which is
very important when running on in-order processors):

$L4:
        addiu   $5,$5,32
        ldc1    $f8,-120($2)
        ldc1    $f6,-112($2)
        pref    6,0($2)
        ldc1    $f4,-104($2)
        addiu   $3,$3,4
        ldc1    $f2,-96($2)
        addiu   $2,$2,32
        ldc1    $f7,-32($5)
        ldc1    $f5,-24($5)
        ldc1    $f3,-16($5)
        ldc1    $f1,-8($5)
        maddf.d $f8,$f7,$f0
        maddf.d $f6,$f0,$f5
        maddf.d $f4,$f0,$f3
        maddf.d $f2,$f0,$f1
        sdc1    $f8,-152($2)
        sdc1    $f6,-144($2)
        sdc1    $f4,-136($2)
        sdc1    $f2,-128($2)
        bnec    $3,$8,$L4

I am not sure what to do about a test case.  One possibility is to
commit some of the tracing in debugging patch:

0001-Add-more-tracing-for-missing-points-to-information.patch

and we could scan for the RE "pi. is NULL", in the dump file
created by -fdump-rtl-sched2.