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 E6AEB3858296 for ; Wed, 15 Feb 2023 09:44:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E6AEB3858296 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 31F9hO2L001890; Wed, 15 Feb 2023 03:43:24 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 31F9hNH6001884; Wed, 15 Feb 2023 03:43:23 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 15 Feb 2023 03:43:23 -0600 From: Segher Boessenkool To: Jakub Jelinek Cc: Simon Richter , David Edelsohn , gcc@gcc.gnu.org Subject: Re: POWER __builtin_add_overflow/__builtin_mul_overflow with u64 Message-ID: <20230215094323.GE25951@gate.crashing.org> References: <567bf141-3d8b-201f-933b-087db28fc38b@hogyros.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_NUMSUBJECT,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 Tue, Feb 14, 2023 at 09:23:55AM +0100, Jakub Jelinek wrote: > CCing Segher and David on this. > rs6000 indeed doesn't implement {,u}{add,sub,mul}v4_optab for > any mode and thus leaves it to the generic code. Yes. Can we do better than the generic code, for those? > On Tue, Feb 14, 2023 at 04:48:42AM +0100, Simon Richter wrote: > > I'm looking at the generated code for these builtins on POWER: > > > > add 4,3,4 > > subfc 3,3,4 > > subfe 3,3,3 > > std 4,0(5) > > rldicl 3,3,0,63 > > blr > > > > and > > > > mulld 10,3,4 > > mulhdu 3,3,4 > > addic 9,3,-1 > > std 10,0(5) > > subfe 3,9,3 > > blr (The _overflow builtins, which obviously generate different code). This is pretty much as good as we can do, at least with older ISAs. With ISA 3.0 (p9) we have isel and with ISA 3.1 (p10) we have setbc*, allowing us to improve on this slightly. > > The POWER architecture has variants of these instructions with builtin > > overflow checks (addo/mulldo), but these aren't listed in the .md files, and > > the builtins don't generate them either. > > > > Is this intentional (I've found a few comments that mulldo is microcoded on > > CellBE and should be avoided there)? As Eric points at we cannot easily use OV since ISA 2.00 (p4, 2001). ISA 3.0 allows us to use addex to get at the OV bit (but inconveniently, the insn is really only meant to allow multiple regs in lon carry chains for multi-precision arithmetic and the like), but nothing else does. Before ISA 2.00 we could use OV easily using the mcrxr instruction, or save up testing it for as many insns as we want using the SO bit, which mcrxr also reads, and conveniently also clears. But instructions like that (reading from three separate resoources and writing to one as well, one that is not renamed even) are not suitable for heavily out-of-order implementations. Since ISA 3.0 we can read OV using mcrxrx. This can allow slightly faster sequences for some specialised cases. That insn also allows us to move CA into a GPR in just one insn as well, hrm :-) I'll add a work item to investigate what we can do here. Improvements will be only marginal, maybe an insn or a cycle or two can be saved here or there, but it is not likely worth it to have o variants of most instructions (which are very inconvenient to deal with in the compiler, they are much nicer for human writers). Segher