From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11333 invoked by alias); 18 Mar 2011 10:15:33 -0000 Received: (qmail 11323 invoked by uid 22791); 18 Mar 2011 10:15:32 -0000 X-SWARE-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_NUMERIC_HELO,SPF_HELO_PASS,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Mar 2011 10:15:27 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q0WiJ-0007Qf-QL for gcc@gcc.gnu.org; Fri, 18 Mar 2011 11:15:23 +0100 Received: from 193.128.72.68 ([193.128.72.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Mar 2011 11:15:23 +0100 Received: from pocmatos by 193.128.72.68 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Mar 2011 11:15:23 +0100 To: gcc@gcc.gnu.org From: "Paulo J. Matos" Subject: Re: avr compilation Date: Fri, 18 Mar 2011 10:15:00 -0000 Message-ID: References: <4D832F02.6080508@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 In-Reply-To: <4D832F02.6080508@gmail.com> X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg00253.txt.bz2 On 18/03/11 10:08, WANG.Jiong wrote: > This may related with subreg regmove finding > Suggest specifiy -fdump-rtl-regmove to see what happen after this pass > Maybe avr need a target dependent regmove pass to handle this > It doesn't look like it's regmove, whose result looks pretty sane: ;; Pred edge ENTRY [100.0%] (fallthru) (note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (note 2 3 5 2 NOTE_INSN_FUNCTION_BEG) (insn 5 2 6 2 add.c:5 (set (reg:HI 42) (mem/c/i:HI (symbol_ref:HI ("y") [flags 0x2] ) [2 y+0 S2 A8])) 8 {*movhi} (nil)) (insn 6 5 7 2 add.c:5 (set (reg:HI 44 [ x ]) (mem/c/i:HI (symbol_ref:HI ("x") [flags 0x2] ) [2 x+0 S2 A8])) 8 {*movhi} (nil)) (insn 7 6 25 2 add.c:5 (set (reg:HI 42) (plus:HI (reg:HI 42) (reg:HI 44 [ x ]))) 20 {*addhi3} (expr_list:REG_DEAD (reg:HI 44 [ x ]) (nil))) (insn 25 7 26 2 add.c:7 (set (reg:QI 24 r24) (subreg:QI (reg:HI 42) 0)) 4 {*movqi} (nil)) (insn 26 25 18 2 add.c:7 (set (reg:QI 25 r25 [+1 ]) (subreg:QI (reg:HI 42) 1)) 4 {*movqi} (expr_list:REG_DEAD (reg:HI 42) (nil))) (insn 18 26 0 2 add.c:7 (use (reg/i:HI 24 r24)) -1 (nil)) ;; End of basic block 2 -> ( 1) If psr 42 and 44 are allocated to the proper registers, i.e. 42 is allocated to the return registers insn 25/26 could be deleted, however, that's not what happens after register allocation: ;; Pred edge ENTRY [100.0%] (fallthru) (note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (note 2 3 5 2 NOTE_INSN_FUNCTION_BEG) (insn 5 2 6 2 add.c:5 (set (reg:HI 18 r18 [42]) (mem/c/i:HI (symbol_ref:HI ("y") [flags 0x2] ) [2 y+0 S2 A8])) 8 {*movhi} (nil)) (insn 6 5 7 2 add.c:5 (set (reg:HI 24 r24 [orig:44 x ] [44]) (mem/c/i:HI (symbol_ref:HI ("x") [flags 0x2] ) [2 x+0 S2 A8])) 8 {*movhi} (nil)) (insn 7 6 25 2 add.c:5 (set (reg:HI 18 r18 [42]) (plus:HI (reg:HI 18 r18 [42]) (reg:HI 24 r24 [orig:44 x ] [44]))) 20 {*addhi3} (nil)) (insn 25 7 26 2 add.c:7 (set (reg:QI 24 r24) (reg:QI 18 r18 [42])) 4 {*movqi} (nil)) (insn 26 25 18 2 add.c:7 (set (reg:QI 25 r25 [+1 ]) (reg:QI 19 r19 [+1 ])) 4 {*movqi} (nil)) (insn 18 26 27 2 add.c:7 (use (reg/i:HI 24 r24)) -1 (nil)) ;; End of basic block 2 -> ( 1) So, I guess it's probably something else... > > Best, > Jiong > > On 03/18/2011 04:47 PM, Paulo J. Matos wrote: >> Hi all, >> >> I am looking at the avr backend in order to try to sort some things >> out on my own backend. >> >> One of the tests I am doing is by compiling the following: >> int x = 0x1010; >> int y = 0x0101; >> >> int add(void) >> { >> return x+y; >> } >> >> It compiles to (in gcc-4.3.5_avr with -Os) >> add: >> /* prologue: function */ >> /* frame size = 0 */ >> lds r18,y >> lds r19,(y)+1 >> lds r24,x >> lds r25,(x)+1 >> add r18,r24 >> adc r19,r25 >> mov r24,r18 >> mov r25,r19 >> /* epilogue start */ >> ret >> >> I don't know much avr assembler so bear with me but I would expect >> this to be written: >> add: >> /* prologue: function */ >> /* frame size = 0 */ >> lds r18,y >> lds r19,(y)+1 >> lds r24,x >> lds r25,(x)+1 >> add r24,r18 >> adc r25,r19 >> /* epilogue start */ >> ret >> >> By inverting the add arguments we save two mov instructions. >> >> If it can be written like this any ideas on why GCC is avoiding it? >> >> Cheers, >> >> -- >> PMatos >> > >