On Wed, Aug 17, 2016 at 8:36 AM, Thomas Koenig <tkoe...@netcologne.de> wrote: > Am 16.08.2016 um 20:57 schrieb Richard Biener: >> >> On August 16, 2016 7:11:26 PM GMT+02:00, Thomas Koenig >> <tkoe...@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...
I suspect the FE is currently just not very careful in exactly replicating the implementations strucure types - sth that shouldn't be too hard to fix. OTOH if this is another case of variable-length vs. fixed-length then it might be harder. > 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. Good - that means it "worked" to some extent. > So, worth investigating. I'll open a PR. Thanks. >> 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. Yeah, I think Honza decided that this usage model for fat objects (shipping libraries with bytecode) wasn't useful and thus the behavior change. I suspect we could add some fancy -flto-allow-option-override mechanics to avoid "fixing" the options in selected cases. It might be a little complicated to get it fool-proof (we can't allow arbitrary changes in late options, esp. for target options). Richard. > Regards > > Thomas
