From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127620 invoked by alias); 15 Jul 2015 12:57:59 -0000 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 Received: (qmail 127609 invoked by uid 89); 15 Jul 2015 12:57:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 15 Jul 2015 12:57:58 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D03FBAC5F; Wed, 15 Jul 2015 12:57:54 +0000 (UTC) Date: Wed, 15 Jul 2015 13:04:00 -0000 From: Michael Matz To: Richard Earnshaw cc: Richard Biener , Jim Wilson , Jeff Law , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH, ARM] stop changing signedness in PROMOTE_MODE In-Reply-To: <55A53519.6040305@foss.arm.com> Message-ID: References: <559BEB2D.7040800@redhat.com> <55A53519.6040305@foss.arm.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg01270.txt.bz2 Hi, On Tue, 14 Jul 2015, Richard Earnshaw wrote: > > I think it's a backend bug that parameters and locals are extended > > differently. The code in tree-outof-ssa was written with the > > assumption that the modes of RTL objects might be different (larger) > > than the tree types suggest, but that they be _consistent_, i.e. that > > the particular extension depends on only the types, not on the > > tree-type of the decl. > > We went through this a couple of weeks back. The backend documentation > for PROMOTE_MODE says: > > " For most machines, the macro definition does not change > @var{unsignedp}. However, some machines, have instructions that > preferentially handle either signed or unsigned quantities of certain > modes. For example, on the DEC Alpha, 32-bit loads from memory and > 32-bit add instructions sign-extend the result to 64 bits. On such > machines, set @var{unsignedp} according to which kind of extension is > more efficient." We aren't talking about what PROMOTE_MODE is or is not allowed, but about an inconsistency between what PROMOTE_MODE does and what target.promote_function_mode does. This is quite clearly a historic accident in the ARM port, namely that they extend parameters and locals in opposite ways, which originally wasn't even possible to describe in GCC. > So clearly it anticipates that all permitted extensions should work, and > in particular it makes no mention of this having to match some > abi-mandated promotions. That makes this a MI bug not a target one. All extensions do work just fine, except when the LHS and RHS of a copy instruction with the same types require different extension types depending on if the rhs is a PARM_DECL or not. It's also fundamental in gimple that copies can't change signedness, and this insonsistency breaks that assumption. Jim says that this is actually harmless in reality, because even a copy propagation will at most replace a use of a VAR_DECL with a PARM_DECL, and at the point of such use the other promotion would be added by expand. While the latter is true, I haven't really convinced myself that this really leads to correct code in all cases. Ciao, Michael.