From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27838 invoked by alias); 8 Jun 2010 21:44:08 -0000 Received: (qmail 27826 invoked by uid 22791); 8 Jun 2010 21:44:07 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Jun 2010 21:44:03 +0000 Received: (qmail 20459 invoked from network); 8 Jun 2010 21:44:01 -0000 Received: from unknown (HELO ?84.152.236.246?) (bernds@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Jun 2010 21:44:01 -0000 Message-ID: <4C0EB9A5.6080907@codesourcery.com> Date: Tue, 08 Jun 2010 21:56:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100425 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eric Botcazou CC: gcc-patches@gcc.gnu.org, Paolo Bonzini , Andrew Pinski Subject: Re: Patch: PR40900, extending call patterns References: <4BDA2513.9000705@codesourcery.com> <201005010054.17350.ebotcazou@adacore.com> <4BDE99BF.2030303@codesourcery.com> <201005051458.39945.ebotcazou@adacore.com> In-Reply-To: <201005051458.39945.ebotcazou@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2010-06/txt/msg00830.txt.bz2 On 05/05/2010 02:58 PM, Eric Botcazou wrote: >> Seems to be because it's a signed operation, and arm has >> >> #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \ >> if (GET_MODE_CLASS (MODE) == MODE_INT \ >> && GET_MODE_SIZE (MODE) < 4) \ >> { \ >> if (MODE == QImode) \ >> UNSIGNEDP = 1; \ >> else if (MODE == HImode) \ >> UNSIGNEDP = 1; \ >> (MODE) = SImode; \ >> } >> >> while ppc doesn't modify UNSIGNEDP. > > Can't we be clever during RTL expansion and avoid blindly zero-extending the > value when we known that > > D.2014_1 = shortv2 (); > > and promote_function_mode sign-extends? The kind of extension for a specific > variable can be changed since the SUBREG_PROMOTED_* machinery records it. In > other words, can't we just override promote_decl_mode in the SSA_NAME case of > expand_expr_real_1? I've looked into this now, and I don't really see a way to do better at rtl expansion time. In current sources, the function ends up as D.2006_1 = shortv2 (); [tail call] return D.2006_1; PROMOTE_MODE ensures that D.2006_1 becomes #0 store_expr (exp=0xf7cbb5e8, target=0xf7d2c5ac, call_param_p=0, nontemporal=0 '\000') at ../../trunk/gcc/expr.c:4582 4582 rtx inner_target = 0; (gdb) p target(gdb) p debug_rtx (target) (subreg/s/u:HI (reg:SI 133 [ D.2006 ]) 0) We create zero-extensions around the CALL_EXPR in store_expr and call expand_expr. At some point, in expand_call, we create a signed target: (subreg/s:HI (reg:SI 136) 0) which is returned from expand_call. This value then gets zero extended due to the NOP_EXPRs around the call which were previously created in store_expr. The zero extension makes it into initial RTL but is quickly deleted as useless. The value returned by the call to expand_expr in store_expr is simply (reg:SI 133), with no hint that there was a sign-extended promoted subreg available anywhere. Later, during expand_return, we create the superfluous sign extension. This seems unavoidable since a) what we return is D.2006_1, i.e. a subreg of reg 133, so we no longer see the subreg created by expand_call, and b) even if we did see it, it had its SUBREG_PROMOTED_VAR_P flag deleted anyway by this code in expand_expr_real_2: /* If the signedness of the conversion differs and OP0 is a promoted SUBREG, clear that indication since we now have to do the proper extension. */ if (TYPE_UNSIGNED (TREE_TYPE (treeop0)) != unsignedp && GET_CODE (op0) == SUBREG) SUBREG_PROMOTED_VAR_P (op0) = 0; I see no obvious place in this sequence of events where we could have done anything better, and I'm doubtful that arbitrarily ignoring the choice made by PROMOTE_MODE at any point would be a good idea. In light of this, is my previous combiner patch OK? Bernd