More than you ever wanted to know about Fortran array indexing;-)

[Toon Moene]

>  The appended patch, I believe, does this.  The result is
>  relatively good code for all of the examples that have
>  been posted so far.

Yep, the timing for bs3dvw.f also is around the same value as with  
the FFECOM_FASTER_ARRAY_REFS "solution".  BTW, it seems to be very  
hard to get consistent timings on a Linux Alpha - in five runs I got  
anywhere between 3.6 and 4.3 seconds, whereas on my machine it is  
consistent up to the tenth of seconds (and it takes 90 seconds !).

>  Only, I would like to see loop take y[i-1], y[i], y[i+1],
>  make one induction variable, and use -4(R), 0(R), 4(R)
>  in the loop.  Hmm...

This is a nice follow-on project :-)  Note that lots of  
computational physics code is based on finite difference or finite  
element algorithms, which all have these opportunities for  
optimisation.

Or recognise that, on loop unrolling, you've got the following  
equivalences:

1	y(i-1)	y(i)	y(i+1)
2		y(i-1)	y(i)	y(i+1)
3			y(i-1)	y(i)	y(i+1)
4				y(i-1)	y(i)	y(i+1)

Anyway, we can consider this problem "solved" (apply Jeff's `use'  
patch, your `expr' patch, my `fold' patch and your `frontend'  
patch), unless Craig objects against the frontend changes.

There is namely a pedantic-standards-interpretation question hiding  
in your frontend patch:  Should the compiler evaluate each and  
every expression in the mode it is written in ?  Note that  
currently, g77+backend as a whole already violate that rule because  
of the `sizetype' promotion `expr.c' does.  What your frontend patch  
does is lift this uncleanliness up into the frontend ...

We'll see - Craig has the last word on this.

Cheers,
Toon.

PS: I'm starting a test now with all those patches applied to  
egcs-970929, to see if it still works on my Fortran code ;-)

PS2: My `fold' patch has a typo; somewhere it says:
+               && multiple_of_p (Ttype, REE_OPERAND (xarg0, 1), arg1))
     Obviously, this should be:
+               && multiple_of_p (type, TREE_OPERAND (xarg0, 1),  
arg1))