From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25817 invoked by alias); 2 Aug 2011 12:36:29 -0000 Received: (qmail 25638 invoked by uid 22791); 2 Aug 2011 12:36:28 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 02 Aug 2011 12:35:57 +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 mo24) (RZmta 26.2) with ESMTPA id v00940n72BAFfX ; Tue, 2 Aug 2011 14:34:54 +0200 (MEST) Message-ID: <4E37EEEE.10401@gjlay.de> Date: Tue, 02 Aug 2011 12:36:00 -0000 From: Georg-Johann Lay User-Agent: Thunderbird 2.0.0.24 (X11/20100302) MIME-Version: 1.0 To: Richard Guenther CC: Mikael Pettersson , Michael Walle , Hans-Peter Nilsson , Richard Henderson , gcc@gcc.gnu.org Subject: Re: libgcc: strange optimization References: <201108012230.29989.michael@walle.cc> <4E371AC5.5090509@redhat.com> <20023.47611.116809.875356@pilspetsen.it.uu.se> <4E37CAFB.5010401@gjlay.de> <27466ae6b9a714679fcba410cce130ba.squirrel@ssl.serverraum.org> <20023.59456.782598.31450@pilspetsen.it.uu.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-08/txt/msg00045.txt.bz2 Richard Guenther wrote: > On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote: >> Michael Walle writes: >> > >> > Hi, >> > >> > > To confirm that try -fno-tree-ter. >> > >> > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working >> > assembly code: >> > >> > f2: >> > addi sp, sp, -4 >> > sw (sp+4), ra >> > addi r2, r0, 10 >> > calli __ashrsi3 >> > addi r8, r0, 10 >> > scall >> > lw ra, (sp+4) >> > addi sp, sp, 4 >> > b ra >> >> -fno-tree-ter also unbreaks the ARM test case in PR48863 comment #4. > > It's of course only a workaround, not a real fix as nothing prevents > other optimizers from performing the re-scheduling TER does. > > I suggest to amend the documentation for local call-clobbered register > variables to say that the only valid sequence using them is from a > non-inlinable function that contains only direct initializations of the > register variables from constants or parameters. > > Or go one step further and deprecate local register variables alltogether > (they IMHO don't make much sense, and rather the targets should provide > a way to properly constrain asm inputs and outputs). Strongly oppose. Local register variables are very useful; maybe not on a linux machine but on embedded systems there are situations you cannot do without. You ever counted the constraint alternatives that that would be needed? You'd need different constraints for QI/HI/SI/DI for each register resulting in myriads of register classes increasing register allocation time and dumps would become impossible to read. I once tried it for a target...never again. Besides that, with local register vars the developer can write code that meets his requirements, whereas for constraints you will always have to change the compiler and make existing sources incompatible. If GCC provides such a feature it must work properly and not be sacrifices for this or that optimization. Correct code is always preferred over non-functional code. Johann > > Richard. >