From patchwork Mon Nov 21 12:36:47 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dominik Vogt X-Patchwork-Id: 697219 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3tMp5G45sTz9t3K for ; Mon, 21 Nov 2016 23:37:04 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="dRF5wxBa"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:reply-to:references:mime-version:content-type :in-reply-to:message-id; q=dns; s=default; b=PSYvxrJchKp1vEETCb8 DZhXUl6OoALTkGXXpTtYTuMFIfFyj48JSv7KwnJASzXtvh172RRq3AEKK291yXAb eK0bnW9xyiE1UXY8R6IJFfcRw8/4KdRhHC/d4S0wNwpyXme93sYclmyZ/jBaFFkh 40JVkHSjTtUeQR+7QUkdds88= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:reply-to:references:mime-version:content-type :in-reply-to:message-id; s=default; bh=62ZpkKQcaXlWYR5HmbXz9EN2E bc=; b=dRF5wxBaAVVwwsX8ymy4FbvSuYgoFG7QNwy5tnHBW1rpfLH9x2DIJSH+Y 9K6j9Q5hyHedjywAFAgugVnbSfOIwugVMoBuqoqWqJU7QABA+HQ+YJw/pxxUCcSZ p3/ngELTWKsdXHENIFLMwFYi0RnR2aryMswBI7NZpZzyh7LTT8= Received: (qmail 24640 invoked by alias); 21 Nov 2016 12:36:56 -0000 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 Received: (qmail 24625 invoked by uid 89); 21 Nov 2016 12:36:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, RCVD_IN_SEMBACKSCATTER autolearn=no version=3.3.2 spammy=2.3.0, sk:vogt@li, U*vogt, vogtlinuxvnetibmcom X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 21 Nov 2016 12:36:53 +0000 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uALCaFSc015405 for ; Mon, 21 Nov 2016 07:36:52 -0500 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0a-001b2d01.pphosted.com with ESMTP id 26uyg1cw01-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Nov 2016 07:36:51 -0500 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 21 Nov 2016 12:36:48 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 21 Nov 2016 12:36:46 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 6E4642190023; Mon, 21 Nov 2016 12:35:58 +0000 (GMT) Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uALCajYK24379588; Mon, 21 Nov 2016 12:36:45 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4E6CC52036; Mon, 21 Nov 2016 11:35:33 +0000 (GMT) Received: from oc5510024614.ibm.com (unknown [9.145.13.207]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id D550552041; Mon, 21 Nov 2016 11:35:32 +0000 (GMT) Received: by oc5510024614.ibm.com (Postfix, from userid 500) id F35BC1A967; Mon, 21 Nov 2016 13:36:47 +0100 (CET) Date: Mon, 21 Nov 2016 13:36:47 +0100 From: Dominik Vogt To: Bernd Schmidt , gcc-patches@gcc.gnu.org, Andreas Krebbel , Ulrich Weigand Subject: Re: [PATCH] Do not simplify "(and (reg) (const bit))" to if_then_else. Reply-To: vogt@linux.vnet.ibm.com Mail-Followup-To: vogt@linux.vnet.ibm.com, Bernd Schmidt , gcc-patches@gcc.gnu.org, Andreas Krebbel , Ulrich Weigand References: <20161031195610.GA3558@linux.vnet.ibm.com> <4c9dd4a4-9f4f-048c-67d5-8ace6bd6eb8c@redhat.com> <20161111111028.GA30873@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20161111111028.GA30873@linux.vnet.ibm.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16112112-0016-0000-0000-0000026879CD X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16112112-0017-0000-0000-000023E0EC3C Message-Id: <20161121123647.GA22233@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-21_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611210225 On Fri, Nov 11, 2016 at 12:10:28PM +0100, Dominik Vogt wrote: > On Mon, Nov 07, 2016 at 09:29:26PM +0100, Bernd Schmidt wrote: > > On 10/31/2016 08:56 PM, Dominik Vogt wrote: > > > > >combine_simplify_rtx() tries to replace rtx expressions with just two > > >possible values with an experession that uses if_then_else: > > > > > > (if_then_else (condition) (value1) (value2)) > > > > > >If the original expression is e.g. > > > > > > (and (reg) (const_int 2)) > > > > I'm not convinced that if_then_else_cond is the right place to do > > this. That function is designed to answer the question of whether an > > rtx has exactly one of two values and under which condition; I feel > > it should continue to work this way. > > > > Maybe simplify_ternary_expression needs to be taught to deal with this case? > > But simplify_ternary_expression isn't called with the following > test program (only tried it on s390x): > > void bar(int, int); > int foo(int a, int *b) > { > if (a) > bar(0, *b & 2); > return *b; > } > > combine_simplify_rtx() is called with > > (sign_extend:DI (and:SI (reg:SI 61) (const_int 2))) > > In the switch it calls simplify_unary_operation(), which return > NULL. The next thing it does is call if_then_else_cond(), and > that calls itself with the sign_extend peeled off: > > (and:SI (reg:SI 61) (const_int 2)) > > takes the "BINARY_P (x)" path and returns false. The problem > exists only if the (and ...) is wrapped in ..._extend, i.e. the > ondition dealing with (and ...) directly can be removed from the > patch. > > So, all recursive calls to if_then_els_cond() return false, and > finally the condition in > > else if (HWI_COMPUTABLE_MODE_P (mode) > && pow2p_hwi (nz = nonzero_bits (x, mode)) > > is true. > > Thus, if if_then_else_cond should remain unchanged, the only place > to fix this would be after the call to if_then_else_cond() in > combine_simplify_rtx(). Actually, there already is some special > case handling to override the return code of if_then_else_cond(): > > cond = if_then_else_cond (x, &true_rtx, &false_rtx); > if (cond != 0 > /* If everything is a comparison, what we have is highly unlikely > to be simpler, so don't use it. */ > ---> && ! (COMPARISON_P (x) > && (COMPARISON_P (true_rtx) || COMPARISON_P (false_rtx)))) > { > rtx cop1 = const0_rtx; > enum rtx_code cond_code = simplify_comparison (NE, &cond, &cop1); > > ---> if (cond_code == NE && COMPARISON_P (cond)) > return x; > ... > > Should be easy to duplicate the test in the if-body, if that is > what you prefer: > > ... > if (HWI_COMPUTABLE_MODE_P (GET_MODE (x)) > && pow2p_hwi (nz = nonzero_bits (x, GET_MODE (x))) > && ! ((code == SIGN_EXTEND || code == ZERO_EXTEND) > && GET_CODE (XEXP (x, 0)) == AND > && CONST_INT_P (XEXP (XEXP (x, 0), 0)) > && UINTVAL (XEXP (XEXP (x, 0), 0)) == nz)) > return x; > > (untested) Updated and tested version of the patch attached. The extra logic is now in combine_simplify_rtx. Ciao Dominik ^_^ ^_^ diff --git a/gcc/combine.c b/gcc/combine.c index b22a274..457fe8a 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -5575,10 +5575,23 @@ combine_simplify_rtx (rtx x, machine_mode op0_mode, int in_dest, { rtx cop1 = const0_rtx; enum rtx_code cond_code = simplify_comparison (NE, &cond, &cop1); + unsigned HOST_WIDE_INT nz; if (cond_code == NE && COMPARISON_P (cond)) return x; + /* If the operation is an AND wrapped in a SIGN_EXTEND or ZERO_EXTEND + with either operand being just a constant single bit value, do + nothing since IF_THEN_ELSE is likely to increase the expression's + complexity. */ + if (HWI_COMPUTABLE_MODE_P (mode) + && pow2p_hwi (nz = nonzero_bits (x, mode)) + && ! ((code == SIGN_EXTEND || code == ZERO_EXTEND) + && GET_CODE (XEXP (x, 0)) == AND + && CONST_INT_P (XEXP (XEXP (x, 0), 0)) + && UINTVAL (XEXP (XEXP (x, 0), 0)) == nz)) + return x; + /* Simplify the alternative arms; this may collapse the true and false arms to store-flag values. Be careful to use copy_rtx here since true_rtx or false_rtx might share RTL with x as a