https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600
--- Comment #12 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Jerry DeLisle from comment #11)
> I was experimenting some more here a few days ago. I really think that
> inlineing shold be disabled above some threshold. On larger arrays, the
> runtime library outperforms inline and right now by default the runtime
> routines are never used unless you provide -fno-frontend-optimize which is
> counter intuitive for the larger arrays.
May I suggest reading the docs? ;-)
`-finline-matmul-limit=N'
When front-end optimiztion is active, some calls to the `MATMUL'
intrinsic function will be inlined. This may result in code size
increase if the size of the matrix cannot be determined at compile
time, as code for both cases is generated. Setting
`-finline-matmul-limit=0' will disable inlining in all cases.
Setting this option with a value of N will produce inline code for
matrices with size up to N. If the matrices involved are not
square, the size comparison is performed using the geometric mean
of the dimensions of the argument and result matrices.
> If one compiles with -march=native -mavx -Ofast etc etc, the inline can do
> fairly well on the larger, however when we update the runtime routines to
> something like shown in comment #8 it will make even more sense to not do
> inline all the time. (Unless of course we further optimize the
> frontend-optimize to do better.)
We can give this option a reasonable default value. The current
status is
The default value for N is the value specified for
`-fblas-matmul-limit' if this option is specified, or unlimitited
otherwise.
