On 30/10/2019 23:49, Segher Boessenkool wrote: > On Wed, Oct 30, 2019 at 10:06:57AM +0100, David Brown wrote: >> But this also brings up another idea. Is the OP using "-Os" >> optimisation? My experience (especially with AVR, msp430, and ARM >> Cortex-M targets) is that "-Os" optimisation is often quite poor >> compared to "-O2". It can result in very significantly slower code for >> a saving of a couple of bytes, and in some cases the code can be >> significantly /bigger/ than with -O2. I don't know whether this is a >> backend issue, or a general problem with "-Os", but I no longer use or >> recommend "-Os" even for tiny embedded systems. > > I have done the same for many years now, on not so tiny systems as well: > if you want compact code, you use -O2, and tune both the code and the > compiler flags manually. Some of the --params are very useful. But do > not forget about tuning the code itself, that is where the biggest gains > are possible, always. (If a better solution is hard to come up with, > try finding a better problem, instead!) > Getting the smallest and fastest code from the compiler is always a bit of an artform - tweaking parameters or options, tweaking code arrangements, adding hints like "always_inline" attributes. No compiler can be expected to make the best choices at all times. But gcc generally does a fine job - it's rare that I need to do anything like this with gcc, but sometimes it is fun :-) (With some of the non-gcc compilers I have used, it is a necessity, and that's less fun.) I think there is a general attitude of "I'm compiling for a small microcontroller with only 32 KB flash - so I must use flags to make the code as small as possible". In fact, if you have 32 KB flash then you need to make your code at most 32 KB in size - code of 31 KB is just as good as code of 17 KB. As long as your code fits, any further reduction in size is unnecessary. > But if you have no time to waste, -Os usually give you smaller code than > -O2, even if some of the choices on the size <-> speed tradeoff are a bit > questionable (bug reports or patches welcome, of course!) And sometimes > -Os is unavoidably a bit bigger than -O2, it just sets *heuristics* after > all. But if you see this often (for some specific target?), please file > a PR for that as well. > I haven't reported any "-O2 smaller than -Os" bugs, as far as I can remember, but have merely noted it as a pattern that I see sometimes. I will try to keep an eye out for when I see it again. I have one bug report filed for an "-O2 slower than -Os" bug, the other direction. This was for ARM Cortex-M targets, which I filed at the "GNU Arm Embedded Toolchain" tracker. They are the main source of gcc toolchains for small-system ARM embedded development - in my business, it's important to have specific "toolchain releases" covering the compiler, library, and other tools. The folks running the project are quite good at fixing things or punting them upstream to the main gcc project, but like every other project bugs are reported faster than they can be handled! <https://bugs.launchpad.net/gcc-arm-embedded/+bug/1646883> Do you have any reference for the heuristic parameters set by -Os ? (I am perfectly happy with "it's in this file in the gcc source code", if that is the answer.) David
