[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491

--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 14 Apr 2023, chip.kerchner at ibm dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
> 
> --- Comment #14 from Chip Kerchner <chip.kerchner at ibm dot com> ---
> Just one more question and then I'll switch to the new bug.
> 
> Would it help any if the functions that are "always_inline" be changed from
> non-static to static?
> 
> Eigen's approach (where this code originally came from - yes, it could be
> definite be better) is to use non-static inlined function.

I don't think so, you'd have to try.  The compile-time issues usually
show up when you have a multi-level call chain all being always-inline
as we then repeatedly early-optimize the same code over and over.
Usually we do that so functions become smaller for the inline heuristics
but for always-inlines that wouldn't matter (but of course making the
body smaller if there's more than one caller can still pay off).

It really depends on the actual callgraph and code which is also
why it is hard to improve.

Another probably more common with C++ code issue would be that we
inline into not optimized callers which means calls that are
almost trivially unreachable have not been eliminated yet but
get inlined.  Usual heuristics would only inline small functions
at this level and defer inlining of larger functions to IPA time
at which point the calls might be eliminated already.  Likewise
calls attributed const or pure might be subject to CSE but
always-inline forces them to be inlined before CSE.

So what you could try is instead of always_inline use
__attribute__((flatten)) on the functions containing the
loop kernels for example and then disable early inlining
(otherwise flatten is applied there as well) with -fno-early-inlining.