https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103989
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 13 Jan 2022, hubicka at kam dot mff.cuni.cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103989 > > --- Comment #10 from hubicka at kam dot mff.cuni.cz --- > > And I'm intentionally not doing this because -Og should still remove > > abstraction during early inlining (for functions marked 'inline'), we > > just don't want to spend the extra compile time doing IPA inlining > > or cleaning up after IPA inlining. > > Indeed it seemed bit too extreme to disable inlining completely at -Og :) > So you want early inliner to behave normally according to flags > while IPA inliner to skip all calls where either caller or > callee is -Og and callee is not always_inline? > This can be done in can_inline_edge_p. I will make patch for that. Yeah, and since we inline all always inline and also flatten during early inline the IPA inliner should really do nothing. > It may be nice to also avoid re-analyzing functions completely to save > some compile time, but that may be bit tricky if we decide to do things > like cross-module always_inline. I will look into that too, but perhaps > that can wait for next stage1. I think we decided to have all always inline early and drop bodies now, didn't you patch it that way this stage1? > > > > but of course IPA inline size estimates are a bit off since we are not > > going to do any optimization on the inlined body. > > We still do late ccp and other things, but indeed inline estimates > anticipate FRE to happen which it doesn't. IIRC the CCP was necessary for some odd reason I don't remember right now ;) > Looking into what passes are in the pipeline I also noticed that > we could also probably skip late modref from -Og optimization pipeline. Yes, I noticed it was there just now ... > (I think David added it htere originally since we do pure-const). > I am thinking about retiring pure-const from pure-const discovery next > stage1 since modref should be monotonosly stronger doing that (and > if we add a stripped down mode of modref it should not be more expensive > than pure-const)
