From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121377 invoked by alias); 8 Jul 2015 22:54:23 -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 121368 invoked by uid 89); 8 Jul 2015 22:54:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 08 Jul 2015 22:54:21 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 63C0BC9B0A; Wed, 8 Jul 2015 22:54:20 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-49.phx2.redhat.com [10.3.113.49]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t68MsJLZ032607; Wed, 8 Jul 2015 18:54:20 -0400 Message-ID: <559DAA34.10707@redhat.com> Date: Wed, 08 Jul 2015 22:54:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jim Wilson CC: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH, ARM] stop changing signedness in PROMOTE_MODE References: <559BEB2D.7040800@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00662.txt.bz2 On 07/07/2015 10:29 AM, Jim Wilson wrote: > > My years at Cisco didn't give me a chance to work on the SSA passes, > so I don't know much about how they work. But looking at this, I see > that PHI nodes are eventually handed by emit_partition_copy in > tree-outof-ssa.c, which calls convert_to_mode, so it appears that > conversions between different (closely related?) types are OK in a PHI > node. It'd be real interesting to see if that call ever does any real conversions -- ie, is it ever called with types that are not useless type conversions (useless_type_conversion_p has essentially become the definition of the gimple type system, for better or worse). This is critically important as various parts of the compiler will take a degenerate PHI node and propagate the RHS of the PHI into the uses of the LHS of the PHI -- without doing any conversions. So if you had something like X = PHI (Y); Where X is a sub-word local and Y is a sub-word parameter, the propagators will blindly replace uses of X with Y, which may be wrong if I understand your next paragraph correctly. The problem in this case is that we have the exact same type > for the src and dest. The only difference is that the ARM forces > sign-extension for signed sub-word parameters and zero-extension for > signed sub-word locals. Thus to detect the need for a conversion, you > have to have the decls, and we don't have them here. There is also > the problem that all of the SUBREG_PROMOTED_* stuff is in expand_expr > and friends, which aren't used by the cfglayout/tree-outof-ssa.c code > for PHI nodes. So we need to copy some of the SUBREG_PROMOTED_* > handling into cfglyout/tree-outof-ssa, or modify them to call > expand_expr for PHI nodes, and I haven't had any luck getting that to > work yet. I still need to learn more about the code to figure out if > this is possible. And this would seem to imply that those objects can't be set/referenced in the same PHI because of the zero vs sign extension issue. > > I haven't looked at trying to forbid the optimizer from creating PHI > nodes connecting parameters to locals. That just sounds like a > strange thing to forbid, and seems likely to result in worse code by > disabling too many optimizations. But maybe it is the right solution > if neither of the other two options work. This should only be done > when PROMOTE_MODE disagrees with TARGET_PROMOTE_FUNCTION_MODE, forcing > the copy to require a conversion. It's less about connecting parameters to locals and more about ensuring that objects connected are close enough in their types that one could be substituted for the other. jeff