From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 7B1C73858439; Thu, 18 Jan 2024 07:41:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7B1C73858439 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7B1C73858439 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1032 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705563663; cv=none; b=aNYO8sTxKmFX+mT4Jl7JHBhzcryXa+8bzCNyqCcOCRuNKNi6MLaeixXaBqsUseHYJx3cozqmX+9edTm2hWGvjlaviwLEh8BqoNl0tw8Q3xtaOGX3NvwdcMa8iQfB/TCdp6+mijI520hZaoLL3IwsegwRp+78+Yqq6gMVGm4LlZg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705563663; c=relaxed/simple; bh=pXImkuFUdLAUg9upj2adFZxEULCBWB1Dzc7fkIUfVTA=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=ku7P0boy9f4Mse3PdQH9EEjexcZJfOpKrmFGx9KREPCdnYE+4/iwvLH12GCjeJbVJ5ndKzLL94MA8O+iRoEEhYkubRUBF38R1Dxaw1xsYnm9+kdKK6HQfwp4A1VFV7U/4g7Pw4ZVrtY+vnyuP0nfuxiFO628OkRsHIG0oAYT0Dg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-29026523507so146359a91.0; Wed, 17 Jan 2024 23:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705563660; x=1706168460; darn=gcc.gnu.org; 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=iLNbXrYqU5u/dV1xVc+JpI+Q/g9RatZ9CsFIYykhg6g=; b=jVWiYg52+aqQqw7LfRs+x4cLAPB533oWA5XSbGrl66CXijzGxbRR7csAp03WhZTXh0 VA2xD0jH2c3RswaTrN1L0Dh6J+HKBOyg9TIHUWt2Efc1ChulcdOt8ESANyxK69woXM7u kc8nnzIrY0qa0/Pwn3hQm61iCw4u8Rg+oPJc/8rVUwkhvu9Zh96NGI9/QEaZjPYEOyWB kVnocgJTotBJiUYs3Kjh5dy/qlu5uhLp1yj6ZU/SRS113PQ1gUyRy+HfQhioAibyNPGA /Zwzlb84aaeMUCjyurtRjUlIrbLOjidKq1a2EHWMmzXMArva/6cxzZbGdngLTK4VWTN5 NDiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705563660; x=1706168460; 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=iLNbXrYqU5u/dV1xVc+JpI+Q/g9RatZ9CsFIYykhg6g=; b=pdAEbGOe/4y27mbHqyy84vMluTTOmOcBNYbZWv0IhthS2jMSQsmm0eE3v5oUna3dQE LWCC4BvaEW9BQTCyrrGbQj5js+Qt71ApMmpsniNKRBljW3JpjWqu60SV7jNg5LlHE6pb 4svZIp2lyQnAMRmlDocj00AMfEQg+REPG3Of16VxhOL9smOL69uImXg6C3wcGNyTGhNN oMw2Un3RoHCbalJgzQwUcvbHvZ+T74hGuGhLwDSIM17dzYY884zbSipYdsO7X/hN7kNw GHnQpuUpM2gwAQFD96HgZyfKwvvtJW9pAQRAPQReVAodCoG3zQm93+p0Ha1qkGMKKLMV rSXQ== X-Gm-Message-State: AOJu0YzjGuSSFwaLX91mTDKA1FmzWsJ+RcD02uOjqggT6P7a7/+qy0Tz OlCWUIB6ZfAx6elFT6c0tGABRP4dM6gXpVHhC+rIPJVYJ9P50do2VFLVFqFzXND3I5HHyu5Dw6c wPnZAVsZWd2MpMuDT1wYnvJvQG4U= X-Google-Smtp-Source: AGHT+IFd/nsXhU8kOXlxg0kBkxgx7G7aEO5RhOQCBNqIK/zcJ7QZ+yY3jvT6uPIF5Rod4wkeviruEk4oenDABN+13jo= X-Received: by 2002:a17:90a:8a11:b0:28e:23ad:2d13 with SMTP id w17-20020a17090a8a1100b0028e23ad2d13mr427238pjn.74.1705563660244; Wed, 17 Jan 2024 23:41:00 -0800 (PST) MIME-Version: 1.0 References: <12731700.VsHLxoZxqI@centauriprime> In-Reply-To: <12731700.VsHLxoZxqI@centauriprime> From: Andrew Pinski Date: Wed, 17 Jan 2024 23:40:48 -0800 Message-ID: Subject: Re: [PATCH] libstdc++: add ARM SVE support to std::experimental::simd To: Matthias Kretz Cc: Srinivas Yadav , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,BODY_8BITS,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,URIBL_SBL_A 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 Wed, Jan 17, 2024 at 11:28=E2=80=AFPM Matthias Kretz wr= ote: > > On Thursday, 4 January 2024 10:10:12 CET Andrew Pinski wrote: > > I really doubt this would work in the end. Because HW which is 128bits > > only, can't support -msve-vector-bits=3D2048 . I am thinking > > std::experimental::simd is not the right way of supporting this. > > Really the route the standard should be heading towards is non > > constant at compile time sized vectors instead and then you could use > > the constant sized ones to emulate the Variable length ones. > > I don't follow. "non-constant at compile time sized vectors" implies > sizeless (no constexpr sizeof), no? > Let me try to explain where I'm coming from. One of the motivating use > cases for simd types is composition. Like this: > > template > struct Point > { > T x, y, z; > > T distance_to_origin() { > return sqrt(x * x + y * y + z * z); > } > }; > > Point is one point in 3D space, Point> stores multiple > points in 3D space and can work on them in parallel. > > This implies that simd must have a sizeof. C++ is unlikely to get > sizeless types (the discussions were long, there were many papers, ...). > Should sizeless types in C++ ever happen, then composition is likely goin= g > to be constrained to the last data member. Even this is a bad design in general for simd. It means the code needs to know the size. Also AoS vs SoA is always an interesting point here. In some cases you want an array of structs for speed and Point> does not work there at all. I guess This is all water under the bridge with how folks design code. You are basically pushing AoSoA idea here which is much worse idea than bef= ore. That being said sometimes it is not a vector of N elements you want to work on but rather 1/2/3 vector of N elements. Seems like this is just pushing the idea one of one vector of one type of element which again is wrong push. Also more over, I guess pushing one idea of SIMD is worse than pushing any idea of SIMD. For Mathematical code, it is better for the compiler to do the vectorization than the user try to be semi-portable between different targets. This is what was learned on Fortran but I guess some folks in the C++ likes to expose the underlying HW instead of thinking high level here. Thanks, Andrew Pinski > > With the above as our design constraints, SVE at first seems to be a bad > fit for implementing std::simd. However, if (at least initially) we accep= t > the need for different binaries for different SVE implementations, then y= ou > can look at the "scalable" part of SVE as an efficient way of reducing th= e > number of opcodes necessary for supporting all kinds of different vector > lengths. But otherwise you can treat it as fixed-size registers - which i= t > is for a given CPU. In the case of a multi-CPU shared-memory system (e.g. > RDMA between different ARM implementations) all you need is a different > name for incompatible types. So std::simd on SVE256 must have a > different name on SVE512. Same for std::simd (which is currentl= y > not the case with Sriniva's patch, I think, and needs to be resolved). For SVE that is a bad design. It means The code is not portable at all. > > > I think we should not depend on __ARM_FEATURE_SVE_BITS being set here > > and being meanful in any way. > > I'd love to. In the same way I'd love to *not depend* on __AVX__, > __AVX512F__ etc. > > - Matthias > > -- > =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 > Dr. Matthias Kretz https://mattkretz.github.io > GSI Helmholtz Center for Heavy Ion Research https://gsi.de > std::simd > =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80