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: Richard Biener <richard dot guenther at gmail dot com>
- To: Paulo Matos <pmatos at broadcom 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 12:02:58 +0100
- 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>
On Tue, Jan 7, 2014 at 4:47 PM, Paulo Matos <pmatos@broadcom.com> wrote:
>> -----Original Message-----
>> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Paulo
>> Matos
>> Sent: 13 November 2013 16:14
>> To: Andrew Haley
>> Cc: gcc@gcc.gnu.org
>> Subject: RE: Infinite number of iterations in loop [v850, mep]
>>
>> > -----Original Message-----
>> > From: Andrew Haley [mailto:aph@redhat.com]
>> > Sent: 13 November 2013 15:56
>> > To: Paulo Matos
>> > Cc: gcc@gcc.gnu.org
>> > Subject: Re: Infinite number of iterations in loop [v850, mep]
>> >
>> > On 11/13/2013 03:48 PM, Paulo Matos wrote:
>> >
>> > Because GCC does not know that *c++ = 0; will not overwrite b . I
>> > suppose you could argue that it's not really infinite, because a will
>> > eventually equal 0xffffffff, but I think that's what is going on.
>> >
>> > Andrew.
>> >
>>
>>
>> I will try to investigate further.
>>
>
> After re-encountering this issue something is amiss. I think this is incorrect.
> In the example:
> extern int *c;
>
> void fn1 (unsigned int b)
> {
> unsigned int a;
> for (a = 0; a < b; a++)
> *c++ = 0;
> }
>
> It doesn't make sense to assume *c++ will overwrite b. b is an argument to the function.
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).
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