On Tue, Jan 7, 2014 at 4:47 PM, Paulo Matos <pma...@broadcom.com> wrote:
>> -----Original Message-----
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@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:a...@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
