This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Infinite number of iterations in loop [v850, mep]
- From: Paulo Matos <pmatos at broadcom dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Andrew Haley <aph at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 8 Jan 2014 14:09:56 +0000
- Subject: RE: Infinite number of iterations in loop [v850, mep]
- Authentication-results: sourceware.org; auth=none
- References: <19EB96622A777C4AB91610E763265F463A757B at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <5283A108 dot 1020108 at redhat dot com> <19EB96622A777C4AB91610E763265F463A761A at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <19EB96622A777C4AB91610E763265F463E5E93 at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <CAFiYyc2ZzJFP0eYkZviZdt7YFxnFChRJNdwqsUs7T9=FmU-+xA at mail dot gmail dot com>
> -----Original Message-----
> From: Richard Biener [mailto:richard.guenther@gmail.com]
> Sent: 08 January 2014 11:03
> To: Paulo Matos
> Cc: Andrew Haley; gcc@gcc.gnu.org
> Subject: Re: Infinite number of iterations in loop [v850, mep]
>
> That was refering to the case with extern b. For the above case the
> issue must be sth else. Trying a cross to v850-elf to see if it
> reproduces for me (if 'b' is a stack or argument slot then we might
> bogously think that *c++ = 0 may clobber it, otherwise RTL
> number of iteration analysis might just be confused).
>
> So for example (should be arch independent)
>
> struct X { int i; int j; int k; int l[24]; };
>
> int foo (struct X x, int *p)
> {
> int z = x.j;
> *p = 1;
> return z;
> }
>
> see if there is a anti-dependence between x.j and *p on the RTL side
> (at least the code dispatching to the tree oracle using the MEM_EXPRs
> should save you from that).
>
> So - v850 at least doesn't pass b in memory and the doloop recognition
> works for me (on trunk).
>
You are right, everything is fine with the above example regarding the anti-dependence and with the loop as well. I got confused with mine not generating a loop for
void fn1 (unsigned int b)
{
unsigned int a;
for (a = 0; a < b; a++)
*c++ = 0;
}
but that simply because in our case it is not profitable.
However, for the case:
void matrix_add_const(unsigned int N, short *A, short val) {
unsigned int i,j;
for (i=0; i<N; i++) {
for (j=0; j<N; j++) {
A[i*N+j] += val;
}
}
}
GCC thinks for v850 and my port that the inner loop might be infinite.
It looks like GCC is mangling the loop so much that the obviousness that the inner loop is finite is lost.
This however turns out to be very performance degrading. Using -fno-ivopts makes generation of loops work again both in my port and v850.
Is there a way to fine-tune ivopts besides trying to tune the costs or do you reckon this is something iv-analysis should be smarter about?
Paulo Matos
> Richard.
>
> > The same situation occurs with a coremark function:
> > void matrix_add_const(ee_u32 N, MATDAT *A, MATDAT val) {
> > ee_u32 i,j;
> > for (i=0; i<N; i++) {
> > for (j=0; j<N; j++) {
> > A[i*N+j] += val;
> > }
> > }
> > }
> >
> > It also says the inner loop might be infinite but it can't N is given as
> argument. j starts as 0, N is unsigned like N. This will loop N times. GCC cannot
> possibly assume array A will overwrite the value of N in the loop. This seems
> like something is wrong in alias analysis.
> >
> >> --
> >> PMatos