Consider const_float_t obsolete

[thinkyhead]

Since AVR has 16-bit pointers some calls and code size may be optimized using a const float& instead of a const float. Whether this makes a big difference in practice is yet to be widely tested, but this PR applies const_float_t for consistency anyway.

[ellensp]

"makes a bug difference" foreshadowing?

[thinkyhead]

foreshadowing

The cogent exploration here is whether const float & is still helpful with the most recent AVR compilers.

The old advice was that function calls are faster/smaller because it only requires 2 bytes on AVR to pass a float or long by reference, whereas passing by value requires 4 bytes. However, in order to pass a float literal by reference, the compiler must first create temporary storage, presumably outside of PROGMEM, or it may sometimes need to generate two distinct functions - one taking a value and the other taking a reference, whereas a literal passed by value can simply be embedded in the program code.

In testing the difference tonight, the code size is 90 bytes smaller using the const_float_t on AVR for the default build, but for some other builds the code size can be hundreds of bytes larger than const float. Is that due to hidden polymorphism, or due to some other factor?

An isolated test shows no apparent code size difference when passing by value or by reference, but I have not yet looked at the assembler output to compare the difference in the resulting assembler code.

If the AVR compiler has become smarter and can find the best balance of faster/smaller then the const_xxxx_t types can go away, and we can just use const float on all targets without worry. So this would be an interesting thing for Marlin contributors to look into so that we have a definite answer.