As Steven Bosscher wrote: > And now that you've shown that for this test case GCC actually may > have regressed on every target, you've shown that perhaps the global > inlining heuristics should be changed. May well be, for all I know. > Tuning heuristics is always hard and never provably optimal.
I accept that. To me, it appears as if GCC is currently incorrectly computing the costs for the inlining for very small functions. Users of the AVR target are particularly affected by that because obviously, their usage pattern frequently contains that kind of short functions, which are now being inlined though that is increasing the actual costs. > It shows so for this particular test case, but that does not count > as proof that the flag always causes increased code size for every > test case. When it was decided to inline at -Os, this was done > because there was proof that overall (for CSiBE) it resulted in > smaller binaries. Then, this is rather a proof to me that CSiBE does not expose the case of very small functions well enough. For the AVR users, we are probably happy if the target code can be tuned enough to get a less aggressive inlining, and I think users of large machines wouldn't care too much about a wasted byte of code or two unless it is their typical usage pattern. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
