AVR compiler that does a good job optimizing for size?

[ralphd]

My expectations that the new ipa optimizer in GCC 5 would generate code closer to hand-written assembler were in vain.  Here's one example of how avr-gcc does a terrible job:
https://gcc.gnu.org/ml/gcc/2015-04/msg00361.html

Has anyone tried avr-llvm?
https://github.com/avr-llvm/llvm

Is there any other free compiler for 8-bit AVR that does a better job than GCC?

[T3sl4co1l]

Does it go away with -O4 instead of Os?

Tim

[ralphd]

There is no -O4.

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

[andersm]

It's worth reporting those kinds of issues, or at least posting to the gcc-help mailing list.

[ralphd]

 Flash is cheap these days, most people just move up to the next device rather than spend a lot of money on a compiler to save 5-10%.

That doesn't help when you're trying to write code for millions of mega328's out there already.
I started writing 8-bit assembler over 30 years ago. It surprises me that compilers still can't match what a programmer can do in assembler after all this time.

[c4757p]

I started writing 8-bit assembler over 30 years ago. It surprises me that compilers still can't match what a programmer can do in assembler after all this time.

A massive amount of work for small benefit. They're good enough that it doesn't matter unless you're cycle-pinching (or if you're so phenomenally bad at C that it comes out shit but it's your fault), chips with enough power not to need cycle-pinching are cheap enough these days that most people don't have to bother, and any compiler that could achieve hand assembly levels of optimization would have to be so closely coupled to its platform that you'd be practically writing a new compiler for every chip.

The very few of us who need hand-assembly efficiency can still just write assembly by hand.

[engineer_in_shorts]

 Flash is cheap these days, most people just move up to the next device rather than spend a lot of money on a compiler to save 5-10%.

That doesn't help when you're trying to write code for millions of mega328's out there already.
I started writing 8-bit assembler over 30 years ago. It surprises me that compilers still can't match what a programmer can do in assembler after all this time.

Try IAR EWAVR

[ralphd]

I started writing 8-bit assembler over 30 years ago. It surprises me that compilers still can't match what a programmer can do in assembler after all this time.

any compiler that could achieve hand assembly levels of optimization would have to be so closely coupled to its platform that you'd be practically writing a new compiler for every chip.

When I've looked at GCC's x86 code, it's been pretty close to what I could write myself, so I doubt it's a matter of GCC's GIMPLE being too restrictive.  I suspect the real reason is the x86 (and probably ARM ) back-end gets more attention than the AVR back-end.

[ralphd]

 Flash is cheap these days, most people just move up to the next device rather than spend a lot of money on a compiler to save 5-10%.

That doesn't help when you're trying to write code for millions of mega328's out there already.
I started writing 8-bit assembler over 30 years ago. It surprises me that compilers still can't match what a programmer can do in assembler after all this time.

Try IAR EWAVR

I read in Avrfreaks where someone was using IAR and getting consistently bigger binaries than avr-gcc-4.3.  GCC-4.4 through 4.7 seemed to get worse for AVR code generation, but now 4.9.2 with lto generates even smaller code than 4.3.

[nuno]

There are a few simple things you can do in the program that will reduce code size. For example, have you set to "static" the functions and globals you don't use in more than one file?

[T3sl4co1l]

There is no -O4.

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Oops, -O3.

Shows how often I use GCC

Tim

[ralphd]

I suppose you have to consider that the AVR target doesn't get as much love as x86 from the developers, for obvious reasons. Also be wary of assuming that the compiler is being dumb, like that link you posted. Often it will create what looks like pointless code, until you find that some other bit of code jumps into the middle of it to save repartition of what follows.

If you want the GCC guys to improve a specific issue you should come up with a minimal test case. Just main() and as little code as possible to illustrate the problem.

*I* wrote the post on the gcc list.
Ive written a lot of asm and often can cut code size by 50% compared to C.
I re-wrote optiboot in asm and got it under 256 bytes, and still have room to add eeprom programming.
https://github.com/nerdralph/picoboot/tree/master/arduino

[Mechatrommer]

Flash is cheap these days, most people just move up to the next device rather than spend a lot of money on a compiler to save 5-10%.

That doesn't help when you're trying to write code for millions of mega328's out there already.
I started writing 8-bit assembler over 30 years ago. It surprises me that compilers still can't match what a programmer can do in assembler after all this time.

that doesnt help if you try to code Win8 GUI interface embedded system. assembly is good for efficient code, but simple application. once your application grows you'll start thinking twice. a compiler will never match hand tuned assembly because of generic contructs for the ease of programming. take few examples such as for...loop and if..endif, they are based on certain generic construct to satisfy all programming conditions, inevitably they take more than what "case by case" "hand tuned" assembly can make. i do assembly when it suits, and i do higher level language where it suits. each one with its own  pro and cons. mourning or nitpicking one way is better than the other will not help. i've made a little bit project to make pic and avr asm code portable between each other by bringing assembly a little bit higher (but still lower than most mainstream like c/vb/delphi et al), by making a giant (well not so giant, but can be expandable to giant for every programming needs, mine is only for myself) bunches of macros, some macros contructs for "loop" and "if" to make asm coding experience better for few variant of machines. i know what it takes, i dont develop a compiler or higher level language to full extents (heck hackers/makers/hobbiest/engineers dont develop compiler/parsers we have different purposes ), but i know what it takes, i encourage you to do the same if you want to get the idea cheers.

[nuno]

A pure C compiler will never be able to write as compact Assembly code as a good human programmer, simply because the C language wasn't designed to capture all the human's intentions; it doesn't know enough about the data ranges and usage, and other stuff. I've written two or three pretty compact projects for AVR using GCC in 99.9% C (sometimes a NOP or SLEEP comes handy). I usually look at the Assembly it generates and sometimes do some C code "re-ordering" that makes it generate more compact Assembly; from my experience, giving it a hand it does generate pretty compact code.

[ralphd]

It turns out to be a 5+ yr old bug.
gcc.gnu.org/PR41076

[mikeselectricstuff]

IAR is pretty good. It supports register variables for when you really need maximum speed.

However with any compiler, the best optimiser is the  user - you can do way more by carefully considering how you write the code than any compiler can ever hope to optimise well.

You also need to review the code that's being generated, if only by looking at the size of each function,  to see if there may be something that's not being done efficiently.

Also be very cautious about using any C library function (e.g. printf), as these will often include functionality that you don't need that can add huge overheads. 

[nuno]

IAR is pretty good. It supports register variables for when you really need maximum speed.

GCC does it also
https://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html

[Mechanical Menace]

No offence but why not use the 4.9.2 release when the 5 series is only a couple of weeks old and as always will need a couple of bug and regression fixes before it's on a par with earlier versions?

[ralphd]

No offence but why not use the 4.9.2 release when the 5 series is only a couple of weeks old and as always will need a couple of bug and regression fixes before it's on a par with earlier versions?

Why not read what I posted to the gcc list so you would know I tried 4.8, 4.9, and 5.0 and got the same code output?

[nuno]

I still use AVR-GCC 4.1.1, it also generates dumb code although not as much (this same code is generated with -Os, -O1, -O2 and -O3):

Code: [Select]

unsigned short f(unsigned char a, unsigned char b)
{
  4c: 99 27        eor r25, r25
  4e: 77 27        eor r23, r23
  50: 76 2f        mov r23, r22
  52: 66 27        eor r22, r22
    return a | (b << 8);
}
  54: 86 2b        or r24, r22
  56: 97 2b        or r25, r23
  58: 08 95        ret

[Mechanical Menace]

No offence but why not use the 4.9.2 release when the 5 series is only a couple of weeks old and as always will need a couple of bug and regression fixes before it's on a par with earlier versions?

Why not read what I posted to the gcc list so you would know I tried 4.8, 4.9, and 5.0 and got the same code output?

Because your posting to the mailing list made no mention of 4.9...

[ralphd]

No offence but why not use the 4.9.2 release when the 5 series is only a couple of weeks old and as always will need a couple of bug and regression fixes before it's on a par with earlier versions?

Why not read what I posted to the gcc list so you would know I tried 4.8, 4.9, and 5.0 and got the same code output?

Because your posting to the mailing list made no mention of 4.9...

Ok, sorry for the sarcasm then.
Although if you also look at the PR, you'll see that it's never been fixed, and therefore exists in 4.9.x.

[andersm]

Use -O1 in the compiler and -Os in the linker.

From the ld documentation:

At the moment this option only affects ELF shared library generation. Future releases of the linker may make more use of this option. Also currently there is no difference in the linker's behaviour for different non-zero values of this option. Again this may change with future releases.

Ie. -O will have no effect for statically linked binaries, as you would have when compiling for AVRs, and there is no -Os.

[westfw]

with any compiler, the best optimiser is the  user - you can do way more by carefully considering how you write the code than any compiler can ever hope to optimise well.

that's a nice theory, but once the optimizer gets "too smart", it can start adding extra code that you never wrote, for unclear reasons.
In fact, that was another one of RalphD's discoveries:  http://nerdralph.blogspot.com/2015/03/fastest-avr-software-spi-in-west.html
(discussed some more here: http://www.avrfreaks.net/forum/avr-gcc-creating-loop-counters-out-nothing-no-reason )
(tl/dr summary: gcc creates and manipulates a 16bit loop counter for the supposed-to-be clever "for(bit = 0x80; bit; bit >>= 1) {" loop.  Really annoying!)

Presumably the root cause of many of these issues is that the compiler does it optimizations at a level of abstraction makes assumptions about "costs" that are untrue for the 8bit AVR architecture. (which is, after all, pretty far from what gcc usually supports.)

[mikeselectricstuff]

with any compiler, the best optimiser is the  user - you can do way more by carefully considering how you write the code than any compiler can ever hope to optimise well.

that's a nice theory, but once the optimizer gets "too smart", it can start adding extra code that you never wrote, for unclear reasons.
In fact, that was another one of RalphD's discoveries:  http://nerdralph.blogspot.com/2015/03/fastest-avr-software-spi-in-west.html
(discussed some more here: http://www.avrfreaks.net/forum/avr-gcc-creating-loop-counters-out-nothing-no-reason )
(tl/dr summary: gcc creates and manipulates a 16bit loop counter for the supposed-to-be clever "for(bit = 0x80; bit; bit >>= 1) {" loop.  Really annoying!)

Presumably the root cause of many of these issues is that the compiler does it optimizations at a level of abstraction makes assumptions about "costs" that are untrue for the 8bit AVR architecture. (which is, after all, pretty far from what gcc usually supports.)

Exactly. And it isn't always the compiler - there are some things that arise from differences between the C language syntax and the CPU instruction set itself. e.g. if I do a<<=1;  the CPU generates a carry bit, but C can't make any use of it.
MCU-specific compilers like IAR are  likely to do a much better job than generic ones like GCC as they will be designed to have better visibility of the underlying instruction set.