[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #6)
> Comdats are really in conflict with the fact that we have command line
> options. I blame C++ standard for that and I don't think there is fully
> satisfactory solution to this problem.
> 
> I was playing with the idea of warning when at lto time when comdats have
> different command line options, but this triggers way too often in practice.

Really? :/

> We would need to determine "dangerous" one i.e. when -fno-avx2 is replaced
> by -favx2 code. 
> There are many ways one can stubly change semantics of the IL which makes
> merging possibly dangerous which is done often in larger projects, like
> firefox.

I think it would be desirable to diagnose these, maybe with an option to
selectively disable this specific diagnostic.  Because while it is not
always a correctness issue it can be a performance issue as well.

> With syntactic aliases it is possible to keep multiple copies of comdat
> function through merging process so inlining will chose corresponding one,
> but it does make other things harder. One important anoyance is that it
> makes it a lot harder to estimate overall size of the translation unit and
> how inlining affects it. We currently assume that every function will need
> offline unless all calls to it disappears. We will need to understand that
> this is true across all syntacit aliases.
> 
> Also that conditional that disables early inliner for all always_inlines is
> probably bit harmful these days as libstdc++ indeed has quite interesting
> set of always_inlines that call normal inlines. I noticed that just recently
> while looking into the push_back implementation how complex maze it got.
> 
> I will fix early inliner to allow safe inlining to always_inlines.

Beware of new always-inline calls then appearing after greedy inlining
(though that's exactly the case that we try to avoid here).  I suppose
you could disable inlining of a function which contains always-inline
calls or simply functions that did not yet have the early inliner run
on them (so keep the current behavior in cycles).  Beware of indirect
always-inline calls then.

Btw, for Skia the issue is really that some auto-generated CTOR isn't
marked always-inline but everything else is.  Maybe they should use
flatten instead of always-inline ...