py/py.mk: Build some core C files as single compilation units. #12714
Conversation
Allows the compiler to do some whole-of-source-file optimizations that aren't possible with -fgc-sections. This work was funded through GitHub Sponsors. Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
Code size report: |
Codecov Report
@@ Coverage Diff @@
## master #12714 +/- ##
=======================================
Coverage 98.39% 98.39%
=======================================
Files 158 158
Lines 20940 20953 +13
=======================================
+ Hits 20603 20616 +13
Misses 337 337 |
|
What caused the big increase in the minimal build? |
Fair question, @dlech! Some of the core files built as single units in this PR are are only partially linked to those builds (which makes sense as the minimal builds use less features.) When I figured out what to put in the Draft I was only looking at the linker map file for PYBV11. To make this work properly across ports and feature levels then it will need more to become more fine grained. For example, could remove some object files from the "build as single units" list entirely, or add some conditionals either in the Makefile or in the source files so the minimal builds don't end up growing. The question I have for now is whether that additional complexity and effort is worth the potential performance/size improvement, or if this is better left as an "interesting, probably not worth it" exercise. |
|
(I edited the last paragraph of the PR post to make that a bit clearer.) |
|
Closing this out for now, it seems like any improvement in size/performance is marginal and there would be a more noticeable increase in complexity to avoid code size increases for minimal build configs. |
(Reviewing #12644 reminded me that I meant to try this experiment.)
Motivation
Building some source files as single compilation units allows the compiler to do some whole-of-source-file optimizations that aren't possible with
-fgc-sections, or to emit slightly tighter assembly (even after linker relaxations are applied.)LTO provides very similar benefits, but is not enabled by default in most builds (and not possible at all for some ports like
esp32).Method
Looking at the "Discarded input sections" of firmware.map for a build with
-fgc-sectionsshows a lot of entries like this:From the above you can see that all symbols from
emitglue.owere linked to the final binary, but bothpersistentcode.oandruntime.ocontained symbols not referenced in the final binary that could be removed by the GC linker pass.Code Size
PYBV11 binary size (without cache):
py/directory was built without-ffunction-sections -fdata-sectionsPerformance
Performance of this PR versus master (cache disabled):
Remaining Work
Currently this is a quick PoC based on PYBV11 only. If the approach seems worthwhile, the next step would be to identify more closely which core files are always 100% linked to the build (or linked depending on make-level options). And/or the cases where some functions can be
#ifdef-ed out to make this true for a file.This work was funded through GitHub Sponsors.