From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30038 invoked by alias); 21 Oct 2010 16:53:42 -0000 Received: (qmail 30019 invoked by uid 22791); 21 Oct 2010 16:53:38 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,MISSING_HEADERS,RCVD_IN_DNSWL_NONE,TW_FW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Oct 2010 16:53:31 +0000 Received: by qwe5 with SMTP id 5so3704613qwe.20 for ; Thu, 21 Oct 2010 09:53:29 -0700 (PDT) Received: by 10.229.223.149 with SMTP id ik21mr989557qcb.224.1287680008921; Thu, 21 Oct 2010 09:53:28 -0700 (PDT) Received: from yakj.usersys.redhat.com (nat-pool-brq-t.redhat.com [209.132.186.34]) by mx.google.com with ESMTPS id x9sm1599024qco.10.2010.10.21.09.53.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Oct 2010 09:53:27 -0700 (PDT) Message-ID: <4CC07005.9070601@gnu.org> Date: Thu, 21 Oct 2010 17:21:00 -0000 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100907 Fedora/3.1.3-1.fc13 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.3 MIME-Version: 1.0 CC: Andrew Pinski , Tom de Vries , gcc-patches@gcc.gnu.org, Bernd Schmidt Subject: Re: new sign/zero extension elimination pass References: <4CBC698B.3080204@codesourcery.com> <4CC014CC.20801@gnu.org> In-Reply-To: <4CC014CC.20801@gnu.org> Content-Type: text/plain; charset=UTF-8 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-10/txt/msg01852.txt.bz2 On 10/21/2010 12:24 PM, Paolo Bonzini wrote: > On 10/18/2010 05:42 PM, Andrew Pinski wrote: >>> > For MIPS, compilation results in the following insns. >>> > >>> > (set (reg/v:SI 199) >>> > (sign_extend:SI (subreg:HI (reg:SI 200) 2))) >>> > >>> > ... >>> > >>> > (set (reg:QI 203) >>> > (subreg:QI (reg/v:SI 199) 3)) >>> > >>> > These insns are the only def and the only use of reg 199, each >>> located in a >>> > different bb. >> >> This sounds like a job for GCSE to do. > > Actually, fwprop should _already_ do that if assuming simplify-rtx.c > does the simplification of (subreg:QI (sign_extend:SI (subreg:HI (reg:SI > 200) 2))) 3). ... which this code should do in simplify_subreg: /* Optimize SUBREG truncations of zero and sign extended values. */ if ((GET_CODE (op) == ZERO_EXTEND || GET_CODE (op) == SIGN_EXTEND) && GET_MODE_BITSIZE (outermode) < GET_MODE_BITSIZE (innermode)) { unsigned int bitpos = subreg_lsb_1 (outermode, innermode, byte); /* If we're requesting the lowpart of a zero or sign extension, there are three possibilities. If the outermode is the same as the origmode, we can omit both the extension and the subreg. If the outermode is not larger than the origmode, we can apply the truncation without the extension. Finally, if the outermode is larger than the origmode, but both are integer modes, we can just extend to the appropriate mode. */ if (bitpos == 0) { enum machine_mode origmode = GET_MODE (XEXP (op, 0)); if (outermode == origmode) return XEXP (op, 0); if (GET_MODE_BITSIZE (outermode) <= GET_MODE_BITSIZE (origmode)) return simplify_gen_subreg (outermode, XEXP (op, 0), origmode, subreg_lowpart_offset (outermode, origmode)); if (SCALAR_INT_MODE_P (outermode)) return simplify_gen_unary (GET_CODE (op), outermode, XEXP (op, 0), origmode); } However, the def of pseudo 200 is "complex enough" that fwprop will not want to propagate it unless it simplifies to a constant. It should be enough to tell fwprop that such propagations are always fine if the destination pseudo has one use only. In this case register pressure cannot increase. Paolo