Re: [avr-gcc-list] Question about generated asm

[David Brown]

On 13/08/16 03:40, Eric Tang wrote:
> Hi avr-gcc mailing list,
>
> I have a question about the asm generated for C code that sequentially
> checks the bits of an integer in a loop. From what I can gather, during
> each iteration of the loop, the integer is shifted right until the bit
> to be checked becomes the least significant bit of its least significant
> byte, at which point that bit is checked. This seems to be the case both
> when the loop index counts up and when it counts down. I am wondering
> why the shifting starts over every time, and if it would be better to
> retain the shifted result and shift it one bit more every iteration of
> the loop or to maintain a mask which is used in an AND operation with
> the integer and shifted one bit more during every iteration of the loop?

It looks like a missed optimisation opportunity here.  What version of 
avr-gcc have you got, and what optimisation options are you using? 
Unless you have the latest compiler version and are using either -O2 or 
-Os, it s not worth complaining about something like this.  (I don't 
have a recent version on hand to test it.)

In general, avr-gcc has cases with sub-optimal code, especially when C 
integer promotion means that what looks like 8-bit arithmetic is 
actually 16-bit.  In many situations, avr-gcc's optimisers can fix 
improve things - but in other situations, it can't.  Newer versions of 
the compiler are better then older ones, but these kinds of 
optimisations are very specific to the avr, and thus only handled by the 
over-worked avr port developers.  Cases like this, where you can easily 
do the optimisation "manually" (as suggested by Russell), are lower 
priority than ones that affect more common code.

But if your compiler is up to date, then you can file a "missed 
optimisation" bug.  It might not get fixed in the near future, but it 
won't be forgotten.


(Try compiling with -O3 - it gives an interesting alternative solution!)