From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21248 invoked by alias); 6 Jul 2011 18:00:04 -0000 Received: (qmail 21160 invoked by uid 22791); 6 Jul 2011 18:00:02 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,TW_SV X-Spam-Check-By: sourceware.org Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jul 2011 17:59:48 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGObUOFkj18odoYNahU4Q== X-RZG-CLASS-ID: mo00 Received: from [192.168.0.22] (business-188-111-022-002.static.arcor-ip.net [188.111.22.2]) by smtp.strato.de (klopstock mo46) (RZmta 26.0) with ESMTPA id D06e24n66Geqwi ; Wed, 6 Jul 2011 19:55:57 +0200 (MEST) Message-ID: <4E14A1AD.7010702@gjlay.de> Date: Wed, 06 Jul 2011 18:06:00 -0000 From: Georg-Johann Lay User-Agent: Thunderbird 2.0.0.24 (X11/20100302) MIME-Version: 1.0 To: Denis Chertykov CC: gcc-patches@gcc.gnu.org, Eric Weddington , Anatoly Sokolov Subject: Re: [Path,AVR]: Improve loading of 32-bit constants References: <4E144C61.60600@gjlay.de> <4E14859A.9010407@gjlay.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00380.txt.bz2 Denis Chertykov wrote: > 2011/7/6 Georg-Johann Lay : >> Denis Chertykov wrote: >>> 2011/7/6 Georg-Johann Lay : >>>> For loading a 32-bit constant in a register, there is room for >>>> improvement: >>>> >>>> * SF can be handled the same way as SI and therefore the patch >>>> adds a peep2 to produce a *reload_insf analogon to *reload_insi. >>>> >>>> * If the destination register overlaps NO_LD_REGS, values already >>>> loaded into some other byte can be reused by a simple MOV. >>>> This is helpful then moving values like, e.g. -2, -100 etc. because >>>> all high bytes are 0xff. >>>> >>>> * 0.0f can be directly moved to memory. >>>> >>>> * The mov insns contain "!d" constraint. I see no reason to make "d" >>>> expensive and discourage use of d-regs. A "*d" to hide is better >>>> because it does it neither puts additional pressure on "d" nor >>>> discourages "d". >>>> >>> I would like to have a real code examples. >>> >>> Denis. >> Hi Denis. >> >> Attached you find a small C file and the asm that is generated by new >> and old versions (-Os -mmcu=atmega88 -S -dp). >> >> I took away some regs as potential clobbers (or -fno-peephole2) to >> show the effect of high register pressure. Bit even if a clobber was >> available you can see that the new version is smarter in reusing >> values, e.g. note the loading of -1L to r22-r25. > > I have asked about example of *d instead of !d. > Just svn GCC with *d vs svn GCC !d. > > > Denis. Ah, I couldn't depict that from your question. I thought it could help in cases like these: long z; void inc (long y) { z += y; } that gets compiled with -Os to inc: push r16 push r17 /* prologue: function */ /* frame size = 0 */ /* stack size = 2 */ .L__stack_usage = 2 lds r16,z lds r17,z+1 lds r18,z+2 lds r19,z+3 add r16,r22 adc r17,r23 adc r18,r24 adc r19,r25 sts z,r16 sts z+1,r17 sts z+2,r18 sts z+3,r19 /* epilogue start */ pop r17 pop r16 ret But with the *d the code is still the same and R16 chosen instead of better R18. Maybe that's an IRA issue. Looking again at the "*d" resp. "!d", I think the alternative is superfluous because there is a "r" alternative and "d" is a subset of "r", so allocator can always switch to "r" if it does not like or see "d". I think we con remove that alternative, it's just confusing. Johann