Re: Non-optimal code generated for H8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux