Le 14/09/2024 à 20:02, Steve Kargl a écrit :
On Fri, Sep 13, 2024 at 12:27:07PM +0200, Mikael Morin wrote:
gcc/fortran/ChangeLog:
* invoke.texi(finline-intrinsics): Document new flag.
* lang.opt (finline-intrinsics, finline-intrinsics=,
fno-inline-intrinsics): New flags.
* options.cc (gfc_post_options): If the option variable controling
s/controling/controlling
The default value for @var{n} is 30.
+@opindex @code{finline-intrinsics}
+@item -finline-intrinsics
+@itemx -finline-intrinsics=@var{intr1},@var{intr2},...
+Prefer generating inline code over calls to libgfortran functions to implement
+intrinscs.
s/intrinscs/intrinsics
+Usage of intrinsics can be implemented either by generating a call to the
+libgfortran library function implementing it, or by directly generating the
+implementation code inline. For most intrinsics, only a single of those
+variants is available and there is no choice of implementation. For some of
+them, however, both are available, and for them the @code{-finline-intrinsics}
+flag permits the selection of inline code generation in its positive form, or
+library call generation in its negative form @code{-fno-inline-intrinsics}.
+With @code{-finline-intrinsics=...} or @code{-fno-inline-intrinsics=...}, the
+choice applies only to the intrinsics present in the comma-separated list
+provided as argument.
While I understand the intent of 'positive form' vs 'negative form', the
above might be clearer as
Usage of intrinsics can be implemented either by generating a call
to the libgfortran library function or by directly generating inline
code. For most intrinsics, only a single variant is available, and
there is no choice of implementation. However, some intrinsics can
use a library function or inline code, wher inline code typically offers
opportunities for additional optimization over a library function.
With @code{-finline-intrinsics=...} or @code{-fno-inline-intrinsics=...},
the
choice applies only to the intrinsics present in the comma-separated list
provided as argument.
+For each intrinsic, if no choice of implementation was made through either of
+the flag variants, a default behaviour is chosen depending on optimization:
+library calls are generated when not optimizing or when optimizing for size;
+otherwise inline code is preferred.
+
OK with consideration the above comments.
Harald actually gave a partial green light on this already, but
obviously there was still room for improvement.
Thanks for the review, I'm incorporating the changes you suggested.
I was (and still am) waiting for a review from someone knowledgeable in
the options system. I'm considering proceeding without, as I prefer
seeing this pushed sooner than later.
