From patchwork Fri Dec 9 15:23:44 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dominik Vogt X-Patchwork-Id: 704599 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 3tZwxd4xHhz9t15 for ; Sat, 10 Dec 2016 02:24:03 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="u2MbL3VN"; 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:cc:subject:reply-to:mime-version:content-type :message-id; q=dns; s=default; b=K7STeiPsYMlDfSxvcAVms5IINFJWsqk nsDCkI16nzd9mgCB+t5h6p5nKsNfzpvJgAKwy/3ESMNB+VLPJJBSa9PJ4Dof/PZL RgN5xh2P2NWQEZ6VvWuIgDe98iQi/NTsKcpq5bEB8NFX30CueeqS+PdcvjetlawI zK+UxdwVfU3I= 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:cc:subject:reply-to:mime-version:content-type :message-id; s=default; bh=buMSO2pjW+FHBEDJDEok9cZYKi8=; b=u2MbL 3VNcTlhgLtyppeDWZNVvw4FL63tVCYtUhOuAbHVQTzPW46DzzHOVFZNppRMx5L27 kGxZhxtIVN3dLMH+vJkwzDhra9oDKE39gTOhwZ5iwp8RxF8AA9LF/tQBQukL37g3 TxysmymE4E6Qkhq19i52gbB5KoHq2ZXmzJsLU4= Received: (qmail 82159 invoked by alias); 9 Dec 2016 15:23:54 -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 82150 invoked by uid 89); 9 Dec 2016 15:23:54 -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= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Dec 2016 15:23:51 +0000 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uB9FJo0L054368 for ; Fri, 9 Dec 2016 10:23:50 -0500 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0b-001b2d01.pphosted.com with ESMTP id 277wsnnpqq-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 09 Dec 2016 10:23:49 -0500 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 9 Dec 2016 15:23:48 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 9 Dec 2016 15:23:46 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id D2E352190061; Fri, 9 Dec 2016 15:22:55 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uB9FNjD040501254; Fri, 9 Dec 2016 15:23:45 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 295554204B; Fri, 9 Dec 2016 14:21:52 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 87B7942042; Fri, 9 Dec 2016 14:21:51 +0000 (GMT) Received: from oc5510024614.ibm.com (unknown [9.145.32.189]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 9 Dec 2016 14:21:51 +0000 (GMT) Received: by oc5510024614.ibm.com (Postfix, from userid 500) id 8909A1AA2A; Fri, 9 Dec 2016 16:23:44 +0100 (CET) Date: Fri, 9 Dec 2016 16:23:44 +0100 From: Dominik Vogt To: gcc-patches@gcc.gnu.org Cc: segher@kernel.crashing.org Subject: [RFC] combine: Improve change_zero_ext, call simplify_set afterwards. Reply-To: vogt@linux.vnet.ibm.com Mail-Followup-To: vogt@linux.vnet.ibm.com, gcc-patches@gcc.gnu.org, segher@kernel.crashing.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16120915-0020-0000-0000-00000290E306 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16120915-0021-0000-0000-00003F5B0815 Message-Id: <20161209152344.GA22030@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-09_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612090213 There are several situations that combine.c:change_zero_ext does not handle well yet. One of them is (and:SI (subreg:SI (zero_extract:DI (reg:DI) ...) ...) (with const_int operands to "and" and "zero_extract") => (and:SI (subreg:SI (and:DI (lshiftrt:DI ...))) with two nested "and"s. Another one is (zero_extract:DI (foo:SI) ...) which is ignored by change_zero_ext. Attached are two experimental patches: 0001-* Deal with mode expanding zero_extracts in change_zero_ext. The patch looks good to me, but not sure whether endianness is handled properly. Is the second argument of gen_rtx_SUBREG correct? 0002-* This is a work in progress with the goal of fixing the first problem and similar ones by calling simplify_set after change_zero_ext to get rid of the overly complex code. That works fine in principle, but replaces back the (and (lshiftrt ...) ...) that change_zero_ext generates back into zero_extract form. Fiddling with simplify_set and make_compound_operation* a bit, trying to suppress undoing the transformations that change_zero_ext has just done, resulted in the (unfinished) patch. As it's not clear to me whether this is a valid approach I'd appreciate any advice on the patch or alternative ways of doing that. Ciao Dominik ^_^ ^_^ diff --git a/gcc/combine.c b/gcc/combine.c index b429453..e14a08f 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -11237,18 +11237,24 @@ change_zero_ext (rtx pat) if (GET_CODE (x) == ZERO_EXTRACT && CONST_INT_P (XEXP (x, 1)) && CONST_INT_P (XEXP (x, 2)) - && GET_MODE (XEXP (x, 0)) == mode) + && (GET_MODE (XEXP (x, 0)) == mode + || GET_MODE_PRECISION (GET_MODE (XEXP (x, 0))) + < GET_MODE_PRECISION (mode))) { + machine_mode inner_mode = GET_MODE (XEXP (x, 0)); + size = INTVAL (XEXP (x, 1)); int start = INTVAL (XEXP (x, 2)); if (BITS_BIG_ENDIAN) - start = GET_MODE_PRECISION (mode) - size - start; + start = GET_MODE_PRECISION (inner_mode) - size - start; if (start) - x = gen_rtx_LSHIFTRT (mode, XEXP (x, 0), GEN_INT (start)); + x = gen_rtx_LSHIFTRT (inner_mode, XEXP (x, 0), GEN_INT (start)); else x = XEXP (x, 0); + if (mode != inner_mode) + x = gen_rtx_SUBREG (mode, x, 0); } else if (GET_CODE (x) == ZERO_EXTEND && SCALAR_INT_MODE_P (mode)