[lno] Fix bootstrap on ppc

[Dorit Naishlos]

> I still don't get vectorization:
> ...
> <<get_loop_niters>>
> get_loop_niters: 0.
> 0 iterations??
> loop_analyzer: bad loop form.

Sebastian is working on fixing loop-count calculation problems in the monev
analyzer.

However, even when your program passes the loop-count test, there are still
(at least) two issues that inhibit vectorization of your code at the
moment:

1) Alignment:
As I explained in http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01887.html,
in order to avoid having to deal with unaligned data accesses, the
vectorizer currently tries to make sure that the accessed array is aligned,
or can be forced to be aligned. Soon, using Devang's/Zdeneks's loop
versioning/peeling utilities, we will be able to handle accesses which
alignment is unknown. In the meantime, we conservatively check that the
first access is aligned. The first accesses to the arrays in your program
are at location 'start_index+1', where start_index = TYPE_MIN_VALUE = 0. I
may have misinterpreted Richard's and Paul's responses
(http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02028.html,
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02033.html),
but to my understanding this is a (temporary) problem in the way gfortran
programs are represented, and until it is fixed, there is no way to tell
what is the real start_index of the array. Until then, I expect you will
get the following failure notice from the vectorizer:

> <<vect_analyze_data_ref_accesses>>
> first access not aligned.

2) The use of pointers:
Before failing on the above alignment check, the vectorizer will refuse to
vectorize your program with the following message:

> <<vect_analyze_data_refs>>
> unhanded ptr-based array ref

The only accesses that the vectorizer currently handles are ARRAY_REFs
which base (operand 0) is a VAR_DECL. This restriction (added in my last
check-in http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02120.html) is in
place to ensure that the alignment of the accessed arrays can be forced (by
the way - is this a correct test? is there a less strict test that would
achieve the same purpose?). The ARRAY_REFs in your program are of the form
'(*T.1_64)[S.3_10]' (i.e, the array base is an INDIRECT_REF) and T is a
POINTER_TYPE:
> static real4 a[1000000];
> real4 * T.11;
> real4[] * T.1;
> T.11_63 = &a - 4;
> T.1_64 = (real4[] *)T.11_63;

If there's currently a way in the compiler to tell that such accesses are
aligned, I will relax the above restriction. Otherwise, such accesses will
probably be handled by inserting run time tests. Since these accesses used
to be simple array accesses, I hope this information can be (is already?
will be?) propagated to the trees.

It is definitely my intention to support vectorization of ARRAY_REF
accesses which base is a pointer, also in order to support accesses in C of
the form:
> foo (int p[])
> {
>   for (i=0; i<N; i++) { p[i] = 0; }
> }
These are currently not translated to ARRAY_REFs but transformed into
pointer arithmetic (http://gcc.gnu.org/ml/gcc/2003-07/msg02013.html,
http://gcc.gnu.org/ml/gcc/2003-12/msg00908.html). Richards work will
hopefully solve this problem (
http://gcc.gnu.org/ml/gcc/2003-12/msg00965.html).


Thanks for your feedback,

Dorit.



                                                                                                                                    
                      Toon Moene                                                                                                    
                      <toon@moene.indiv        To:       Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>                           
                      .nluug.nl>               cc:       gcc-patches@gcc.gnu.org, Dorit Naishlos/Haifa/IBM@IBMIL                    
                                               Subject:  Re: [lno] Fix bootstrap on ppc                                             
                      25/01/2004 17:53                                                                                              
                                                                                                                                    




Zdenek Dvorak wrote:

> my attempt to fix the problem in the doloop was obviously bogus,
> since loop->scan_start is always set; this one should be a bit better,
> but probably still not quite correct.  Does not matter, current doloop
will
> disappear from the lno branch completely next week.

This indeed fixed the bootstrap.  However, using the following Fortran
source, I still don't get vectorization:

DIMENSION A(1000000), B(1000000), C(1000000)
READ*, X, Y
A = LOG(X); B = LOG(Y); C = A + B
PRINT*, C(500000)
END

The current complaint is:

<<<<<<< analyze_loop_nest >>>>>>>

<<vect_analyze_loop_form>>

<<get_loop_niters>>
get_loop_niters: 0.
0 iterations??
loop_analyzer: bad loop form.

for:

L.2:;
   T.15_18 = &c - 4;
   T.9_19 = (real4[] *)T.15_18;

   # S.10_1 = PHI <1(4), S.10_39(9)>;
<L7>:;
   T.16_25 = (*T.1_5)[S.10_1];
   T.17_26 = (*T.4_10)[S.10_1];
   T.18_27 = T.16_25 + T.17_26;
   (*T.9_19)[S.10_1] = T.18_27;
   S.10_39 = S.10_1 + 1;
   if (S.10_39 > 1000000) goto L.3; else goto <L11>;

<L11>:;
   goto <bb 5> (<L7>);

I hope this enlightens ...

--
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)