From patchwork Wed Nov 14 23:08:52 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 199097 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 02B012C0081 for ; Thu, 15 Nov 2012 12:33:04 +1100 (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=1353547985; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=O/AXn2JLsjxRk5Z7Pn8M X1YXwRw=; b=q1ol6LXTJGMguZ7323fop+RRI3Cms7oL7KtvoWHRtab5iaUNWJmm /ndu+Hv1Pyw+uU4JyUJ+C9iyEx5IZ0Veubln4TBTzn7C2nVbnpBCjrUQDgSO0Z6x SF1PmlHo6KSA60Yj+NMUQh1bL+SwSRRUW9/qb3LT0F8Eg24kTll2Rt4= 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:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=qmqchVgPibVLUzxbreh2WecqEoUIiEJBh/q1BEuuzF3YjeaLusZvdXC9SdGqam Q8zDtfOn2ImBL8+96+kjrfMihKfuPFj/+J5y1gcELe0ljoJeEbQsm4sUxB7wuHiD u87Jnj49645NadYuZO8vDgvZ606DM5dk1JZvqJ51n6bpk=; Received: (qmail 1706 invoked by alias); 15 Nov 2012 01:33:00 -0000 Received: (qmail 1698 invoked by uid 22791); 15 Nov 2012 01:33:00 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Nov 2012 01:32:56 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAF1We6r017428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Nov 2012 20:32:56 -0500 Received: from zalov.redhat.com (vpn1-4-119.ams2.redhat.com [10.36.4.119]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qAEN8rB5032503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 18:08:55 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id qAEN8rLB028027; Thu, 15 Nov 2012 00:08:53 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id qAEN8q66028026; Thu, 15 Nov 2012 00:08:52 +0100 Date: Thu, 15 Nov 2012 00:08:52 +0100 From: Jakub Jelinek To: Uros Bizjak , Richard Henderson Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Restore i?86/x86_64 4.6 and earlier cmov behavior (PR target/54073) Message-ID: <20121114230852.GO1886@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 Hi! Before Richard Sandiford's 4.7 optab cleanups emit_conditional_move wasn't testing the predicate on the comparison, and apparently movcc patterns in i386.md can handle some comparisons that the current predicates on the expanders reject. This PR on MonteCarlo kernel shows a hardly predictable floating point UNLT comparison with SImode conditional increment, on which cmov improves things a lot. The following patch restores the 4.6 and earlier behavior, if movcc isn't able to handle the comparison, it will FAIL (except for the fallout discovered during the bootstrap/regtest, that floating point conditional move didn't check on i686 -m32 for DImode comparisons). If cmovs are undesirable on likely well predictable conditionals, we should reject it somewhere else, depending on the predictability of the conditionals, not based on whether the comparison is ordered or not. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2012-11-14 Jakub Jelinek PR target/54073 * config/i386/i386.md (movcc): Use comparison_operator instead of ordered_comparison_operator resp. ix86_fp_comparison_operator predicates. * config/i386/i386.c (ix86_expand_fp_movcc): Reject TImode or for -m32 DImode comparisons. Jakub --- gcc/config/i386/i386.md.jj 2012-11-13 16:46:04.859106102 +0100 +++ gcc/config/i386/i386.md 2012-11-14 20:31:24.440648957 +0100 @@ -16120,7 +16120,7 @@ (define_peephole2 (define_expand "movcc" [(set (match_operand:SWIM 0 "register_operand") - (if_then_else:SWIM (match_operand 1 "ordered_comparison_operator") + (if_then_else:SWIM (match_operand 1 "comparison_operator") (match_operand:SWIM 2 "") (match_operand:SWIM 3 "")))] "" @@ -16237,7 +16237,7 @@ (define_split (define_expand "movcc" [(set (match_operand:X87MODEF 0 "register_operand") (if_then_else:X87MODEF - (match_operand 1 "ix86_fp_comparison_operator") + (match_operand 1 "comparison_operator") (match_operand:X87MODEF 2 "register_operand") (match_operand:X87MODEF 3 "register_operand")))] "(TARGET_80387 && TARGET_CMOVE) --- gcc/config/i386/i386.c.jj 2012-11-14 20:26:37.000000000 +0100 +++ gcc/config/i386/i386.c 2012-11-14 20:45:54.304190855 +0100 @@ -19847,6 +19847,11 @@ ix86_expand_fp_movcc (rtx operands[]) return true; } + if (GET_MODE (op0) == TImode + || (GET_MODE (op0) == DImode + && !TARGET_64BIT)) + return false; + /* The floating point conditional move instructions don't directly support conditions resulting from a signed integer comparison. */