From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id F2C443858D35 for ; Fri, 9 Jun 2023 11:40:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F2C443858D35 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-lj1-x236.google.com with SMTP id 38308e7fff4ca-2b227fdda27so3368981fa.1 for ; Fri, 09 Jun 2023 04:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686310819; x=1688902819; 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=H/dTQo/s1rGXx76EwDXehdME6mzkLLjB5C1Sqw6aJ+w=; b=QgrDlq5QhHfh2fzGQyAyWbHBCxCa9+UajVpga43WxtG8cWem5Sh7WXBz5Tv9wn2tHJ hZulsZCpp0XNss47Ju+54fIHuu7U3CxveGJVormSkddgawz6HZtsvRRAWhp7xVu7FlxD KtOg7R3tLORxK/A4VgcKusyQ3878FSlun+vJW7CigNZd3V6GLe5xPsXNGsy36ofwJlFr Vc1K68BVdN3BUE4zC02Lv/yN8T4UByLvtWalcguouqZTH1z6NsIYHlNvWqerys50aMxh 24qaf6ZCuAburWGXq1JwMXJMT4b8bNWSZI1hxcuJ/e/9sOGTE7YuW1B7Ss/t7oqdWUrQ jcAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686310819; x=1688902819; 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=H/dTQo/s1rGXx76EwDXehdME6mzkLLjB5C1Sqw6aJ+w=; b=kdHVpBoKUjVuaANDkxbcy7JpVJEAlN3BBlLKw2wtuAEiHWAS7axe8TMuvfDPQhBhW/ CfGxzMDGR3GkHli++K+ohXtROetC43lO0NDpLfrC4LkPEN9VQkmo0dx+DpgmDNBQPzQ1 VsmPXeRTSR5tSJiAaqDMAUa5gdJA2oaRvxurgUrVJ5iLqWlJhNrEgTwllbTwsb8PdbK9 16x5TVLi7sCDn06ZWq/0Jn0WOeWwBzuIzg5FAxLRRL3B1tdSNixPwDaqBZPlcu7eQFRq 3yMmf0wVSkmlA4hQHqBQBz73dM/k6+OvxnDACJWElb18yEQayYN5UqABcwze0+4gbD99 03aA== X-Gm-Message-State: AC+VfDwMQaP+22l8FJzTcJyKrrprgxMTsaAN2T6mNGVw32+6Xf+OZohY NQOYy41PiWaR9HSz4J31g/2vymtZCfj4f7s2OIg= X-Google-Smtp-Source: ACHHUZ5WTjJPfOJ15bXENkBMI/7EBqVoNPVvecjIDIsIsbiXRb6XJ/4AsxEs0o/OVV4YWq7sSs1N+/mdqbkOd2qpiw4= X-Received: by 2002:a2e:8684:0:b0:2a9:ec7e:8f58 with SMTP id l4-20020a2e8684000000b002a9ec7e8f58mr587806lji.7.1686310818816; Fri, 09 Jun 2023 04:40:18 -0700 (PDT) MIME-Version: 1.0 References: <77479c6f-5ce4-12fa-f429-c49ffbff3542@codesourcery.com> <3b95bfff-9aed-dafb-e905-2f7398a865e9@codesourcery.com> In-Reply-To: From: Richard Biener Date: Fri, 9 Jun 2023 13:40:06 +0200 Message-ID: Subject: Re: [PATCH] Add COMPLEX_VECTOR_INT modes To: Andrew Stubbs Cc: "gcc-patches@gcc.gnu.org" , richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 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 Fri, Jun 9, 2023 at 11:45=E2=80=AFAM Andrew Stubbs wrote: > > On 09/06/2023 10:02, Richard Sandiford wrote: > > Andrew Stubbs writes: > >> On 07/06/2023 20:42, Richard Sandiford wrote: > >>> I don't know if this helps (probably not), but we have a similar > >>> situation on AArch64: a 64-bit mode like V8QI can be doubled to a > >>> 128-bit vector or to a pair of 64-bit vectors. We used V16QI for > >>> the former and "V2x8QI" for the latter. V2x8QI is forced to come > >>> after V16QI in the mode list, and so it is only ever used through > >>> explicit choice. But both modes are functionally vectors of 16 QIs. > >> > >> OK, that's interesting, but how do you map "complex int" vectors to th= at > >> mode? I tried to figure it out, but there's no DIVMOD support so I > >> couldn't just do a straight comparison. > > > > Yeah, we don't do that currently. Instead we make TARGET_ARRAY_MODE > > return V2x8QI for an array of 2 V8QIs (which is OK, since V2x8QI has > > 64-bit rather than 128-bit alignment). So we should use it for a > > complex-y type like: > > > > struct { res_type res[2]; }; > > > > In principle we should be able to do the same for: > > > > struct { res_type a, b; }; > > > > but that isn't supported yet. I think it would need a new target hook > > along the lines of TARGET_ARRAY_MODE, but for structs rather than array= s. And the same should work for complex types, no? In fact we could document that TARGET_ARRAY_MODE also is used for _Complex? Note the hook is used for type layout and thus innocent array types (in aggregates) can e= nd up with a vector mode now. Hopefully that's without bad effects (on the ABI). That said, the hook _could_ be used just for divmod expansion without actually creating a complex (or array) type of vectors. > > The advantage of this from AArch64's PoV is that it extends to 3x and 4= x > > tuples as well, whereas complex is obviously for pairs only. > > > > I don't know if it would be acceptable to use that kind of struct wrapp= er > > for the divmod code though (for the vector case only). > > Looking again, I don't think this will help because GCN does not have an > instruction that loads vectors that are back-to-back, hence there's > little benefit in adding the tuple mode. > > However, GCN does have instructions that effectively load 2, 3, or 4 > vectors that are *interleaved*, which would be the likely case for > complex numbers (or pixel colour data!) that's load_lanes and I think not related here but it probably also needs the xN modes. > I need to figure out how to move forward with this patch, please; if the > new complex modes are not acceptable then I think I need to reimplement > DIVMOD (maybe the scalars can remain as-is), but it's not clear to me > what that would look like. > > Andrew