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 libfortran/77278] New: Use LTO for libgfortran


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

            Bug ID: 77278
           Summary: Use LTO for libgfortran
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

In order to aid optimization, it could be beneficial to
build libgfortran as an lto-enabled library. There could be
a big win for functions being called via constant propagation,
especially for I/O and array operations.

With I/O, checking for large number of options at runtime could
be avoided.  Array operations could profit from cases where arrays
are contiguous, when the library needs to take non-contiguous cases
into account.

Some discussion starts here.

https://gcc.gnu.org/ml/fortran/2016-08/msg00069.html

What has been done so far to identify potential problems
was to manually add -flto -ffat-lto-objects to the Makefile
in libgfortran and compile a simple program with -flto.

This led to error messages like

lto1: warning: type of '_gfortran_st_write' does not match original declaration
[-Wlto-type-mismatch] ../../../trunk/libgfortran/io/transfer.c:3746:1: note:
'st_write' was previously declared here
../../../trunk/libgfortran/io/transfer.c:3746:1: note: code may be misoptimized
unless -fno-strict-aliasing is used

so there is likely work to do on the library side and on the LTO side.

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