From patchwork Mon Oct 24 10:43:08 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kewen.Lin" X-Patchwork-Id: 8324 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp372012wru; Mon, 24 Oct 2022 03:44:15 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5fwV+1ZUkY1GLjNN2zeDHkWcyUy9bJ+5/NM7ntD+hlIAVgHIjvjA4GSCyokaprX1j+x+5c X-Received: by 2002:a17:907:a428:b0:78d:9fab:84fb with SMTP id sg40-20020a170907a42800b0078d9fab84fbmr25971885ejc.694.1666608255034; Mon, 24 Oct 2022 03:44:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666608255; cv=none; d=google.com; s=arc-20160816; b=E4f5UVqn8D+3jaONeOUFs5x6C1xvzPhPfKz86YPOpuZzy5eaCz5cZZ1Kfue+gaBgsk Tsej3vz5MqXjsTOb8IEhpnegTpJQtXOEuf08VeADrxKpEdsDhxujyhAzhlKXLw00fxCD /BhTVzq53zGYuFsPR9le1CoTr9+hpuRkP0bjW7qUKhfRmatMBdR85lMXxstA8VgjOGAm SdkA6ksEr4ZUJkq/buzF5pXt9Y0FQJGfKpekasGodZWTwB6s4XVtR7JM2SYscHGJGuKA ovPgGna3n8m9BEZL+evR/1tP0m0UHJW0EzWeVbTnbTEbRg0ch8avfR4HHbJ1U1n7S2Y7 vcWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:reply-to:from:list-subscribe:list-help :list-post:list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:subject:to:content-language:user-agent :mime-version:date:message-id:dmarc-filter:delivered-to :dkim-signature:dkim-filter; bh=MWMnF8WeTPPtCi0h89zeDXquEOEGcbj10qlpuhP9/ks=; b=luGIBrvhJ4uPxdhhJhdUvcIM9rVDA2hVk9CjKMrCud851GY1GUJ5RKL+xXLGpshcxX f6hYTuKpXJxHX0LvXGC8AqGZA8D1ayghsSxjZJCmGhJWRDNGbOQZDtT8vDq3GEEq/iFo P9etLY41noAVDf5cLZPrBR8t+KENuWcftmUe/YPDYuncGaJApNmweUObdI7AVXYXCcfL yqogVbio92KxeYf7pIIBP6dTn/bwHqbmY3Ya9OXhHK1mK4GH4CQkN07+gHJFxoWM8GYi DQBDAb2aR4Q8S6sotGfaWAyoBTNfFQNSy1M3kwIYUnPks0M+oMgYqgobqEyScYqnAXsD Gc1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=r7ros71M; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id fj3-20020a1709069c8300b00730ed690a72si31999181ejc.630.2022.10.24.03.44.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Oct 2022 03:44:15 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=r7ros71M; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B10F53858025 for ; Mon, 24 Oct 2022 10:44:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B10F53858025 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1666608253; bh=MWMnF8WeTPPtCi0h89zeDXquEOEGcbj10qlpuhP9/ks=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=r7ros71Md/El2AntrwSe3ELd84FL4J8qpurJXC9tM0d/vWLs8tf5FPCD6zjrzZkGE Q1hRpk/hGY2PXTlKdUoObkm8z3kFDUgKEbMd4xOCnzISGwEOGTVnOXApE6ruhDipTy wnCmCOF+ZRfwx4KbjiluFCRqdC2FgaimUxAiiDDM= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 8B0F33858421 for ; Mon, 24 Oct 2022 10:43:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8B0F33858421 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29OA8jbd013143; Mon, 24 Oct 2022 10:43:18 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3kdqvxam2w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Oct 2022 10:43:17 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 29OAV2JL017193; Mon, 24 Oct 2022 10:43:17 GMT Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3kdqvxam16-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Oct 2022 10:43:16 +0000 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 29OAbmfY021949; Mon, 24 Oct 2022 10:43:14 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma03ams.nl.ibm.com with ESMTP id 3kc85934ex-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Oct 2022 10:43:14 +0000 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 29OAhCNV64750030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 24 Oct 2022 10:43:12 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 910A54203F; Mon, 24 Oct 2022 10:43:12 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2197142041; Mon, 24 Oct 2022 10:43:10 +0000 (GMT) Received: from [9.197.233.191] (unknown [9.197.233.191]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 24 Oct 2022 10:43:09 +0000 (GMT) Message-ID: <95d598d7-4f00-ad36-08f9-4b5942e48e42@linux.ibm.com> Date: Mon, 24 Oct 2022 18:43:08 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: GCC Patches Subject: vect: Fix wrong shift_n after widening on BE [PR107338] X-TM-AS-GCONF: 00 X-Proofpoint-GUID: nRzX_A5k_cirH_gG-x9g5UyDou5ANXmh X-Proofpoint-ORIG-GUID: H1yo1ZjSYxzQmJJjhlsG_xH3vrwVk6r4 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-10-24_02,2022-10-21_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 lowpriorityscore=0 malwarescore=0 mlxscore=0 phishscore=0 bulkscore=0 mlxlogscore=999 impostorscore=0 adultscore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2210240063 X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: "Kewen.Lin via Gcc-patches" From: "Kewen.Lin" Reply-To: "Kewen.Lin" Cc: Richard Sandiford , Peter Bergner , Segher Boessenkool Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747565417922442571?= X-GMAIL-MSGID: =?utf-8?q?1747565417922442571?= Hi, As PR107338 shows, with the use of widening loads, the container_type can become a wider type, it causes us to get wrong shift_n since the BIT_FIELD_REF offset actually becomes bigger on BE. Taking the case in PR107338 as example, at the beginning the container type is short and BIT_FIELD_REF offset is 8 and size is 4, with unpacking to wider type int, the high 16 bits are zero, by viewing it as type int, its offset actually becomes to 24. So the shift_n should be 4 (32 - 24 - 4) instead of 20 (32 - 8 - 4). I noticed that if we move shift_n calculation early before the adjustments for widening loads (container type change), it's based on all the stuffs of the original container, the shfit_n calculated there is exactly what we want, it can be independent of widening. Besides, I add prec adjustment together with the current adjustments for widening loads, although prec's subsequent uses don't require this change for now, since the container type gets changed, we should keep the corresponding prec consistent. Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu, powerpc64-linux-gnu P7 and P8 and powerpc64le-linux-gnu P9 and P10. Is it ok for trunk? BR, Kewen ----- PR tree-optimization/107338 gcc/ChangeLog: * tree-vect-patterns.cc (vect_recog_bitfield_ref_pattern): Move shfit_n calculation before the adjustments for widening loads. --- gcc/tree-vect-patterns.cc | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) -- 2.35.4 diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc index 777ba2f5903..01094e8cb86 100644 --- a/gcc/tree-vect-patterns.cc +++ b/gcc/tree-vect-patterns.cc @@ -1925,6 +1925,16 @@ vect_recog_bitfield_ref_pattern (vec_info *vinfo, stmt_vec_info stmt_info, tree container_type = TREE_TYPE (container); tree vectype = get_vectype_for_scalar_type (vinfo, container_type); + /* Calculate shift_n before the adjustments for widening loads, otherwise + the container may change and we have to consider offset change for + widening loads on big endianness. The shift_n calculated here can be + independent of widening. */ + unsigned HOST_WIDE_INT shift_n = bit_field_offset (bf_ref).to_constant (); + unsigned HOST_WIDE_INT mask_width = bit_field_size (bf_ref).to_constant (); + unsigned HOST_WIDE_INT prec = tree_to_uhwi (TYPE_SIZE (container_type)); + if (BYTES_BIG_ENDIAN) + shift_n = prec - shift_n - mask_width; + /* We move the conversion earlier if the loaded type is smaller than the return type to enable the use of widening loads. */ if (TYPE_PRECISION (TREE_TYPE (container)) < TYPE_PRECISION (ret_type) @@ -1935,6 +1945,7 @@ vect_recog_bitfield_ref_pattern (vec_info *vinfo, stmt_vec_info stmt_info, NOP_EXPR, container); container = gimple_get_lhs (pattern_stmt); container_type = TREE_TYPE (container); + prec = tree_to_uhwi (TYPE_SIZE (container_type)); vectype = get_vectype_for_scalar_type (vinfo, container_type); append_pattern_def_seq (vinfo, stmt_info, pattern_stmt, vectype); } @@ -1953,12 +1964,6 @@ vect_recog_bitfield_ref_pattern (vec_info *vinfo, stmt_vec_info stmt_info, shift_first = false; } - unsigned HOST_WIDE_INT shift_n = bit_field_offset (bf_ref).to_constant (); - unsigned HOST_WIDE_INT mask_width = bit_field_size (bf_ref).to_constant (); - unsigned HOST_WIDE_INT prec = tree_to_uhwi (TYPE_SIZE (container_type)); - if (BYTES_BIG_ENDIAN) - shift_n = prec - shift_n - mask_width; - /* If we don't have to shift we only generate the mask, so just fix the code-path to shift_first. */ if (shift_n == 0)