[Fortran] Another array reference dependency improvement

[Paul Thomas]

Janne,

>
>No, it seems to be a real regression, I'm seeing it on trunk too, now
>that Roger backed out the second patch. My time for channel went up
>from 16.91 to 24.86.
>
You are absolutely right.  In fact, the lines 152-164 in the main 
program are the culprits:

    u(2:M-1,1:N,new) = u(2:M-1,1:N,old) &               ! interior u points
        +2.d0*dt*f(2:M-1,1:N)*v(2:M-1,1:N,mid) &
        -2.d0*dt/(2.d0*dx)*g*dhdx(2:M-1,1:N)

    v(1:M,2:N-1,new) = v(1:M,2:N-1,old) &               ! interior v points
        -2.d0*dt*f(1:M,2:N-1)*u(1:M,2:N-1,mid) &
        -2.d0*dt/(2.d0*dy)*g*dhdy(1:M,2:N-1)

    h(1:M,2:N-1,new) = h(1:M,2:N-1,old) &               ! interior h points
        -2.d0*dt/(2.d0*dx)*Href*dudx(1:M,2:N-1) &
        -2.d0*dt/(2.d0*dy)*Href*dvdy(1:M,2:N-1)

They now produce calls to _gfortran_internal_malloc that were not there 
before.  I believe that

	(gfc_check_element_vs_element): Assume lref and rref must be
	REF_ARRAYs.  If gfc_dep_compare_expr returns -2, assume these
	references could potentially overlap.

is doing it.  The subsequent patch was able to do the right thing in this case and to determine that there is no dependency.

I propose that, since this regression only slows the code down a bit but produces the correct result, that we give Roger time to fix the second patch along the lines that were discussed on the list.

Yes, your test results look very good too; I guess that such relative differences as there are reflect different architectural weaknesses - L2 in the case of an AthlonXP1700.  I would be curious to know if you also see a slow-down in going from 4.1 to 4.2?

Cheers

Paul