From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 5AA9C3858D1E for ; Mon, 13 Mar 2023 21:26:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5AA9C3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 32DLPt0N013015; Mon, 13 Mar 2023 16:25:55 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 32DLPtUn013014; Mon, 13 Mar 2023 16:25:55 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 13 Mar 2023 16:25:55 -0500 From: Segher Boessenkool To: Peter Bergner Cc: "Kewen.Lin" , Chip Kerchner , GCC Patches Subject: Re: [PATCH] rs6000: Accept const pointer operands for MMA builtins [PR109073] Message-ID: <20230313212555.GB25951@gate.crashing.org> References: <40ecb0c8-2821-a72b-549d-6de6876b5d45@linux.ibm.com> <20230309145520.GU25951@gate.crashing.org> <3093b008-061c-885f-b799-1b609db68cb7@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3093b008-061c-885f-b799-1b609db68cb7@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no 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! On Thu, Mar 09, 2023 at 07:24:58PM -0600, Peter Bergner wrote: > On 3/9/23 8:55 AM, Segher Boessenkool wrote: > >> 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. Yup, just thinking out loud here, not asking for one way or the other. > 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. Yes :-) > >> 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. Certainly. And if this is only for MMA and it is fixed in 12, then we can just not deal with it and hope it will work out fine (there are few users of MMA after all). > 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. Right, but we should always (not just here) consider if similar problems will happen in similar cases. Deciding we don't want to fix this is just fine, but it helps to have some reasoning behind that. > 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. Which is perfectly fine. And having a non-const pointer to const data is fine even (but may well warn)! Trying to actually modify const data is not. This is in C; things are different in C++ of course. Evereything is different in C++. > 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. That is invalid, sure. Segher