[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #13 from tkoenig at gcc dot gnu dot org 2009-09-13 12:54 --- Actually closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #12 from burnus at gcc dot gnu dot org 2009-07-03 11:33 --- > Michael Matz fixed that for allocatable arrays, but the patch needs to be > extended to nonallocatable arrays, cf. > http://gcc.gnu.org/ml/fortran/2009-07/msg4.html Actually, there it already works. Left is only to do the same optimization for CONTIGUOUS arrays, but this F2008 feature does not exist, yet. Thus I am closing this PR. For the contiguous attribute, see PR 40632. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #11 from matz at gcc dot gnu dot org 2009-07-02 15:31 --- Subject: Bug 32131 Author: matz Date: Thu Jul 2 15:31:28 2009 New Revision: 149178 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149178 Log: fortran/ PR fortran/32131 * trans-array.c (gfc_conv_descriptor_stride_get): Return constant one for strides in the first dimension of ALLOCATABLE arrays. testsuite/ PR fortran/32131 * gfortran.dg/pr32921.f: Adjust. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr32921.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-02 14:44 --- Michael Matz fixed that for allocatable arrays, but the patch needs to be extended to nonallocatable arrays, cf. http://gcc.gnu.org/ml/fortran/2009-07/msg4.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #9 from jb at gcc dot gnu dot org 2007-10-12 20:17 --- *** Bug 33753 has been marked as a duplicate of this bug. *** -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-09 23:06 --- How on earth did that PR get assigned to me? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED Last reconfirmed|2007-05-28 20:56:12 |2007-08-08 17:29:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #7 from jb at gcc dot gnu dot org 2007-06-27 15:56 --- (In reply to comment #5) > I can see two ways to address this issue (both of them worth pursuing): > > a) For allocatable arrays, we can always assume stride=1. But this helps only locally in the procedure where the array is declared. If you call another procedure with an explicit interface, that procedure cannot assume that stride==1. I wonder, would it make sense to generate code like if (stride ==1) then some array operation, simplified for the case stride==1 else general case end if Then at least the stride==1 case could be vectorized, and presumably that is also the overwhelmingly common case. Of course it would imply some code bloat. Or is this something the middle-end could do for us? Of course, with IPA this problem could be solved by looking at all the callers.. :) > b) We can tell the middle-end that our random number generator doesn't >modify the array descriptor (similar to PR 20165). Once we've fixed >PR 20165, this should be easy, but I don't see anybody working on it. Another question, do we at the moment tell the middle-end anything about Fortran aliasing rules? E.g. that after the call to random_number (or any other procedure) the a->data is not reachable via some other variable? Or is this another manifestation of the pointer escaping thing from PR 20165? But I would assume some support exists for C99 restrict, which is similar? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #6 from jb at gcc dot gnu dot org 2007-05-29 17:51 --- Reopening. This vectorizes only partly, with -ffast-math to boot. We should be able to vectorize it without doing any "unsafe" math. gfortran -O2 -ffast-math -march=native -mfpmath=sse -ftree-vectorize -ftree-vectorizer-verbose=6 allocate-loop.f90 allocate-loop.f90:15: note: LOOP VECTORIZED. allocate-loop.f90:14: note: LOOP VECTORIZED. allocate-loop.f90:10: note: Vectorizing an unaligned access. allocate-loop.f90:10: note: LOOP VECTORIZED. allocate-loop.f90:9: note: not vectorized: data ref analysis failed D.1424_40 = (*D.1371_14)[D.1423_39] allocate-loop.f90:1: note: vectorized 3 loops in function. and without -ffast-math: gfortran -O2 -march=native -mfpmath=sse -ftree-vectorize -ftree-vectorizer-verbose=6 allocate-loop.f90 allocate-loop.f90:15: note: not vectorized: unsupported use in stmt. allocate-loop.f90:14: note: LOOP VECTORIZED. allocate-loop.f90:10: note: not vectorized: unsupported use in stmt. allocate-loop.f90:9: note: not vectorized: data ref analysis failed D.1424_40 = (*D.1371_14)[D.1423_39] allocate-loop.f90:1: note: vectorized 1 loops in function. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #5 from tkoenig at alice-dsl dot net 2007-05-29 17:47 --- Subject: Re: knowing that stride==1 when using allocated arrays and escaping allocatable arrays On Tue, 2007-05-29 at 04:52 +, pinskia at gcc dot gnu dot org wrote: > we think we change a's stride > which we don't (and cannot in this case). I can see two ways to address this issue (both of them worth pursuing): a) For allocatable arrays, we can always assume stride=1. b) We can tell the middle-end that our random number generator doesn't modify the array descriptor (similar to PR 20165). Once we've fixed PR 20165, this should be easy, but I don't see anybody working on it. So, maybe looking at a) is better. Personally, I like the allocatable array feature of Fortran 95 very much. It'd be a pity if this carried a big performance overhead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-29 06:51 --- Hmm, rebuild and works for me. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 04:52 --- (In reply to comment #2) > PR31738 is another "missed vectorization in Fortran", though I don't think > it's > really that related to this one. The vectorizer issue just exposes the real issue and maybe why GCC is slow in some cases (fixing the aliasing issue here will speed up fortran code even without the vectorizer help). The issue is a.stride is reloaded after the call to random_number as we think random_number can change the stride. If we change the code into: program main implicit none real, allocatable, dimension(:) :: a, b, c real, dimension(10) :: d, e, f real :: s integer :: i allocate (a(10), b(10), c(10)) do i = 0, 10 call random_number(a(i)) call random_number(b(i)) enddo c = a+b s = sum(c) print *,s call random_number(d) call random_number(e) f = d+e s = sum(f) print *,f end program main We get: t.f90:18: note: not vectorized: unsupported use in stmt. t.f90:17: note: LOOP VECTORIZED. t.f90:13: note: not vectorized: unsupported use in stmt. t.f90:12: note: Alignment of access forced using peeling. t.f90:12: note: Vectorizing an unaligned access. t.f90:12: note: Vectorizing an unaligned access. t.f90:12: note: LOOP VECTORIZED. t.f90:8: note: not vectorized: unhandled data-ref t.f90:1: note: vectorized 2 loops in function. Which is correct and shows the aliasing issue, we think we change a's stride which we don't (and cannot in this case). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #2 from jb at gcc dot gnu dot org 2007-05-29 04:30 --- PR31738 is another "missed vectorization in Fortran", though I don't think it's really that related to this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 20:56 --- This is an aliasing issue. The reason why we don't optimize this is because we think a/b and escape except in Fortran that is not the case. I think there is another bug about this case somewhere too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||alias Last reconfirmed|-00-00 00:00:00 |2007-05-28 20:56:12 date|| Summary|knowing that stride==1 when |knowing that stride==1 when |using allocated arrays |using allocated arrays and ||escaping allocatable arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
