> On Fri, Jun 25, 2010 at 06:10:56AM -0700, Jan Hubicka wrote: > > When you compile with -Os, the inlining happens only when code size reduces. > > Thus we pretty much care about the code size metrics only. I suspect the > > problem here might be that normal C++ code needs some inlining to make > > abstraction penalty go away. GCC -Os implementation is generally tuned for > > CSiBE and it is somewhat C centric (that makes sense for embedded world). > > As a > > result we might get quite noticeable slowdowns on C++ apps compiled with -Os > > (and code size growth too since abstraction is never eliminated). It can be > > seen also at tramp3d (Pooma testcase) where -Os produces a lot bigger and a > > lot > > slower code. > > One would think that in most of the abstraction-penalty cases, the inlined > code (often the direct reading or setting of a class data member) should > be both smaller and faster than the call, so -Os should inline. Perhaps
Yes at -Os inliner should inline to produce smallest binary. Problem is to figure out at inline time what the results of the inlining decisions will be. Inliner has no idea how the code will optimize if it does inlining or if it does not and often the code quality depends on multiple inline decisions (i.e. one needs to inline all methods of the object to make it to be scalar replaced and optimized away). Current herusitcs makes some simple guesses. Some of them are turned off for -Os to avoid regressions on C benchmarks in CSiBE. So I would really need to see individual examples to work out what can be done about them. Honza > there are cases where the inlined version is, say, one or two instructions > larger > than the version with a call, and this causes the degradation? If so, > maybe some heuristic could be produced that would inline anyway for > a small function?
