https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Sun, 2 Jun 2019, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 > > --- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- ... > So, dt_parm_1 is still filled with information in the tight loop > (which the library does not change), and the call to > transfer_real_write.constprop does not do a lot of the things > that could be done in theory, for example keeping the unit > number cached, take a note that this is not asynchronous, > that we always use "NO" on advance in the loop, etc. > > So, is it realistic to expect that LTO could do this kind > of thing with the very complex structure that libgfortran? Sure, why not. Of course the original motivation wasn't so much I/O but inlining/optimizing intrinsics. The frontend does a lot more inlining itself here today so the effect might not be as big.
