[Bug fortran/40973] New: Mark PRIVATE module functions as STATIC to faciliate optimization

[Bug fortran/40973] New: Mark PRIVATE module functions as STATIC to faciliate optimization

[burnus at gcc dot gnu dot org]

We should consider marking module procedures with PRIVATE attribute as STATIC
(in the C sense) such that they can be eliminated. In the following program,
"two" could be optimized away as it cannot be called from outside the module.
However, this does not happen with

  gfortran -O3 -c test.f90    (nor with ifort -O3 -c test, nor for NAG f95,
openf95)

as "nm test.o" shows. I think STATIC does the right thing also if it is used as
in the following example:

  procedure(), pointer :: ptr  ! e.g. dummy argument, module variable, local
variable ...
  ptr => two

I think one cannot mark it as STATIC if it has a C binding name, i.e. PRIVATE
but bind(C). It can be marked as STATIC, however, if it has no binding name: 
bind(C,name="").

(Maybe I miss something as this optimization does not happen for so many
compilers, but I fail to see the flaw.)


MODULE M
  PRIVATE :: two
CONTAINS
  SUBROUTINE one(a)
    integer :: a
    a = two()
  END SUBROUTINE one
  integer FUNCTION two()
     two = 42
  END FUNCTION two
END MODULE


-- 
           Summary: Mark PRIVATE module functions as STATIC to faciliate
                    optimization
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/40973] Mark PRIVATE module functions as STATIC to faciliate optimization

[dfranke at gcc dot gnu dot org]

------- Comment #1 from dfranke at gcc dot gnu dot org  2009-12-04 23:28 -------
How about this (somewhat constructed) example:

! interface module, file (a)
MODULE M
  PRIVATE :: two
CONTAINS
  SUBROUTINE one(a)
    integer :: a
  END SUBROUTINE one
  integer FUNCTION two()
  END FUNCTION two
END MODULE

! implementation, file (b)
SUBROUTINE one(a)
  USE M
  integer :: a
  a = two()
END SUBROUTINE one

integer FUNCTION two()
  two = 42
END FUNCTION two

! another user of the function, without using the interface module, file (c)
SUBROUTINE three(a)
  integer :: a
  a = two()
END SUBROUTINE three


I often use modules simply to provide interfaces for subroutines implemented in
other files and compiled into libraries, then distributing the interface
modules together with the library to avoid issues with .mod files of varying
compiler versions.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/40973] Mark PRIVATE module functions as STATIC to faciliate optimization

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2010-02-20 22:08 -------
Marking it as STATIC will become difficult with SUBMODULES as one has several
.o files belonging to one common MODULE, i.e. the function shall be accessible
by all submodules, which are scattered over several .o files.

With -flto -fwhole-program it should be possible to optimize the function away
even without using STATIC.

(In reply to comment #1)
> How about this (somewhat constructed) example:

I fail to see why __m_MOD_two is needed - it is not called anywhere.

> ! interface module, file (a)
> MODULE M
>   PRIVATE :: two
[...]
>   integer FUNCTION two() [...]
> END MODULE

> ! implementation, file (b)
> SUBROUTINE one(a)
>   USE M
>   integer :: a
>   a = two()
> END SUBROUTINE one

You are calling "two_" which is a REAL function and you are not calling an
INTEGER function and specifically you are not calling __m_MOD_two.
"two" is just an implicitly type external function.

> SUBROUTINE three(a)
>   integer :: a
>   a = two()
> END SUBROUTINE three

This one should be identical to "one".

> I often use modules simply to provide interfaces for subroutines implemented
> in other files and compiled into libraries

You should use ABSTRACT INTERFACE to provide interfaces...


-- 


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