https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
So, I played around with this a little. By putting in
-flto and -ffat-lto-binaries into CFLAGS, FFLAGS and LDFLAGS
into the Makefile in the libgfortran build directory, it is
possible to build an LTO-enabled libgfortran.
For the first test (write.f90 from comment#1 below), a small
patch
Index: io/open.c
===================================================================
--- io/open.c (Revision 271843)
+++ io/open.c (Arbeitskopie)
@@ -740,6 +740,7 @@ st_open (st_parameter_open *opp)
GFC_INTEGER_4 cf = opp->common.flags;
unit_convert conv;
+ memset (&flags, 0, sizeof(flags));
library_start (&opp->common);
/* Decode options. */
led to a lot of conditional code not being pulled into the
main program. So far, so good - constant folding for open
was good.
The main function then became (in the optimized tree dump)
<bb 2> [local count: 10737418]:
open_parm.0.common.filename = &"write.f90"[1]{lb: 1 sz: 1};
open_parm.0.common.line = 5;
open_parm.0.file = &"foo.bar"[1]{lb: 1 sz: 1};
open_parm.0.file_len = 7;
open_parm.0.readonly = 0;
MEM[(int *)&open_parm.0] = 42966450432;
st_open.constprop (&open_parm.0);
open_parm.0 ={v} {CLOBBER};
# DEBUG i => 1
<bb 3> [local count: 1063004407]:
# ivtmp_27 = PHI <10000000(2), ivtmp_1(3)>
# DEBUG i => NULL
_gfortran_random_r8 (&a);
dt_parm.1.common.filename = &"write.f90"[1]{lb: 1 sz: 1};
dt_parm.1.common.line = 8;
dt_parm.1.advance = &"NO"[1]{lb: 1 sz: 1};
dt_parm.1.format = &"(E17.8,\" \")"[1]{lb: 1 sz: 1};
MEM[(long int *)&dt_parm.1 + 88B] = { 11, 2 };
MEM[(int *)&dt_parm.1] = 42949685248;
st_write.constprop (&dt_parm.1);
transfer_real_write.constprop (&dt_parm.1, &a);
st_write_done (&dt_parm.1);
dt_parm.1 ={v} {CLOBBER};
# DEBUG i => NULL
ivtmp_1 = ivtmp_27 + 4294967295;
if (ivtmp_1 == 0)
goto <bb 4>; [1.01%]
else
goto <bb 3>; [98.99%]
<bb 4> [local count: 10737418]:
a ={v} {CLOBBER};
return;
}
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?
