public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: Sylvain Leroux <sylvain@chicoree.fr>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Optimizing 32 bits integer manipulation on 8 bit AVR target
Date: Fri, 31 Aug 2012 11:51:00 -0000	[thread overview]
Message-ID: <503FAB40.301@hesbynett.no> (raw)
In-Reply-To: <503F6507.6050901@chicoree.fr>

Two points:

avr-gcc is known to produce poor code for a number of 32-bit operations. 
  You can search the bugzilla database for missed optimisations like 
this, in case this particular usage is not already listed (even if the 
avr-gcc porters have limited time to work on such things, they still 
like them to be recorded as bugs).  As a general rule, 32-bit operations 
are not used much on the 8-bit avr, and thus improving the generated 
code is not the highest priority for the developers.

Secondly, why are you worrying about portability for code that is 
clearly avr-specific?  Writing portable code is often a useful aim, but 
when you have code that is tightly tied to particular hardware, there is 
no need to be portable.  This is particularly true for the avr, with its 
separate memory space for flash data - a lot of avr code will not 
compile directly on other architectures (or even on other avr 
compilers).  Thus there is no problem with your second version.


You don't mention what optimisation settings you tried - certainly gcc 
will generate terrible code if you don't have at least -O.  The most 
common settings for avr-gcc are -Os.

One setting that often affects 32-bit code on the avr is 
-fsplit-wide-types.  For some code, you get better results with this 
enabled, but at other times it is best to disable it 
(-fno-split-wide-types).


You may also like to join the avr specific list at
avr-gcc-list@nongnu.org.

mvh.,

David



On 30/08/12 15:05, Sylvain Leroux wrote:
> As a complement to my previous message,
>
> It appears the following C source leads to much better code:
>
> ---------8<-----------------------------------
> void f(uint32_t i) {
> union __attribute__((__packed__)) {
> uint32_t i;
> struct S { uint8_t a,b,c,d; } s;
> } u;
>
> u.i = i | ((uint32_t)(0xFF) << 16);
>
> DDRA = (uint32_t)(u.s.d);
> DDRA = (uint32_t)(u.s.c);
> DDRA = (uint32_t)(u.s.b);
> DDRA = (uint32_t)(u.s.a);
> }
> ---------8<-----------------------------------
>
> avr-objdump:
> ---------8<-----------------------------------
> union __attribute__((__packed__)) {
> uint32_t i;
> struct S { uint8_t a,b,c,d; } s;
> } u;
>
> u.i = i | ((uint32_t)(0xFF) << 16);
> 58: af 6f ori r26, 0xFF ; 255
>
> DDRA = (uint32_t)(u.s.d);
> 5a: ba bb out 0x1a, r27 ; 26
> DDRA = (uint32_t)(u.s.c);
> 5c: aa bb out 0x1a, r26 ; 26
> DDRA = (uint32_t)(u.s.b);
> 5e: 9a bb out 0x1a, r25 ; 26
> DDRA = (uint32_t)(u.s.a);
> 60: 8a bb out 0x1a, r24 ; 26
> ---------8<-----------------------------------
>
> *But*, the C code is no longer portable since I'm using
> "__attribute__((__packed__))". Moreover it requires endianness
> knowledge/assumption.
>
>
> That's why I was hoping for a command line option allowing gcc to
> perform the same optimization.
>
> - Sylvain
>
>
> On 08/30/2012 02:54 PM, Sylvain Leroux wrote:
>> Hi,
>>
>> It seems to me that avr-gcc/avr-g++ is producing sub-optimal code for
>> the 'f' function in the following source code:
>>
>> ---------8<-----------------------------------
>> #include <avr/io.h>
>>
>> void f(uint32_t i) {
>> i |= ((uint32_t)(0xFF) << 16);
>>
>> /* DDRA is an 8 bit register */
>> DDRA = (uint32_t)(i);
>> DDRA = (uint32_t)(i>>8);
>> DDRA = (uint32_t)(i>>16);
>> DDRA = (uint32_t)(i>>24);
>> }
>>
>> int main() {
>> volatile uint32_t n = 0x01020304;
>>
>> f(n);
>> }
>> ---------8<-----------------------------------
>> Having compiled with the following options:
>> avr-gcc c.c -mmcu=attiny2313
>> -Os -ffunction-sections -fdata-sections
>> -g -Wl,--gc-sections -Wl,--print-gc-sections
>> -fipa-cp -fcprop-registers -fweb
>>
>> ... here is the relevant fragment as displayed by avr-objdump. I marked
>> with a star (*) all the instruction that appears to be useless:
>> ---------8<-----------------------------------
>> void f(uint32_t i) {
>> i |= ((uint32_t)(0xFF) << 16);
>> 34: 8f 6f ori r24, 0xFF ; 255
>>
>> DDRA = (uint32_t)(i);
>> 36: 6a bb out 0x1a, r22 ; 26
>> DDRA = (uint32_t)(i>>8);
>> 38: 27 2f mov r18, r23
>> * 3a: 38 2f mov r19, r24
>> * 3c: 49 2f mov r20, r25
>> * 3e: 55 27 eor r21, r21
>> 40: 2a bb out 0x1a, r18 ; 26
>> DDRA = (uint32_t)(i>>16);
>> 42: 9c 01 movw r18, r24
>> * 44: 44 27 eor r20, r20
>> * 46: 55 27 eor r21, r21
>> 48: 2a bb out 0x1a, r18 ; 26
>> DDRA = (uint32_t)(i>>24);
>> 4a: 69 2f mov r22, r25
>> * 4c: 77 27 eor r23, r23
>> * 4e: 88 27 eor r24, r24
>> * 50: 99 27 eor r25, r25
>> 52: 6a bb out 0x1a, r22 ; 26
>> }
>> 54: 08 95 ret
>> ---------8<-----------------------------------
>>
>> Both gcc and g++ produce the same code. And I get the same results both
>> with 4.3.5 and 4.7.1
>>
>> Here is my question:
>> Is there any option(s) that will help gcc to not produce those extra
>> instructions in such case?
>>
>>
>> Regards,
>> - Sylvain
>>
>>
>>
>
>

  reply	other threads:[~2012-08-30 18:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-30 15:32 Sylvain Leroux
2012-08-30 18:05 ` Sylvain Leroux
2012-08-31 11:51   ` David Brown [this message]
2012-08-31 22:37 ` Georg-Johann Lay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=503FAB40.301@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=gcc-help@gcc.gnu.org \
    --cc=sylvain@chicoree.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).