Repository navigation
Adjust -finline-limit so it does not cause problems #322
Description
To make the image fit on non-Express boards, I set -finline-limit=19. This is too low. It apparently causes some routines to disappear completely with -flto.
One way to check is to see if deinit checking is working. Here is an example of it not working:
>>> import board,digitalio
>>> d = digitalio.Di
DigitalInOut Direction
>>> d = digitalio.DigitalInOut(board.D2)
>>> d.value
False
>>> d.deinit()
>>> d.value
False
The second d.value should throw an exception saying the value can no longer be used.
If we push -finline-limit up, the non-express board images may no longer fit. We'll have to figure out a different way of saving space.
Activity
jerryneedell commentedon Oct 13, 2017
Dan,
This is very troubling - the use of -finline-limit should only impact code size, not result in lost code. I am not familiar with -lto so I guess I should read up, but how can you be confident that code is not being lost in other cases? Just curious. Am I missing something?
Jerry
dhalbert commentedon Oct 13, 2017
@jerryneedell Exactly. No, I expect code may be broken elsewhere.Scott has seen different issues (exceptions were causing hard faults), so we can't tell where code is getting lost: I just have a reproducible example. I will try to figure out exactly what is going on. I am also going to look at removing a few more things from the non-Express builds so we can make them fit without -finline-limit. Another possibility is to reduce the 64k filesystem slightly, but we are reluctant to do that because it will break existing filesystems.
tannewt commentedon Oct 13, 2017
dhalbert commentedon Oct 13, 2017
That's a good point, because the deinit checking function raises an exception. I'll look at that.
I have been looking at trimming the non-Express builds. I can turn off complex floats, which I think nobody will miss, and get back 1576 bytes. With no
-finline-limitat all, it's still over by a few hundred bytes. So I could bump-finline-limitback up a lot.I don't see a lot else to remove immediately. Looking at the final .elf, I see that it includes double-precision float arithmetic routines (
__aeabi_dadd,dsub, etc.), which use up a few thousand bytes. I haven't been able to figure out who's actually calling these. It doesn't appear to be anything else. They may be included in the same library as the single-precision routines. I've found a few elf call-graph analyzers, but some of them are way overkill.dhalbert commentedon Oct 13, 2017
readelf,nm --print-sizeandfirmware.elf.maphave been helpful.dhalbert commentedon Oct 16, 2017
Rendered moot by #329.
-finline-limitis not need at the moment, and we can probably keep it much higher than 19 now if we need to reinstate it.