This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/42118] Slow forall


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Harald Anlauf from comment #5)
> Do not forget that there are constraints for FORALL statements that are
> not required for DO loops so that all assignments are independent.
> This guarantees vectorization

Not quite: The Fortran standard requires that the RHS is evaluated before the
assignment to the LHS is done. This might even imply the generation of a
temporary variable. By contrast, DO CONCURRENT is much better: The user
guarantees that the is no order dependence, while constraints ensure that the
many violations of this are detected at compile time. In addition, DO
CONCURRENT permits more things within its body.

By the way, the Fortran committee is considering to deprecate FORALL in the
next standard (Fortran 2015) because it considers FORALL superior in nearly all
aspects.

For DO CONCURRENT, I have a pending patch which sets the vectorization safelen
to infinity (well INT_MAX). I wonder whether one could do likewise for FORALL;
that probably needs some dependency fine tuning to ensure that there is
dependency at all between the LHS and RHS. To avoid temporaries, it is
sufficient to be either forward or backward dependency free.

(Setting the safelen for whole-array operations probably also makes sense.
There, the same applies.)



(In reply to Lionel GUEZ from comment #6)
> There is also the problem of the order of indices in a forall. I guess this
> is in close relation to the comparison of do and forall.

Try compiling with -floop-interchange (requires a GCC built with Graphite).

Deciding which order is best is not a trivial task, although in simple cases as
yours, it shouldn't be that difficult. Maybe someone finds the time to do it.

[Presumably the same issue comes up with DO CONCURRENT, if one places multiple
iteration variables into that statement (opposed to using multiple DO
CONCURRENT statements with one iteration variable).]

> According to the Fortran standard, the order of indices in the forall header
> is of no consequence.

Well, it doesn't with any of the compilers: The resulting value is always the
same. The standard doesn't tell anything about the performance (not about the
index walking order).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]