This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/33245] Missed opportunities for vectorization due to invariant condition
- From: "dorit at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 31 Aug 2007 13:39:03 -0000
- Subject: [Bug tree-optimization/33245] Missed opportunities for vectorization due to invariant condition
- References: <bug-33245-7780@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #1 from dorit at gcc dot gnu dot org 2007-08-31 13:39 -------
(In reply to comment #0)
> The innermost loop in "j" cannot be vectorized because of the
> irregular code in that loop, i.e. the condition "IF ( l.NE.k )". But
> the cond expression is invariant in that loop, so the whole condition
> can be hoisted outside that loop, versioning the loop, and potentially
> allowing the vectorization of the innermost loop.
if you use -O3 the condition *is* taken out of the loop by loop-unswitch (at
least that's what I see with revision 127623).
> SUBROUTINE DGEFA(A,Lda,N,Ipvt,Info)
> INTEGER Lda , N , Ipvt(*) , Info
> DOUBLE PRECISION A(Lda,*)
> DOUBLE PRECISION t
> INTEGER IDAMAX , j , k , kp1 , l , nm1
> Info = 0
> nm1 = N - 1
> IF ( nm1.GE.1 ) THEN
> DO k = 1 , nm1
> kp1 = k + 1
> l = IDAMAX(N-k+1,A(k,k),1) + k - 1
> Ipvt(k) = l
> IF ( A(l,k).EQ.0.0D0 ) THEN
> Info = k
> ELSE
> IF ( l.NE.k ) THEN
> t = A(l,k)
> A(l,k) = A(k,k)
> A(k,k) = t
> ENDIF
> t = -1.0D0/A(k,k)
> CALL DSCAL(N-k,t,A(k+1,k),1)
> DO j = kp1 , N
> t = A(l,j)
> IF ( l.NE.k ) THEN
> A(l,j) = A(k,j)
> A(k,j) = t
> ENDIF
> CALL DAXPY(N-k,t,A(k+1,k),1,A(k+1,j),1)
> ENDDO
> ENDIF
> ENDDO
> ENDIF
> Ipvt(N) = N
> IF ( A(N,N).EQ.0.0D0 ) Info = N
> CONTINUE
> END
> The result of the vectorizer on this testcase is:
> /home/seb/ex/linpk.f90:24: note: not vectorized: too many BBs in loop.
> /home/seb/ex/linpk.f90:24: note: bad loop form.
> /home/seb/ex/linpk.f90:1: note: vectorized 0 loops in function.
> Okay, if I'm versioning that loop by hand, I get the same error due to
> the PRE as for capacita.f90: the PRE inserts in the loop->latch block
> some code:
> <bb 11>:
> # VUSE <PARM_NOALIAS.16_252> { PARM_NOALIAS.16 }
> pretmp.47_297 = *n_13(D);
> goto <bb 10>;
Looks like -fno-tree-pre is not enough, because if PRE doesn't do it, then sink
does it. When I use "-O3 -ftree-vectorize -msse2 -fno-tree-pre -fno-tree-sink"
I get the dataref problem you report below, without manual modifications to the
code
> And with PRE disabled, the fail occurs in the data ref analysis:
> ./linpk_corrected.f90:26: note: not vectorized: data ref analysis failed t.8_70
> = (*a_25(D))[D.1406_69]
> ./linpk_corrected.f90:26: note: bad data references.
Just for the record, this is the dataref problem that the dataref analyzer
reports:
Creating dr for t
analyze_innermost: (analyze_scalar_evolution
(loop_nb = 3)
(scalar = &t)
(get_scalar_evolution
(scalar = &t)
(scalar_evolution = ))
)
success.
base_address: &t
offset from base address: 0
constant offset from base address: 0
step: 0
aligned to: 128
base_object: t
symbol tag: t
FAILED as dr address is invariant
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33245