From patchwork Mon Apr 30 12:54:05 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Uros Bizjak X-Patchwork-Id: 155859 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 4DB72B6FAC for ; Mon, 30 Apr 2012 22:54:24 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1336395265; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=DHqsSHiyc2KgkhN2ISEXzLadMcQ=; b=HotOGGzhT4fKeIfLQ4MSPK6eU6TxDS88fijooNFMmy4Ap0eSnPWeM1XpEU+xho JmBcgEa8xjOw7k4snTkerAbKjx5Sp6oJdC+J4xNd2dZILGA43OffkYhNAsharqQ0 xj40dHQptWtKQ5CcYAyPZDX0HehZSEVYLgxO3bxoOoSOk= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=NvOBTSOeDTfm57mFiAw0bxmxvtl9nTVJUh/cIcw1r6Gvg4qPEKZNIVnsfJp4ky F6F0o+AY4EpaaifbcztQsdpe8tUjrx2/EKGDgFx7Tz4qVSwZ7+yEslYcm/xNnRHZ hrlfTgDbcuDdf8VwD8w+oMooR9XG8Q6h+NSuiGf9KvCrQ=; Received: (qmail 4822 invoked by alias); 30 Apr 2012 12:54:21 -0000 Received: (qmail 4809 invoked by uid 22791); 30 Apr 2012 12:54:20 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, TW_XF, TW_ZJ X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Apr 2012 12:54:06 +0000 Received: by yenm3 with SMTP id m3so1342530yen.20 for ; Mon, 30 Apr 2012 05:54:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.108.199 with SMTP id q47mr21924777yhg.76.1335790445991; Mon, 30 Apr 2012 05:54:05 -0700 (PDT) Received: by 10.146.124.5 with HTTP; Mon, 30 Apr 2012 05:54:05 -0700 (PDT) In-Reply-To: References: <20120425191453.GX16117@tyan-ft48-01.lab.bos.redhat.com> <20120426152814.GB16117@tyan-ft48-01.lab.bos.redhat.com> Date: Mon, 30 Apr 2012 14:54:05 +0200 Message-ID: Subject: Re: [PATCH] Improve andq $0xffffffff, %reg handling (PR target/53110) From: Uros Bizjak To: Jakub Jelinek Cc: Richard Henderson , gcc-patches@gcc.gnu.org Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Thu, Apr 26, 2012 at 5:34 PM, Uros Bizjak wrote: > On Thu, Apr 26, 2012 at 5:28 PM, Jakub Jelinek wrote: > >>> > We have a splitter for reg1 = reg2 & 0xffffffff, but only if regnums >>> > are different.  But movl %edi, %edi is a cheaper variant of >>> > andq $0xffffffff, %rdi even with the same register and doesn't clobber >>> > flags, so this patch attempts to expand it as a zero extension early. >>> > >>> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >>> > >>> > 2012-04-25  Jakub Jelinek   >>> > >>> >        PR target/53110 >>> >        * config/i386/i386.md (and3): For andq $0xffffffff, reg >>> >        instead expand it as zero extension. >>> >>> Perhaps we can go all the way and also convert ANDs with $0xff and >>> $0xffff to relevant zero_extend patterns, like in the referred >>> splitter. >> >> I wasn't sure about 0xffff, on which CPUs it would be a win and on which it >> would not.  0xffffffff is a win always. It is always a win, especially when loading from memory. In the latter case, no execution units are used, only load (memory read) unit. > My recent changes to zero_extend expanders should handle this > automatically, and will undo generation of zero_extend pattern. Please > see zero_extendsi2_and expander, and how it handles > TARGET_ZERO_EXTEND_WITH_AND targets. Attached patch implements this idea. In addition, it fixes the splitter to not change output mode of zero_extension from HImode and QImode from DImode to SImode. Although they generate the same instruction, I think we should better keep original mode here. 2012-04-30 Uros Bizjak * config/i386/i386.md (and3): Expand masking operations with 0xff, 0xffff or 0xffffffff immediates to corresponding zero_extend RTX. (and splitter): Split to DImode zero_extend RTX for DImode operand[0]. Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN. Uros. Index: config/i386/i386.md =================================================================== --- config/i386/i386.md (revision 186954) +++ config/i386/i386.md (working copy) @@ -7695,14 +7695,45 @@ (match_operand:SWIM 2 "")))] "" { - if (mode == DImode - && GET_CODE (operands[2]) == CONST_INT - && INTVAL (operands[2]) == (HOST_WIDE_INT) 0xffffffff - && REG_P (operands[1])) - emit_insn (gen_zero_extendsidi2 (operands[0], - gen_lowpart (SImode, operands[1]))); + enum machine_mode mode = GET_MODE (operands[1]); + rtx (*insn) (rtx, rtx); + + if (CONST_INT_P (operands[2]) && REG_P (operands[0])) + { + HOST_WIDE_INT ival = INTVAL (operands[2]); + + if (ival == (HOST_WIDE_INT) 0xffffffff) + mode = SImode; + else if (ival == 0xffff) + mode = HImode; + else if (ival == 0xff) + mode = QImode; + } + + if (mode == GET_MODE (operands[1])) + { + ix86_expand_binary_operator (AND, mode, operands); + DONE; + } + + operands[1] = gen_lowpart (mode, operands[1]); + + if (GET_MODE (operands[0]) == DImode) + insn = (mode == SImode) + ? gen_zero_extendsidi2 + : (mode == HImode) + ? gen_zero_extendhidi2 + : gen_zero_extendqidi2; + else if (GET_MODE (operands[0]) == SImode) + insn = (mode == HImode) + ? gen_zero_extendhisi2 + : gen_zero_extendqisi2; + else if (GET_MODE (operands[0]) == HImode) + insn = gen_zero_extendqihi2; else - ix86_expand_binary_operator (AND, mode, operands); + gcc_unreachable (); + + emit_insn (insn (operands[0], operands[1])); DONE; }) @@ -7839,32 +7870,38 @@ && true_regnum (operands[0]) != true_regnum (operands[1])" [(const_int 0)] { + HOST_WIDE_INT ival = INTVAL (operands[2]); enum machine_mode mode; + rtx (*insn) (rtx, rtx); - if (INTVAL (operands[2]) == (HOST_WIDE_INT) 0xffffffff) + if (ival == (HOST_WIDE_INT) 0xffffffff) mode = SImode; - else if (INTVAL (operands[2]) == 0xffff) + else if (ival == 0xffff) mode = HImode; else { - gcc_assert (INTVAL (operands[2]) == 0xff); + gcc_assert (ival == 0xff); mode = QImode; } operands[1] = gen_lowpart (mode, operands[1]); - if (mode == SImode) - emit_insn (gen_zero_extendsidi2 (operands[0], operands[1])); + if (GET_MODE (operands[0]) == DImode) + insn = (mode == SImode) + ? gen_zero_extendsidi2 + : (mode == HImode) + ? gen_zero_extendhidi2 + : gen_zero_extendqidi2; else { - rtx (*insn) (rtx, rtx); - /* Zero extend to SImode to avoid partial register stalls. */ operands[0] = gen_lowpart (SImode, operands[0]); - insn = (mode == HImode) ? gen_zero_extendhisi2 : gen_zero_extendqisi2; - emit_insn (insn (operands[0], operands[1])); + insn = (mode == HImode) + ? gen_zero_extendhisi2 + : gen_zero_extendqisi2; } + emit_insn (insn (operands[0], operands[1])); DONE; })