This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop fusion.
- From: "Bin.Cheng" <amker dot cheng 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 11:59:34 +0100
- Subject: Re: Loop fusion.
- References: <71dd38d0-2dbc-0100-7419-6f1ca1d5e077@moene.org>
On Sun, Apr 22, 2018 at 3: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 ?
Hi,
I don't know the current status of fusion in graphite. As for
traditional fusion transformation, I think it's not very difficult to
be implemented along with existing distribution, actually, quite lot
of code should be shared. What we do need are something like: more
motivation cases, good/conservative cost model.
Thanks,
bin
>
> 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