Bug 49957 - Fails to SLP in 410.bwaves
Summary: Fails to SLP in 410.bwaves
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: 4.7.0
Assignee: Richard Biener
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2011-08-03 09:23 UTC by Richard Biener
Modified: 2018-03-24 18:56 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-08-03 11:10:57


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2011-08-03 09:23:22 UTC
While the loop

      subroutine shell(nx,ny,nz)
      implicit none
      integer i,j,k,l,nx,ny,nz
      real*8 q(21,nx,ny,nz),dq(21,nx,ny,nz)
      do k=1,nz
         do j=1,ny
            do i=1,nx
               do l=1,21
                  q(l,i,j,k)=q(l,i,j,k)+dq(l,i,j,k)
               enddo
            enddo
         enddo
      enddo
      return
      end

is vectorized using loop vectorization the following variant is not
(as appearing in 410.bwaves):

      subroutine shell(nx,ny,nz)
      implicit none
      integer i,j,k,l,nx,ny,nz
      real*8 q(5,nx,ny,nz),dq(5,nx,ny,nz)
      do k=1,nz
         do j=1,ny
            do i=1,nx
               do l=1,5
                  q(l,i,j,k)=q(l,i,j,k)+dq(l,i,j,k)
               enddo
            enddo
         enddo
      enddo
      return
      end

first of all dependence checking on the innermost unrolled loop fails:

(compute_affine_dependence
  (stmt_a =
D.1639_140 = *q_54[D.1638_139];
)
  (stmt_b =
*q_54[D.1638_157] = D.1647_160;
)
(subscript_dependence_tester
(analyze_overlapping_iterations
  (chrec_a = {((pretmp.33_209 + 6) + pretmp.33_213) + offset.5_32, +, 5}_3)
  (chrec_b = {((pretmp.33_209 + 7) + pretmp.33_213) + offset.5_32, +, 5}_3)
(analyze_siv_subscript
siv test failed: unimplemented.
)

as pretmp.33 is signed and we thus do not associate the constant offset
(well, I think this might be the problem at least).

That shouldn't prevent vectorization (and it doesn't).  But then
(probably due to the same reason) we get

t.f:7: note: === vect_analyze_data_ref_accesses ===
t.f:7: note: not consecutive access D.1639_140 = *q_54[D.1638_139];
t.f:7: note: not vectorized: complicated access pattern.
t.f:7: note: bad data access.
t.f:1: note: vectorized 0 loops in function.

so in the end it _does_ seem to be the underlying issue.

I will see what can be done here.
Comment 1 Richard Biener 2011-08-03 11:10:57 UTC
When associating the index expression "properly" it works.
Comment 2 Tobias Burnus 2011-08-03 14:05:13 UTC
Cf. RFC Fortran patch at http://gcc.gnu.org/ml/fortran/2011-08/msg00012.html to change the index order into the canonical form.
Comment 3 Richard Biener 2011-08-03 14:41:49 UTC
The patch now makes us vectorize

shell_lam.f:303: note: LOOP VECTORIZED.
shell_lam.f:262: note: LOOP VECTORIZED.
shell_lam.f:205: note: LOOP VECTORIZED.

compared to just

shell_lam.f:262: note: LOOP VECTORIZED.

without.
Comment 4 Richard Biener 2011-08-03 15:17:42 UTC
Mine.
Comment 5 Richard Biener 2011-08-04 12:22:47 UTC
Author: rguenth
Date: Thu Aug  4 12:22:42 2011
New Revision: 177368

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177368
Log:
2011-08-04  Richard Guenther  <rguenther@suse.de>

	PR fortran/49957
	* trans-array.c (add_to_offset): New function.
	(gfc_conv_array_ref): Build the array index expression in optimally
	associated order.
	(gfc_walk_variable_expr): Adjust for the backward walk.

	* gfortran.dg/vect/O3-pr49957.f: New testcase.

Added:
    trunk/gcc/testsuite/gfortran.dg/vect/O3-pr49957.f
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog
Comment 6 Richard Biener 2011-08-04 12:23:10 UTC
Fixed.