https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> --- > > 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? :/ Yep, for example firefox consist of many extra libraries (skia, video codecs, image format decoders...) each developed independently LTOed into one libxul. Each of them has its own configure that tampers with command line options. These brings in libstdc++ comdats with different command line sets (over 100 of different command lines for std::vector). Firefox is bit extreme, but it is common for other bigger projects, too. > > 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. I can dig out the patch then. But it was simply printing something like warning: merging comdat function with function of same name but different flags note: first difference is -f..... which was produced similar way we do diffs for optimization and target attributes. Now those -f.... were usually quite misleading as they tended to be internal flags implied by something else (such as -Ofast instead of -O2). Often the picked -f flag was obviously harmless and false positive, however other -f flag might have been important. So I concluded that it is not very easy information to interpret from user perspective. But indeed I agree htat this is not very obvious source of interesting correctness & performance issues. > > 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 ... We disable inlining to always_inline during early inline, but not greedy inline. Both of them can turn indirect calls to direct calls. So I was thinking that as first cut we can inline only callees with no indirect calls and no inlinable direct calls into always_inlines with no indirect calls. Are you worried about possibility of early opt inventing new call into builtin function that is defined as always_inline?
