search

MarlinFirmware / U8glib-HAL

Customized U8glib for use in Marlin 2.0
Other
45 stars 33 forks source link

Remove explicit U8G_NOINLINE. #25

Closed ramiropolla closed 3 years ago

ramiropolla commented 3 years ago

The compiler is usually smarter than us when choosing what to inline or not, especially when -flto is used.

This saves 384 bytes of program memory on my Anet A6.

thinkyhead commented 3 years ago

Another straightforward optimization, thanks!

Do you happen to know a compiler flag to get it to automatically combine strings, including allowing overlaps? For example, if you have a "CATALOG\0" string and a "LOG\0" string, the compiler could just emit the bytes "CATALOG\0". I did some experiments a while ago, and I seem to remember the compiler emitted a lot of duplicate strings.

ramiropolla commented 3 years ago

Another straightforward optimization, thanks!

Do you happen to know a compiler flag to get it to automatically combine strings, including allowing overlaps? For example, if you have a "CATALOG\0" string and a "LOG\0" string, the compiler could just emit the bytes "CATALOG\0". I did some experiments a while ago, and I seem to remember the compiler emitted a lot of duplicate strings.

Do you have a real use-case from Marlin about this you could point me to?

For normal strings, GCC is smart enough to merge and deduplicate them. It seems to work even for strings declared with PROGMEM. It did fail at optimising PSTR() strings though. I found this forum that kind of figured out how to merge and deduplicate PSTR() strings but it doesn't work out-of-the-box on Marlin because of macros: https://forum.arduino.cc/t/pstr-flash-string-de-duplication-a-problem-a-solution-and-a-question/189661

Also I did a quick check on Marlin to look for duplicated strings on progmem and I found these: G28 Probing Failed Z Probe Past Bed

I'll leave it up to you to find a way to optimise them :)

thinkyhead commented 3 years ago

Thank you for the note. I added a bunch of pre-defined common PROGMEM strings to Marlin 'encourage' the compiler to only make a single copy, but maybe that won't be needed in the long run. I'd rather use PSTR("G28") than G28_STR any day. So, I'll do another round of experiments at some point to see whether that extra work was ever truly needed.

In future, it might be nice to move parts of Marlin into the libs folder and let them compile down to separate units for a smaller linker line at the end. I've already tried making one libs item and it was very easy to set up, but I am slightly concerned that the compiler will be even less able to optimize things -like duplicated strings- under that scheme.