From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 8833A3858C5E for ; Fri, 10 Mar 2023 01:25:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8833A3858C5E 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 (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 32A02FfW010018; Fri, 10 Mar 2023 01:25:04 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=DU9gCL3V2dc+kat7PMkFmksvQNdXkGn68Gq6h2aIMQA=; b=Kj4LFLDy+Jdws+kIbz4Ts//MbKwOzaRSp2W7wMvc4BxQ6VooSJ57QuglapM683EiJldv mNooca3Nj6Nu2FB6XRBposlwOTWrPtx31xeUoZJAo6Px95WiEdzRjMNNQSFmqcwKfNq6 W+i4fwAtPt7cATS4Y3LIEbP56IfPdePa8ndfiAWElIf9HJpp5jPGezGppsSLy4aCEehv KwiD0O5MQTasMO8srVd1v02l0vTgYR7DE0Y4WWKJYuivKSDb+KXjfghM3fiQ+S7JcBQd /5uSdGZDxmXej5Rx1sEwKfBZw2hD8V5INIRPzRJq4nLZVq+D3YdsCHmBSteCWzB7L63F Bw== Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3p7snghmrf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Mar 2023 01:25:04 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 329Ne48n022227; Fri, 10 Mar 2023 01:25:03 GMT Received: from smtprelay06.wdc07v.mail.ibm.com ([9.208.129.118]) by ppma01dal.us.ibm.com (PPS) with ESMTPS id 3p6fhhye4m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Mar 2023 01:25:03 +0000 Received: from smtpav02.wdc07v.mail.ibm.com (smtpav02.wdc07v.mail.ibm.com [10.39.53.229]) by smtprelay06.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 32A1OxWH62390540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Mar 2023 01:24:59 GMT Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C127D5805F; Fri, 10 Mar 2023 01:24:59 +0000 (GMT) Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 34C9B58059; Fri, 10 Mar 2023 01:24:59 +0000 (GMT) Received: from [9.211.90.110] (unknown [9.211.90.110]) by smtpav02.wdc07v.mail.ibm.com (Postfix) with ESMTP; Fri, 10 Mar 2023 01:24:59 +0000 (GMT) Message-ID: <3093b008-061c-885f-b799-1b609db68cb7@linux.ibm.com> Date: Thu, 9 Mar 2023 19:24:58 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] rs6000: Accept const pointer operands for MMA builtins [PR109073] Content-Language: en-US To: Segher Boessenkool , "Kewen.Lin" Cc: Chip Kerchner , GCC Patches References: <40ecb0c8-2821-a72b-549d-6de6876b5d45@linux.ibm.com> <20230309145520.GU25951@gate.crashing.org> From: Peter Bergner In-Reply-To: <20230309145520.GU25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 2ZUKr-Lui-dkuZBgt43oJriPgCfFpo50 X-Proofpoint-GUID: 2ZUKr-Lui-dkuZBgt43oJriPgCfFpo50 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_14,2023-03-09_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 clxscore=1015 mlxlogscore=999 spamscore=0 phishscore=0 impostorscore=0 mlxscore=0 malwarescore=0 suspectscore=0 bulkscore=0 adultscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2303100004 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,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 List-Id: On 3/9/23 8:55 AM, Segher Boessenkool wrote: > On Thu, Mar 09, 2023 at 05:30:53PM +0800, Kewen.Lin wrote: >> on 2023/3/9 07:01, Peter Bergner via Gcc-patches wrote: >>> This patch was tested in both GCC 11 and GCC 10 on powerpc64le-linux and >>> showed no regressions. Ok for backports? > > It isn't truly a backport. You can put it on 11 and 10 at the same time, > there is no benefit doing it on 11 only first. Correct. I just meant that they're targeted at the two release branches and not trunk. >>> 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. > > Or as globals even. Currently we have X and pointer to X, but no > pointer to const X (and no const X either, but that isn't so useful). > > The generic code doesn't have this either, hrm. I can have a look at that, but was trying to keep the change as small as possible. Especially since we're not trying to create code that will be "easier" to maintain in the future, because this is all changed in GCC12 with Bill's builtin re-write. >> 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. > > Yeah, there is more to be done here. Well I'm sure there are non-MMA builtins that have the same issue. I was just fixing the ones Chip ran into and similar builtins. I don't think we want to go and make everything work like it does on trunk, especially when no one has complained about hitting them. As for the __builtin_mma_xxm[ft]acc() errors, I'm not sure any actual code will ever hit this. All realistic examples declare a __vector_quad var and the pointer passed to the builtin comes from doing &var as the operand. Clearly we cannot have a "const __vector_quad var;" and use that in the builtins. >> 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. I'm not a language lawyer and I don't play one on TV. What we're accepting here, is a pointer with a "const" value that points to non-const memory. I'll double check the trunk code, but I don't think it allows (and we don't want it to) using a pointer (const or non-const) that points to a const memory ...at least for the stxvp builtin. > Since the patch is a strict improvement already, it is okay for 11 and > 10. But you (Peter) may want to flesh it out a bit first? Or first > commit only this if that works better for you. I'll see about making some of the changes above and then I'll report back. Peter