From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id A9F663850218 for ; Mon, 5 Jun 2023 13:49:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A9F663850218 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="6.00,217,1681200000"; d="scan'208";a="8567363" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 05 Jun 2023 05:49:33 -0800 IronPort-SDR: mGjzpwHsEv+vANSe3J/1XNrKqMmEETqav2RGYx6HYVIf4R0mce0/s3S+EQ3obRWz5ERAV/BMuN 5JQfS1PUhFFIbmYO6w/7wD7y6NDacDrIx8C/xzTf4oY8cKwD7N9WC4sxpuQKBr2rP8DKj8P0rs GlcQ/N5bKoqBUzfSKWQY6SostUsi3dBVfZWkSsa8Z1Y9IQiv5yBehfUrlWaVO2/i8Do5Dz75ze 7e04EjHbRmJSDxjh9+8WslC/0sQR9BdfloC+mRvq5e2kit10hkbQo3nVFbqfQMZ59zYn2rKbNB Y98= Message-ID: Date: Mon, 5 Jun 2023 14:49:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.11.0 Subject: Re: [PATCH] Add COMPLEX_VECTOR_INT modes Content-Language: en-GB To: Richard Biener CC: "gcc-patches@gcc.gnu.org" References: <77479c6f-5ce4-12fa-f429-c49ffbff3542@codesourcery.com> From: Andrew Stubbs In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On 30/05/2023 07:26, Richard Biener wrote: > On Fri, May 26, 2023 at 4:35 PM Andrew Stubbs wrote: >> >> Hi all, >> >> I want to implement a vector DIVMOD libfunc for amdgcn, but I can't just >> do it because the GCC middle-end models DIVMOD's return value as >> "complex int" type, and there are no vector equivalents of that type. >> >> Therefore, this patch adds minimal support for "complex vector int" >> modes. I have not attempted to provide any means to use these modes >> from C, so they're really only useful for DIVMOD. The actual libfunc >> implementation will pack the data into wider vector modes manually. >> >> A knock-on effect of this is that I needed to increase the range of >> "mode_unit_size" (several of the vector modes supported by amdgcn exceed >> the previous 255-byte limit). >> >> Since this change would add a large number of new, unused modes to many >> architectures, I have elected to *not* enable them, by default, in >> machmode.def (where the other complex modes are created). The new modes >> are therefore inactive on all architectures but amdgcn, for now. >> >> OK for mainline? (I've not done a full test yet, but I will.) > > I think it makes more sense to map vector CSImode to vector SImode with > the double number of lanes. In fact since divmod is a libgcc function > I wonder where your vector variant would reside and how GCC decides to > emit calls to it? That is, there's no way to OMP simd declare this function? The divmod implementation lives in libgcc. It's not too difficult to write using vector extensions and some asm tricks. I did try an OMP simd declare implementation, but it didn't vectorize well, and that's a yack I don't wish to shave right now. In any case, the OMP simd declare will not help us here, directly, because the DIVMOD transformation happens too late in the pass pipeline, long after ifcvt and vect. My implementation (not yet posted), uses a libfunc and the TARGET_EXPAND_DIVMOD_LIBFUNC hook in the standard way. It just needs the complex vector modes to exist. Using vectors twice the length is problematic also. If I create a new V128SImode that spans across two 64-lane vector registers then that will probably have the desired effect ("real" quotient in v8, "imaginary" remainder in v9), but if I use V64SImode to represent two V32SImode vectors then that's a one-register mode, and I'll have to use a permutation (a memory operation) to extract lanes 32-63 into lanes 0-31, and if we ever want to implement instructions that operate on these modes (as opposed to the odd/even add/sub complex patterns we have now) then the masking will be all broken and we'd need to constantly disassemble the double length vectors to operate on them. The implementation I proposed is essentially a struct containing two vectors placed in consecutive registers. This is the natural representation for the architecture. Anyway, you don't like this patch and I see that AArch64 is picking apart BLKmode to see if there's complex inside, so maybe I can make something like that work here? AArch64 doesn't seem to use TARGET_EXPAND_DIVMOD_LIBFUNC though, and I'm pretty sure the problem I was trying to solve was in the way the expand pass handles the BLKmode complex, outside the control of the backend hook (I'm still paging this stuff back in, post vacation). Thanks Andrew