Adjust `-finline-limit` so it does not cause problems

[dhalbert]

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.

[jerryneedell]

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]

@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]

I have a feeling the compiler doesn't understand the mechanic that is used to raise exceptions. Its pretty tricky so we may want to "poison" the core function with inline assembly so it doesn't disappear.

…

On Fri, Oct 13, 2017 at 7:00 AM Dan Halbert ***@***.***> wrote: @jerryneedell <https://github.com/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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#322 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADNqWsTZBE5OrUrHDvxxL0_zZtUDBXvks5sr20QgaJpZM4P37JK> .

[dhalbert]

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-limit at all, it's still over by a few hundred bytes. So I could bump -finline-limit back 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]

readelf, nm --print-size and firmware.elf.map have been helpful.

[dhalbert]

Rendered moot by #329. -finline-limit is not need at the moment, and we can probably keep it much higher than 19 now if we need to reinstate it.