From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27242 invoked by alias); 8 Jan 2014 10:40:29 -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 27229 invoked by uid 89); 8 Jan 2014 10:40:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,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, 08 Jan 2014 10:40:28 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 16A12AC44; Wed, 8 Jan 2014 10:40:25 +0000 (UTC) Date: Wed, 08 Jan 2014 10:40:00 -0000 From: Richard Biener To: Kugan cc: Eric Botcazou , gcc-patches@gcc.gnu.org, "patches@linaro.org" Subject: Re: [PING^2][PATCH][2 of 2] RTL expansion for zero sign extension elimination with VRP In-Reply-To: <52CD0096.9010201@linaro.org> Message-ID: References: <51ABFC6E.30205@linaro.org> <1726629.C2vZH2NXuZ@polaris> <520B31F5.7020200@linaro.org> <52245B58.6090507@linaro.org> <5253B4FA.9090203@linaro.org> <525D153A.1030808@linaro.org> <525DDC09.9090509@linaro.org> <526761C7.1060007@linaro.org> <52A15162.40302@linaro.org> <52CBEC0D.4070706@linaro.org> <52CD0096.9010201@linaro.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2014-01/txt/msg00352.txt.bz2 On Wed, 8 Jan 2014, Kugan wrote: > > On 07/01/14 23:23, Richard Biener wrote: > > On Tue, 7 Jan 2014, Kugan wrote: > > [snip] > > > > Note that VIEW_CONVERT_EXPR is wrong here. I think you are > > handling this wrong still. From a quick look you want to avoid > > the actual promotion for > > > > reg_1 = .... > > > > when reg_1 is promoted and thus the target is (subreg:XX N). > > The RHS has been expanded in XXmode. Dependent on the value-range > > of reg_1 you want to set N to a paradoxical subreg of the expanded > > result. You can always do that if the reg is zero-extended > > and else if the MSB is not set for any of the values of reg_1. > > Thanks Richard for the explanation. I just want to double confirm I > understand you correctly before I attempt to fix it. So let me try this > for the following example, > > for a gimple stmt of the following from: > unsigned short _5; > short int _6; > _6 = (short int)_5; > > ;; _6 = (short int) _5; > target = (subreg/s/u:HI (reg:SI 110 [ D.4144 ]) 0) > temp = (subreg:HI (reg:SI 118) 0) > > So, I must generate the following if it satisfies the other conditions. > (set (reg:SI 110 [ D.4144 ]) (subreg:SI temp )) > > Is my understanding correct? I'm no RTL expert in this particular area but yes, I think so. Not sure what paradoxical subregs are valid, so somebody else should comment here. You could even generate (set (reg:SI 110) (reg:SI 118)) iff temp is a SUBREG of a promoted var, as you require that for the destination as well. > > > I don't see how is_assigned_exp_fit_type reflects this in any way. > > > > > What I tried doing with the patch is: > > (insn 13 12 0 (set (reg:SI 110 [ D.4144 ]) > (zero_extend:SI (subreg:HI (reg:SI 118) 0))) c5.c:8 -1 > (nil)) > > If the values in register (reg:SI 118) fits HI mode (without > overflowing), I assume that it is not necessary to just drop the higher > bits and zero_extend as done above and generate the following instead. > > (insn 13 12 0 (set (reg:SI 110 [ D.4144 ]) > (((reg:SI 118) 0))) c5.c:8 -1 > (nil)) > > is_assigned_exp_fit_type just checks if the range fits (in the above > case, the value in eg:SI 118 fits HI mode) and the checks before > emit_move_insn (SUBREG_REG (target), SUBREG_REG (temp)); checks the > modes match. > > Is this wrong or am I missing the whole point? is_assigned_exp_fit_type is weird - it looks at the value-range of _5, but as you want to elide the extension from _6 to SImode you want to look at the value-range from _5. So, breaking it down and applying the promotion to GIMPLE it would look like unsigned short _5; short int _6; _6 = (short int)_5; _6_7 = (int) _6; where you want to remove the last line representing the assignment to (subreg:HI (reg:SI 110)). Whether you can do that depends on the value-range of _6, not on the value-range of _5. It's also completely independent on the operation performed on the RHS. Well. As far as I understand at least. Richard.