Am 08.08.24 um 19:13 schrieb Thomas Koenig:
Am 08.08.24 um 11:09 schrieb Mikael Morin:
As we are not planning to remove the library implementation (-Os!),
this is also the best way to compare library to inline code.
This makes perfect sense, but why reuse the -ffrontend-optimize option?
The manual describes it as:
This option performs front-end optimization, based on manipulating
parts the Fortran parse tree
These patches are about inlining, there is no manipulation of the
parse tree. So I would rather use a separate option
(-finline-intrinsics?).
I concur, -ffrontend-optimize should remain specific to manipulating
the parse tree.
Having a -finline-intrinsic options, which would be set at any
optimization level except -Os, may be the right way forward.
Or something else :-)
Well, I am not so convinced that -finline-intrinsics is a good choice.
What do you think users will expect from it?
Quoting from the current documentation:
-ffrontend-optimize
This option performs front-end optimization, based on manipulating
parts the Fortran parse tree. Enabled by default by any -O option except
-O0 and -Og. Optimizations enabled by this option include:
inlining calls to MATMUL,
elimination of identical function calls within expressions,
removing unnecessary calls to TRIM in comparisons and assignments,
replacing TRIM(a) with a(1:LEN_TRIM(a)) and
short-circuiting of logical operators (.AND. and .OR.).
It can be deselected by specifying -fno-frontend-optimize.
So we currently already do selective inlining, which we extend to
more intrinsics, and may further extend in the future.
But if you think we really need a new option I'm fine with it.
Harald
Best regards
Thomas
