Re: [avr-gcc-list] Missing compiler optimizations?

[Erik Walthinsen]

Nigel Winterbottom wrote:
> Watch out. Registers (r18-r27, r30-r31) ARE trashable by any function.
> Because you call "bootloader_eeprom_read_byte", that too is allowed to
> trash these registers. You cannot use (r18-r27, r30-r31) for variables
> which "live" across a function call, unless of course you "push/pop" around
> that function call.
That's true, but the compiler could use the high registers and save them 
with the same or slightly more push/pops around the called functions, 
and gain the ability to use the various instructions that only operate 
on high registers.  Perhaps that's too large of a scale of optimization 
though, as it depends on number and position of calls, and overall 
register usage (e.g. some of the function-clobbered registers are only 
needed *before* the calls, etc.).

> Incorrect. Only Y (r28/r29) is saved.
No, I said "caller", not "called".  r28/r29 are the only registers that 
the "called" function are required to save (of the top 4 pairs).

> Try this macro:
>
> #define HILOTO16(hi, lo) ({ \
> unsigned int __result; \
> __asm__ ( " mov %B0,%1 \n" : "=r" (__result) : "r" (hi), "0" (lo) ); \
> __result; })
>
> e.g.  w = HILOTO16(c, b);
>
> This gives optimal code and should cause a different compiler to complain,
> thereby highlighting the non portability.
Yeah, I can do that kind of stuff, but it's not really the point. 
Merging bytes into a word is one of quite a number of common programming 
idioms (esp. embedded) that I've seen gcc make hash of, so I want to see 
if there's a way to peephole match more of them and inject better code.