[avr-gcc-list] avr-gcc making really bad inlining decisions.

[Bill Westfield]

Historically, from the avr-gcc 4.3.2 compiler used in Arduino, though
several intermediate versions, the compiler has become more and more
aggressive about in-lining "small" functions, and has done an
increasingly bad job of detecting "small" on AVRs (perhaps it bases
its decisions on "intermediate code" size rather actual code size.)
This is even in the presence of "-Os" compile instructions.  (getting
optiboot to fit in 512 bytes with newer compilers has meant chasing
optimization switches and eventually adding
"__attribute__((noinline))" for ... everything.


But a particularly awful example has just surfaced, apparently related
to the use of floating point.

The following not-very-complex sketch compiles to about 12k with 4.3.2
(Arduino 1.0.6), and bloats to over 44k with 4.8.x (Arduino 1.6.2)
This is because the compiler is in-lining calls to "move3Servos(Servo
servo1Name, float target_pos1,Servo servo2Name, float
target_pos2,Servo servo3Name, float target_pos3,float easing)" and
similar, and it ends up NOT being a very small function (over 1k)


http://forum.arduino.cc/index.php?action=dlattach;topic=314062.0;attach=121538
http://forum.arduino.cc/index.php?topic=314062


Is there anything that can be done about this?  (preferably short of
specifying a bunch of obscure special-purpose optimization switches.
Perhaps like giving the compiler some per-architecture guess at the
average internal->final instruction mapping efficiency?)