|
From: | David Brown |
Subject: | Re: [avr-gcc-list] Question about generated asm |
Date: | Sat, 13 Aug 2016 18:04:13 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
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!)
[Prev in Thread] | Current Thread | [Next in Thread] |