-
Notifications
You must be signed in to change notification settings - Fork 3k
ARM toolchain: heap setup micro-optimisation #11701
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Locating and checking the length of the `ARM_LIB_HEAP` region is an extra task, when we're just interested in the base and limit. Looking at only those saves 8 bytes of ROM. More space could be saved if we ensured all targets had `ARM_LIB_HEAP`, removing the need for this run-time fallback code.
Having just done this, my "C standard paranoia" kicks in. According to the standard, all objects have distinct addresses, so the compiler would be within its rights to eliminate the test, and assume that the condition is true. Hmm. |
But then again, in the original version, all objects have non-null addresses, so the compiler could have optimised that out too. |
Ah, the WEAK attribute of course opens the door to any of them being null, so that effectively forces the compiler to deactivate any such optimisation normally applied to C objects. All good. |
CI started |
Tests will fail (iar license issue, investigating) |
Restarted failed jobs |
Test run: FAILEDSummary: 3 of 11 test jobs failed Failed test jobs:
|
CI restarted |
Test run: FAILEDSummary: 3 of 4 test jobs failed Failed test jobs:
|
CI restarted |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
Description
Locating and checking the length of the
ARM_LIB_HEAP
region is an extra task, when we're just interested in the base and limit. Looking at only those saves 8 bytes of ROM.More space could be saved if we ensured all targets had
ARM_LIB_HEAP
, removing the need for this run-time fallback code.Pull request type