------- Comment #11 from j at uriah dot heep dot sax dot de 2007-02-21 19:32 ------- (In reply to comment #9)
> I don't see that adding a hook to provide target specific tuning for > size estimates at this level is going to be useful enough to justify > maintenance cost of such code. Sadly inlining heuristics is one of > the most important and least informed parts of optimization queue. Well, for the AVR, it's rare you could see a size benefit for almost any function that is called more than once. As most AVR users are concerned about size (rather than speed), it would probably even make sense to allow for a backend flag that tells the middle-end to never try inlining unless it is really only called once. (In reply to comment #10) > So, ehm... What do the asm dumps for AVR look like? Can you attach > them, so we know what we're talking about here? Yes, will do. Arguably, it's only very few instructions for this fairly simple test case, but I've been trying to construct a simplified case that is even completely target independent (so all the GCC folks who don't know the AVR don't have to care for things like AVR inline assembly statements or such). In real-world code, I've seen more pessimistic results out of this kind of inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
