Link time optimization doesn't work #9
Comments
|
In platform.txt change: to: |
|
Is this something that should be done with the other cores as well? This fix works perfectly with IDE 1.6.12, but I get this error message when trying with 1.6.5 and 1.6.9: Any ideas on how to get it working with older versions as well? |
|
This is how SpenceKonde did it in ATTinyCore: I would think it would be best to do this with all the cores that you add LTO support to since that's what Arduino AVR Boards did. I don't fully understand the difference between the two. There's some information here: arduino/Arduino#660 (comment) |
|
hmm. I can make it work with IDE 1.6.5 and 1.6.12, but not at the same time. When I choose these boards.txt settings, and add however, with this boards.txt configuration I get this error with the LTO option enabled: If I change the LTO like to this (and just leave the platform.txt like it is): it compiles without errors in IDE 1.6.5, but the I get the huge error from the frist post with IDE 1.6.12. Is it really possible to make it work on both versions? |
|
Using that modification to platform.txt and boards.txt I can successfully use either the Tools > GCC flags > -Os -flto(default) or the Tools > GCC flags > -Os options with IDE 1.6.12/Arduino AVR Boards 1.6.14. With IDE 1.6.5/AVR Boards 1.6.8 I can successfully use Tools > GCC flags > -Os but not Tools > GCC flags > -Os -flto(default). These are the results I'd expect as the AVR-GCC 4.8.1 included with AVR Boards 1.6.8 doesn't support LTO. I can successfully use either option with IDE 1.6.5 and AVR Boards 1.6.14. Are these the results you're getting? On a side note, after thinking about it more I'm not actually crazy about the |
That's the exact same result as I'm getting with IDE 1.6.5 and Boards 1.6.8. The problem is that boards 1.6.14 doesn't ship with IDE 1.6.5, so the user will have to manually replace the platform.txt file in order to use anything less than IDE 1.6.10.
Hmm. Is it true that GCC 4.8.1 doesn't support LTO? If I use
I agree. I just copied the line from ATTinyCore. I'll add the full command name to the boards.txt file instead. It doesn't need to be confusing just because it works! |
That was my understanding previously but after reading arduino/Arduino#660 more closely it sounds it does support it but possibly with some issues. It seems like there has to be some connection between the upgrade to AVR-GCC 4.9.2 and the LTO compiler flags being added to Arduino AVR Boards at the same time. If I try to compile with the I don't find liblto_plugin-0.dll included with Arduino's avr-gcc 4.8.1. I do find it included with Arduino's avr-gcc 4.9.2. Maybe that's what's referred to at arduino/Arduino#660 (comment) (I'm using Windows):
If I copy liblto_plugin-0.dll from avr-gcc 4.9.2 to 4.8.1 then I get the If I try to compile with the I don't know what file or directory it's referring to. So that means I'm getting a different result than you, probably because we're on different operating systems. I remember even with AVR-GCC 4.9.2 they had to try a couple times to build it correctly to support LTO on Windows. I'm happy to test out other configurations if you want, just let me know. Another option would be to include an AVR-GCC tool with MiniCore so that you will always have control of which version is used, as discussed for AVRDUDE in MCUdude/MightyCore#32. Of course that requires the extra complication of including AVR-GCC with the manual installation and needing a different installation file for each operating system, etc. You could also just explain in the readme that the LTO options require IDE 1.6.11 or newer or AVR Boards 1.6.13 or newer and make them non-default but that's unfortunate for people using older versions and may also lead to support requests from people who didn't read your documentation. |
|
Backwards compatibility is a pain! I think the best option right now is to make -Os the default , and make the -flto another option. I'll document this well in the readme file, so nobody can blame me 😉 About the GCC compiler; the latest IDE is including 4.9.2. Why aren't we running GCC 5 or 6? Are there any reason why we shouldn't use newer versions? |
I think Arduino tends to prefer stable well tested over cutting edge. There are builds of 5.1.0 and 6.1 available from arduino/Arduino#660 so they certainly were considered. I've been using 6.1.0 for some bootloader builds lately, just because that's what the other developer is using and have experienced no problems. I just use the standard tool versions with the Arduino IDE so that I can better reproduce the experience of the standard user. Another advantage of having your own avr-gcc tool would be to offer the users of your cores the latest tool versions but it does seem like some work to get the builds right for all operating systems. |
|
How large will the core become (in MB) with GCC compiled for Windows, macOS and Linux? It's certainly an option, I'm tired of not having full control when a new IDE is released. |
|
avr-gcc 4.9.2-atmel3.5.3-arduino2 for Windows is 154 MB unzipped, 42 MB zipped. If you use the option of providing operating specific manual installation files with each release then the user will only have to download/install/store the avr-gcc build for their OS, not all of them. The correct tool version for the users OS will be automatically installed by Boards Manager. |
|
I think most users are using the boards manager option, but I want the manual installation to work as well. I'm no Github expert, but maybe there should exist three releases, one for each operating system. Can Github fix this automatically, or do I need to generate the ZIP file myself? |
|
The only way I can think of to do three releases for each release would be to base each one on a different branch, one branch for each operating system. The hardware folders of all the branches would be synced and the tools folder of the branch would contain the operating system specific build of avr-gcc. The other possibility, which I like better, would be to do a single release from the master branch and then use the release webhook((https://developer.github.com/v3/activity/events/types/#releaseevent)) to trigger a script that automatically generates the operating system manual installation zip files and then attaches them to the release(https://developer.github.com/v3/repos/releases/#upload-a-release-asset). That seems like it will make for a cleaner/easier to manage(because less branches) and much smaller(because it doesn't need to include avr-gcc) repository. That same script could also assemble the Boards Manager installation file and update the JSON file. |
This definitely sounds like the best way. I think MiniCore might be the the best core to start with. It's not "mature", and isn't nearly as popular (yet) as the other two. I'd love some help with this, so you're welcome to help if you want to! |
|
I don't have any experience with this sort of thing(beyond Windows batch files 😛) so if any script wizards end up reading this I'm sure we'd appreciate some help and would probably eventually be able to adapt it to the other cores. There's a good start at the Boards Manager part of the script here: https://github.com/Optiboot/optiboot/blob/master/optiboot/release.sh. I'll keep my eye out for other repositories that do something similar to the release script triggered by webhook that we could use as a reference. Of course I'm happy to keep doing the Boards Manager thing manually. I can put together the manual installation release files too. I can't add files to releases via pull request but I could upload them to a branch of my fork and add links to them in the boards manager release pull request description. The script would be an improvement in the long term because it will less prone to mistakes once it's working correctly. |
|
If it's easier for you to test and debug, I can always give you admin rights to this core! |
|
I appreciate your confidence in me. I think I could do just about anything from a fork but will let you know. The script would run on a server so it would only need to to be written for linux, the webhook causes a payload with the release information to be sent to a URL on that server. There's a general overview of GitHub webhooks here: https://developer.github.com/v3/repos/hooks |
9108614 Fix issue with PWM on pin D2 with 328PB This kinda ugly fix is necessary to get PWM working properly when using timer3b or timer4b on ATmega328PB. It's strange, but the PWM functionality gets disabled when PORTD bit 2 is set to zero 2245d4c Merge branch 'master' of https://github.com/MCUdude/MCUdude_corefiles 47ce3a3 Add support for the new *PB variants 903e61b Merge pull request #9 from per1234/test-mightycore 9df002b Update MightyCore core folder name 75464f9 Fix typos in .travis.yml comments a4026bc Update README.md 090c9de Merge pull request #8 from per1234/test-minicore 6c244c7 Merge pull request #7 from per1234/fix-travis ea9f095 Test against MiniCore 57a3c9a Update MajorCore core folder name in .travis.yml git-subtree-dir: avr/cores/MCUdude_corefiles git-subtree-split: 91086148c25fc02bc148374ed180ead001b2d9d7
After Arduino IDE 1.6.10 was released, the GCC link time optimization (-flto) is enabled by default. This reduces the sketch size dramatically, while not making the code smaller. I'm planning to add a separate GCC flags menu to MightyCore, MegaCore and MiniCore, and so far this is a success on MegaCore and MightyCore. When adding the GCC flags menu with the option -Os -flto I get this error. The error does not occur in IDE 1.6.9, but does with 1.6.12. How can I get this working? The current boards.txt file is attached for testing purposes.
boards.txt
The text was updated successfully, but these errors were encountered: