From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id A6A923858416 for ; Tue, 6 Jun 2023 06:42:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A6A923858416 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-4f63ab1ac4aso189784e87.0 for ; Mon, 05 Jun 2023 23:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686033760; x=1688625760; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mqFGrMoAzw41NLPapoGMq0Bm0amdEDr2i4CcG2vNaZg=; b=DwpFS/ztTz6/KiVQvksNMXDufx8bytBmC7Gr+k4WclQ2chSDUS116ZzfVxkZtMMjyO tQySdy4rcuaG3gWvWSK39Uu5CFcO2OTUxAOdu30hO+WC4ACcymUlvBDAnzNtC1Rzum4x /s4q1ZcYf84KdquRygX1bLv8Kg3t6z3Lc0sqNQCMVY2SyZC421q6Q2u3swJRkGCgh2CP IMwUDHEsMydxW7yPazLbo2wDNkzf4j3f0zYOqP1RhoNpdauS9gf4+MoJelwP3J1S8+1i YTwR8BlTyZ5mmI5muhc+B/zgEHSW00xopHNAPIP5/kjr6L3Nrx0PdhEk5eOJZT9j2Zqr j9qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686033760; x=1688625760; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mqFGrMoAzw41NLPapoGMq0Bm0amdEDr2i4CcG2vNaZg=; b=WejL0NgNGc99MBB7cGTp6PJECw3AiEx7zgq3RJN8DHhRLYNOvBYEWK2NC5cs3gcmJ9 0uhEjxwctElaOIaIm1LDlVzhS3kcRa9eBQkliauzQydRqcqEJZpIs8uL+FMcxCsn72DJ vu7T+SoKQVsgGNf5llItn+TDX5SGZRXDEAJvWE26jKSIAFfzAYuJYCTc42+nxjfX5rS2 NcdKm63lQ8+kc5r0J5tG4M+f0CJjFU2lMAvCnYniaj4WxKqpYL1fjmkAnYhxsy8daIsH 4Rs/VUMBNNShBCUQPpzdRNkOVY/C3wC9FX4KUFJ7qAEZviIK6hzzeGb0HqorYqVZ3wJD eE/g== X-Gm-Message-State: AC+VfDxnaPxdXoG00EZZQqltUUFZFE/B9r2pRLkOqBxcioghQOMF1ISd GdC8E94if7uuDolVBEp9VByw5j8YnQUFdtI8x9e0xDNnhG0= X-Google-Smtp-Source: ACHHUZ7IVdObXR7ljYj6RqiVsO4FeVtV4kK+XqejNHRf/TC6khyGsvkfCWnY9g8uHwCbkH1Zc8CtdQmW/2njPeqRMkk= X-Received: by 2002:a19:ad09:0:b0:4f6:e50:d41c with SMTP id t9-20020a19ad09000000b004f60e50d41cmr518875lfc.60.1686033760024; Mon, 05 Jun 2023 23:42:40 -0700 (PDT) MIME-Version: 1.0 References: <77479c6f-5ce4-12fa-f429-c49ffbff3542@codesourcery.com> In-Reply-To: From: Richard Biener Date: Tue, 6 Jun 2023 08:40:19 +0200 Message-ID: Subject: Re: [PATCH] Add COMPLEX_VECTOR_INT modes To: Andrew Stubbs Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Mon, Jun 5, 2023 at 3:49=E2=80=AFPM Andrew Stubbs = wrote: > > On 30/05/2023 07:26, Richard Biener wrote: > > On Fri, May 26, 2023 at 4:35=E2=80=AFPM Andrew Stubbs wrote: > >> > >> Hi all, > >> > >> I want to implement a vector DIVMOD libfunc for amdgcn, but I can't ju= st > >> 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 exce= ed > >> the previous 255-byte limit). > >> > >> Since this change would add a large number of new, unused modes to man= y > >> architectures, I have elected to *not* enable them, by default, in > >> machmode.def (where the other complex modes are created). The new mod= es > >> 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 fun= ction? > > 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. I'm a bit confused as I don't see the difference between V64SCImode and V128SImode since both contain 128 SImode values. And I would expect the imag/real parts to be _always_ interleaved, irrespective of whether the result fits one or two vector registers. > The implementation I proposed is essentially a struct containing two > vectors placed in consecutive registers. This is the natural > representation for the architecture. I don't think you did that? Or at least I don't see how vectors of complex modes would match that. It would be a complex of a vector mode instead, no? I do see that internal functions with more than one output would be desirable and I think I proposed ASMs with a "coded text" aka something like a pattern ID or an optab identifier would be the best fit on GIMPLE but TARGET_EXPAND_DIVMOD_LIBFUNC for this particular case should be a good fit as well, no? Can you share what you needed to change to get your complex vector int code actually working? What does the divmod pattern matching create for the return type? The pass has /* Disable the transform if either is a constant, since division-by-const= ant may have specialized expansion. */ if (CONSTANT_CLASS_P (op1)) return false; if (CONSTANT_CLASS_P (op2)) { if (integer_pow2p (op2)) return false; if (TYPE_PRECISION (type) <=3D HOST_BITS_PER_WIDE_INT && TYPE_PRECISION (type) <=3D BITS_PER_WORD) return false; at least the TYPE_PRECISION query is bogus when type is a vector type and the IFN building does /* Part 3: Create libcall to internal fn DIVMOD: divmod_tmp =3D DIVMOD (op1, op2). */ gcall *call_stmt =3D gimple_build_call_internal (IFN_DIVMOD, 2, op1, op2)= ; tree res =3D make_temp_ssa_name (build_complex_type (TREE_TYPE (op1)), call_stmt, "divmod_tmp"); so that builds a complex type with a vector component, not a vector with complex components. Richard. > 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