This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop fusion.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Toon Moene <toon at moene dot org>
- Cc: gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Mon, 23 Apr 2018 13:00:46 +0200
- Subject: Re: Loop fusion.
- References: <71dd38d0-2dbc-0100-7419-6f1ca1d5e077@moene.org>
On Sun, Apr 22, 2018 at 4:27 PM, Toon Moene <toon@moene.org> wrote:
> A few days ago there was a rant on the Fortran Standardization Committee's
> e-mail list about Fortran's "whole array arithmetic" being unoptimizable.
>
> An example picked at random from our weather forecasting code:
>
> ZQICE(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YI%MP)
> ZQLI(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YL%MP)
> ZQRAIN(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YR%MP)
> ZQSNOW(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YS%MP)
>
> The reaction from one of the members of the committee (about "their"
> compiler):
>
> 'And multiple consecutive array statements with the same shape are “fused”
> exactly so that the compiler can generate good cache use. This sort of
> optimization is pretty low hanging fruit.'
>
> As far as I can see loop fusion as a stand-alone optimization is not
> supported as yet, although some mention is made in the context of graphite.
>
> Is this something that should be pursued ?
In principle GRAPHITE can handle loop fusion but yes, standalone fusion
is sth useful.
Note that while it looks "obvious" in the above source fragment the IL
that is presented to optimizers may make things a lot less "low-hanging".
Richard.
> Kind regards,
>
> --
> Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
> At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
> Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news