[Fortran] Use ANNOTATE_EXPR annot_expr_ivdep_kind for DO CONCURRENT

This patch requires my pending ME and C FE patch: 
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00514.html

Using C/C++'s #pragma ivdep or – with the attached Fortran patch – "do 
concurrent", the loop condition is annotated such that later the loop's 
vectorization safelen is set to infinity (well, INT_MAX). The main 
purpose is to tell the compiler that the result is independent of the 
order in which the loop is walked. The typical case is pointer aliasing, 
in which the compiler either doesn't vectorize or adds a run-time 
aliasing check (loop versioning). With the annotation, the compiler 
simply assumes that there is no aliasing and avoids the versioning. – 
Contrary to C++ which does not even have the "restrict" qualifier (gcc 
and others do support __restrict) and cases where C/C++'s __restrict 
qualifier isn't sufficient/applicable, the effect on typical Fortran 
code should be smaller as most variables cannot alias. Still, in some 
cases it can help. (See test case for an example.)

There is an alternative to ivdep, which is more lower level [1]: 
OpenMPv4's "omp simd" (with safelen=) for C/C++/Fortran and – for C/C++ 
– Cilk Plus's #pragma simd.

Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias

PS: I think the same annotation could be also used with FORALL and 
implied loops with whole-array/array-section assignments, when the FE 
knows that there is no aliasing between the LHS and RHS side. (In some 
cases, the FE knows this while the ME doesn't.)

PPS: My personal motivation is my long-standing wish to pass this 
information to the middle end for DO CONCURRENT but also to use the 
pragma for a specific C++ code.

[1] The OpenMPv4 support for C/C++ will be merged soon, for Fortran it 
will take a while (maybe still in 4.9, maybe only later). See 
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00502.html / The relevant 
Cilk Plus patch has been posted at 
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01626.html

Two weeks ago I submitted the patch, available at: 
http://gcc.gnu.org/ml/fortran/2013-10/msg00022.html ; while the ME patch 
is not yet approved, the C FE was approved (latest C/ME patch: 
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01752.html).

Additionally, I'd like to early ping for: 
http://gcc.gnu.org/ml/fortran/2013-10/msg00068.html

Tobias

PS: Actually, safelen (i.e. "GCC ivdep", "omp simd", Cilk's "simd") does 
not require that the result is independent of the loop-waking order. 
Just (quoting from my C patch for GCC ivdep): "With this pragma, the 
programmer asserts that there are no loop-carried dependencies which 
would prevent that consecutive iterations of the following loop can be 
executed concurrently with SIMD (single instruction multiple data) 
instructions."
Fortran's do concurrent requires more: "The DO CONCURRENT construct 
provides a means for the program to specify that individual loop
iterations have no interdependencies." (F2008, Introduction). Still, in 
terms of optimizing "do concurrent", setting safelen gives the ME all 
required information.


On Oct 08, 2013, Tobias Burnus wrote:
> This patch requires my pending ME and C FE patch: 
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00514.html
>
> Using C/C++'s #pragma ivdep or – with the attached Fortran patch – "do 
> concurrent", the loop condition is annotated such that later the 
> loop's vectorization safelen is set to infinity (well, INT_MAX). The 
> main purpose is to tell the compiler that the result is independent of 
> the order in which the loop is walked. The typical case is pointer 
> aliasing, in which the compiler either doesn't vectorize or adds a 
> run-time aliasing check (loop versioning). With the annotation, the 
> compiler simply assumes that there is no aliasing and avoids the 
> versioning. – Contrary to C++ which does not even have the "restrict" 
> qualifier (gcc and others do support __restrict) and cases where 
> C/C++'s __restrict qualifier isn't sufficient/applicable, the effect 
> on typical Fortran code should be smaller as most variables cannot 
> alias. Still, in some cases it can help. (See test case for an example.)
>
> There is an alternative to ivdep, which is more lower level [1]: 
> OpenMPv4's "omp simd" (with safelen=) for C/C++/Fortran and – for 
> C/C++ – Cilk Plus's #pragma simd.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
>
> PS: I think the same annotation could be also used with FORALL and 
> implied loops with whole-array/array-section assignments, when the FE 
> knows that there is no aliasing between the LHS and RHS side. (In some 
> cases, the FE knows this while the ME doesn't.)
>
> PPS: My personal motivation is my long-standing wish to pass this 
> information to the middle end for DO CONCURRENT but also to use the 
> pragma for a specific C++ code.
>
> [1] The OpenMPv4 support for C/C++ will be merged soon, for Fortran it 
> will take a while (maybe still in 4.9, maybe only later). See 
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00502.html / The relevant 
> Cilk Plus patch has been posted at 
> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01626.html

On Tue, Oct 22, 2013 at 08:30:44PM +0200, Tobias Burnus wrote:
> Two weeks ago I submitted the patch, available at: 
> http://gcc.gnu.org/ml/fortran/2013-10/msg00022.html ; while the ME patch 
> is not yet approved, the C FE was approved (latest C/ME patch: 
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01752.html).

The Fortran part is OK.