This is the mail archive of the gcc@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]

Re: Using LTO-enabled libgfortran


Am 16.08.2016 um 20:57 schrieb Richard Biener:
On August 16, 2016 7:11:26 PM GMT+02:00, Thomas Koenig <tkoenig@netcologne.de> wrote:
What would it take to use an LTO-enabled version of gfortran?

It could turn out to be quite useful for speeding up programs,
especially where I/O or array intrinsics are used.

I also expect many issues to surface where libgfortran is
playing with types in a way that could break LTO, so I
would not expect this to be an easy thing.

So, ideas anybody?  I don't think any other library included
with gcc does this, correct?

Correct.  My advice is to simply try.

I did that, with some interesting results.

Just putting -flto -ffat-lto-objects into every CFLAG and FFLAG
available into the Makefile of libgfortran (autoconf can come later :-),
recompiling gfortran and trying out the program

program main
  real, dimension(10) :: a
  call random_number(a)
  write (*,'(E12.5)',advance="no") a
end program main

led to

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 lto1: warning: type of '_gfortran_transfer_array_write' does not match original declaration [-Wlto-type-mismatch] ../../../trunk/libgfortran/io/transfer.c:2195:1: note: 'transfer_array_write' was previously declared here ../../../trunk/libgfortran/io/transfer.c:2195:1: note: code may be misoptimized unless -fno-strict-aliasing is used lto1: warning: type of '_gfortran_st_write_done' does not match original declaration [-Wlto-type-mismatch] ../../../trunk/libgfortran/io/transfer.c:3756:1: note: 'st_write_done' was previously declared here ../../../trunk/libgfortran/io/transfer.c:3756:1: note: code may be misoptimized unless -fno-strict-aliasing is used

So, the expected surprises appeared...

From the disassembly, I could also see that LTO had done some things;
there were references to functions like
_gfortrani_gf_strerror.constprop.18, write_decimal.isra.5.constprop.11,
nml_parse_qualifier.constprop.15 and _gfortran_arandom_r4.constprop.3.

So, worth investigating. I'll open a PR.

 Note this will work only for static libgfortran.  Also note that since
the  LTO option scheme changed to preserve compile-time optimization
and target attributes LTOing libgfortran will be less useful than
before (you won't get any advantage from extra available ISAs).

Once every other problem has been solved :-) I am sure we can address
this one.

Regards

	Thomas


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