This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [lno] [patch] vectorizer update - loop bound
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- To: Dorit Naishlos <DORIT at il dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, pop at gauvain dot u-strasbg dot fr
- Date: Mon, 19 Jan 2004 00:08:48 +0100
- Subject: Re: [lno] [patch] vectorizer update - loop bound
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <OFD3B76F8E.0D178FAA-ONC2256E1F.00289406-C2256E1F.003BC592@il.ibm.com>
Dorit Naishlos wrote:
The patch below implements a more general loop bound transformation scheme
- still limited to known loop bound that divides by the vectorization
factor, but no longer dependent on the loop IV eolution and the loop exit
condition form. This allows relaxing the restrictions that the vectorizer
imposed on the loop exit condition, and use the precomputed
loop->nb_iterations instead (from the monev analyzer). As a result, two of
the loops in the test case tree-ssa-vect-none.c (#12 and #13) are now
vectorizable, and are therefore moved to tree-ssa-vect-all.c.
Still ...
No vector, no cry:
$ cat vector.f95
DIMENSION A(1000000), B(1000000), C(1000000)
READ*, X, Y
A = LOG(X); B = LOG(Y); C = A + B
PRINT*, C(500000)
END
From vector.f95.t34.vect:
<<vect_analyze_data_ref_accesses>>
step:
1
init:
1no vectype for stmt.
(*T.9_78)[S.10_18] = T.18_114loop_analyzer: bad data access.
This is the relevant loop:
<L6>:;
if (S.10_18 > 1000000) goto L.3; else goto <L7>;
<L7>:;
T.16_112 = (*T.1_64)[S.10_18];
T.17_113 = (*T.4_69)[S.10_18];
T.18_114 = T.16_112 + T.17_113;
(*T.9_78)[S.10_18] = T.18_114;
S.10_120 = S.10_18 + 1;
goto <bb 7> (<L6>);
Hope someone can analyse this ...
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)