[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[seurer at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

Bill Seurer <seurer at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |seurer at linux dot vnet.ibm.com

--- Comment #25 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
This is affecting us on powerpc64 as well.  It takes twice as long to build the
spec2017 test cases with most of the difference in a few of the fortran
compilations which take 30 times or more longer.  I tried the new option but it
seems to have no effect.

Some quick comparison timings:

compiling module_first_rk_step_part1.fppized.f90 (part of 521.wrf_r)

r10-484: 0m17, 0m14
r10-485: 9m19, 9m17
r10-7837 (current-ish trunk): 9m57, 10m3
r10-7837 with -finline-arg-packing: 9m58, 9m59

Compiling all of spec2017

r10-484: 34m8 
r10-485: 65m1  
r10-7837: 63m47  
r10-7837 w. option: 65m36

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #26 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Bill Seurer from comment #25)
> This is affecting us on powerpc64 as well.  It takes twice as long to build
> the spec2017 test cases with most of the difference in a few of the fortran
> compilations which take 30 times or more longer.  I tried the new option but
> it seems to have no effect.
> 
> Some quick comparison timings:
> 
> compiling module_first_rk_step_part1.fppized.f90 (part of 521.wrf_r)
> 
> r10-484: 0m17, 0m14
> r10-485: 9m19, 9m17
> r10-7837 (current-ish trunk): 9m57, 10m3
> r10-7837 with -finline-arg-packing: 9m58, 9m59
> 
> Compiling all of spec2017
> 
> r10-484: 34m8 
> r10-485: 65m1  
> r10-7837: 63m47  
> r10-7837 w. option: 65m36

Does the option actually work, i.e. does it have the desired effect
of not expanding the packing inline?  Maybe you could do a quick check
of the tree dumps generated.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 21 Apr 2020, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
> 
> --- Comment #26 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
> (In reply to Bill Seurer from comment #25)
> > This is affecting us on powerpc64 as well.  It takes twice as long to build
> > the spec2017 test cases with most of the difference in a few of the fortran
> > compilations which take 30 times or more longer.  I tried the new option but
> > it seems to have no effect.
> > 
> > Some quick comparison timings:
> > 
> > compiling module_first_rk_step_part1.fppized.f90 (part of 521.wrf_r)
> > 
> > r10-484: 0m17, 0m14
> > r10-485: 9m19, 9m17
> > r10-7837 (current-ish trunk): 9m57, 10m3
> > r10-7837 with -finline-arg-packing: 9m58, 9m59
> > 
> > Compiling all of spec2017
> > 
> > r10-484: 34m8 
> > r10-485: 65m1  
> > r10-7837: 63m47  
> > r10-7837 w. option: 65m36
> 
> Does the option actually work, i.e. does it have the desired effect
> of not expanding the packing inline?  Maybe you could do a quick check
> of the tree dumps generated.

I think you need -fno-inline-arg-packing

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note a possibility would be to emit the packing/unpacking functions as
inline functions so whether inlining happens would be decided by the
middle-end inlining heuristics.  That has the advantage of inlining
only at (estimated) hot call sites and honoring limits set for unit
and function growth.

If the inline function is appropriately declared then the offline
copy would continue to reside in libgfortran.

Not sure if this enables the same optimization as fully inlining
the packing/unpacking in the frontend does.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[seurer at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #29 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
The suggestion above was to use -finline-arg-packing but I will try
-fno-inline-arg-packing.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[seurer at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #30 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
I tried

-fno-inline-arg-packing

and with that the time to build all of spec2017 is 28m43 versus 63m to 65m
without.

For my purposes this is fine BUT will using this option have some sort of
performance effect when the tests are run?

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #31 from Michael Meissner <meissner at gcc dot gnu.org> ---
For the Spec 2017 521.wrf_r benchmark on little endian PowerPC power9 systems,
there was no difference in runtime between a normal run using -Ofast
-mcpu=power9 and one with -Ofast -mcpu=power9 -fno-inline-arg-packing.

Of the seven rate benchmarks in Spec 2017 that use Fortran (548.exchange2_r,
503.bwaves_r, 507.cactuBSSN_r, 521.wrf_r, 527.cam4_r, 549.fotonik3d_r, and
554.roms_r) none of them vary by more tha 0.7% depending on whether the switch
is used or not.

I used the compiler checked out from the master branch on March 27, 2020 to
build and run the benchmarks.

As others have said, using -fno-inline-arg-packing does dramatically reduce the
time it takes to compile 521.wrf_r.

[Bug middle-end/91512] [10/11 Regression] Fortran compile time regression.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.0                        |10.2

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.1 has been released.

[Bug middle-end/91512] [10/11 Regression] Fortran compile time regression.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.2                        |10.3

--- Comment #33 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.2 is released, adjusting target milestone.

[Bug middle-end/91512] [10/11 Regression] Fortran compile time regression.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.3                        |10.4

--- Comment #34 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.3 is being released, retargeting bugs to GCC 10.4.

[Bug middle-end/91512] [10/11/12/13 Regression] Fortran compile time regression.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug middle-end/91512] [11/12/13/14 Regression] Fortran compile time regression.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #36 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.