From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id DEB3F3858D33 for ; Thu, 9 Mar 2023 09:31:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DEB3F3858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 329939D5007038; Thu, 9 Mar 2023 09:31:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=IuIZjPSq1LeOqPE/2lmixFYT7RgpyQSVWkf5aCFdtDw=; b=f2wpJPfHai7Ee5kcXODbVU9NtXAsoUSW6JqMxrx6ev6I+EMv+qn+vTK/wA5RgNbzQ1J0 ONYUUK7T0A3kC+rjA12aNFHwrN12s9AxyKGFC+q2g+15qP3TwLUws/ARQZZNGe7/Ia64 dh4pDGeQ4i/f11StZwpY2r3wr02R7LUMcGVfXIDhO1Gz3IIhCchbHx9//VWhtOdBXQQc 3WMMez8o+ucOKFAmrGOQquCOHqCVoVgDfIxzKeNhbYY+9GgfHzzcJQVw1C9YpSjpSjEO fqz2JN+KOOxjITdyOeWxULHm/jq6Pto5Uq1yvgjLMJqD7f0QGFY4JKqAbQDWpkevBkC+ 7A== Received: from ppma05fra.de.ibm.com (6c.4a.5195.ip4.static.sl-reverse.com [149.81.74.108]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3p6s9awvak-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Mar 2023 09:31:02 +0000 Received: from pps.filterd (ppma05fra.de.ibm.com [127.0.0.1]) by ppma05fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 328I4heJ015869; Thu, 9 Mar 2023 09:31:00 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma05fra.de.ibm.com (PPS) with ESMTPS id 3p6g759j1g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Mar 2023 09:30:59 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3299Uv5e47120792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Mar 2023 09:30:57 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2739E2004F; Thu, 9 Mar 2023 09:30:57 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 64A6B2004D; Thu, 9 Mar 2023 09:30:55 +0000 (GMT) Received: from [9.197.245.177] (unknown [9.197.245.177]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 9 Mar 2023 09:30:54 +0000 (GMT) Message-ID: Date: Thu, 9 Mar 2023 17:30:53 +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 Subject: Re: [PATCH] rs6000: Accept const pointer operands for MMA builtins [PR109073] Content-Language: en-US To: Peter Bergner Cc: Segher Boessenkool , Chip Kerchner , GCC Patches References: <40ecb0c8-2821-a72b-549d-6de6876b5d45@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: <40ecb0c8-2821-a72b-549d-6de6876b5d45@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: daIztlgor1qm-U85HfwV2R2fQswqYr7I X-Proofpoint-GUID: daIztlgor1qm-U85HfwV2R2fQswqYr7I X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-03-09_05,2023-03-08_03,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 bulkscore=0 phishscore=0 clxscore=1015 impostorscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 mlxscore=0 spamscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2303090072 X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,NICE_REPLY_A,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 List-Id: Hi Peter, on 2023/3/9 07:01, Peter Bergner via Gcc-patches wrote: > PR109073 shows a problem where GCC 11 and GCC 10 do not accept a const > __vector_pair pointer operand to some MMA builtins, which GCC 12 and later > correctly accept. Fixed here by initializing the builtins to accept const > pointers. > > This patch was tested in both GCC 11 and GCC 10 on powerpc64le-linux and > showed no regressions. Ok for backports? > > Peter > > > gcc/ > > PR target/109073 > * config/rs6000/rs6000-call.c (mma_init_builtins): Accept const pointer > operands for lxvp, stxvp and disassemble builtins. > > gcc/testsuite/ > > PR target/109073 > * gcc.target/powerpc/mma-builtin-4.c): New const * test. Update ~~ typo. > expected instruction counts. > * gcc.target/powerpc/mma-builtin-5.c: Likewise. > * gcc.target/powerpc/mma-builtin-7.c: Likewise. > > > diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c > index 1be4797e834..3b6d40f0aef 100644 > --- a/gcc/config/rs6000/rs6000-call.c > +++ b/gcc/config/rs6000/rs6000-call.c > @@ -14343,22 +14343,30 @@ mma_init_builtins (void) > { > op[nopnds++] = build_pointer_type (void_type_node); > if (d->code == MMA_BUILTIN_DISASSEMBLE_ACC) > - op[nopnds++] = build_pointer_type (vector_quad_type_node); > + op[nopnds++] = build_pointer_type (build_qualified_type > + (vector_quad_type_node, > + TYPE_QUAL_CONST)); Nit: Maybe we can build them out of the loop once and then just use the built one in the loop. > else > - op[nopnds++] = build_pointer_type (vector_pair_type_node); > + op[nopnds++] = build_pointer_type (build_qualified_type > + (vector_pair_type_node, > + TYPE_QUAL_CONST)); > } > else if (d->code == VSX_BUILTIN_LXVP) > { > op[nopnds++] = vector_pair_type_node; > op[nopnds++] = sizetype; > - op[nopnds++] = build_pointer_type (vector_pair_type_node); > + op[nopnds++] = build_pointer_type (build_qualified_type > + (vector_pair_type_node, > + TYPE_QUAL_CONST)); > } > else if (d->code == VSX_BUILTIN_STXVP) > { > op[nopnds++] = void_type_node; > op[nopnds++] = vector_pair_type_node; > op[nopnds++] = sizetype; > - op[nopnds++] = build_pointer_type (vector_pair_type_node); > + op[nopnds++] = build_pointer_type (build_qualified_type > + (vector_pair_type_node, > + TYPE_QUAL_CONST)); I wonder if the bifs which need to be updated are enough here. The reason why I asked is that on trunk *ptr_vector_pair_type_node* is used for function types v1poi_ftype_ulg_pv1poi, v_ftype_pv1poi_uv16qi_uv16qi, v_ftype_pv_pv1poi and v_ftype_v1poi_ulg_pv1poi, and *ptr_vector_quad_type_node* is used for function types v_ftype_pv1pxi, v_ftype_pv1pxi_uv16qi_uv16qi, v_ftype_pv1pxi_uv16qi_uv16qi_ci_ci, v_ftype_pv1pxi_uv16qi_uv16qi_ci_ci_ci, v_ftype_pv1pxi_uv16qi_uv16qi_uv16qi_uv16qi, v_ftype_pv1pxi_v1poi_uv16qi, v_ftype_pv1pxi_v1poi_uv16qi_ci_ci and v_ftype_pv_pv1pxi. These function types are further used for bifs as follow: __builtin_vsx_lxvp __builtin_mma_assemble_pair __builtin_vsx_assemble_pair __builtin_vsx_build_pair __builtin_mma_disassemble_pair __builtin_vsx_disassemble_pair __builtin_vsx_stxvp __builtin_mma_xxmfacc __builtin_mma_xxmtacc __builtin_mma_xxsetaccz ... ... and more ... Simply testing __builtin_mma_xxmtacc and __builtin_mma_xxmfacc as below: $ cat test.C void foo0(const __vector_quad *acc) { __builtin_mma_xxmtacc(acc); __builtin_mma_xxmfacc(acc); } test.C:2:25: error: invalid conversion from ‘const __vector_quad*’ to ‘__vector_quad*’ [-fpermissive] 2 | __builtin_mma_xxmtacc(acc); test.C:3:25: error: invalid conversion from ‘const __vector_quad*’ to ‘__vector_quad*’ [-fpermissive] 3 | __builtin_mma_xxmfacc(acc); They also suffered the same error on gcc11 branch but not on trunk. Besides, I'm not sure if the existing bif declarations using ptr_vector_pair_type_node and ptr_vector_quad_type_node are all intentional, at least it looks weird to me that we declare const __vector_pair* for this __builtin_vsx_stxvp, which is meant to store 32 bytes into the memory provided by the pointer biasing the sizetype offset, but the "const" qualifier seems to tell that this bif doesn't modify the memory pointed by the given pointer. As a contrast, for bif vec_xl (a, b), b is the address argument and of type const TYPE *, while for bif vec_xst (a, b, c), c is the address and of type TYPE *, here we don't add const qualifier for the address argument of vec_xst as expected. BR, Kewen