From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 4BC053861832; Wed, 27 Mar 2024 12:13:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4BC053861832 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4BC053861832 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711541594; cv=none; b=PC7EJxlwqF0z8kFixNU3F15wMFjSPD3w2NYItfJ7pjGs241jqoi5LCA9+jE0EK9HDLNA/BKKpsbfxUuVVAgV/xBlmnzoZL6P/giDc+m2O6ZrKKbrT9YegQ2ihlUKXO/2yRSBfm1+4y546B6sxGlnsrUepMscocjzL4u95XJB2cU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711541594; c=relaxed/simple; bh=FqTfGyE8XL2/XFDQX+dKVKuK/vXaysrJgFgfLQzwysg=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=IqQL0eqThmreTJiFNMcswO9I0TY3nNw6Tid84crVXSqARk9N82EGRjGTRydpGnxGVZjYl8WUmImtcHyBCzT/NApZtJsaZGfh52t/nZnRZ3MuODejdD/VGH70lE145fNFyiIh0B+ctO2oIerNAGBLdAf6HQnuepOiZCmZQMYQsP8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D210F2F4; Wed, 27 Mar 2024 05:13:45 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 00C9E3F694; Wed, 27 Mar 2024 05:13:10 -0700 (PDT) From: Richard Sandiford To: Matthias Kretz Mail-Followup-To: Matthias Kretz ,Jonathan Wakely , , , Srinivas Yadav Singanaboina , richard.sandiford@arm.com Cc: Jonathan Wakely , , , Srinivas Yadav Singanaboina Subject: Re: [PATCH v2] libstdc++: add ARM SVE support to std::experimental::simd References: <4336515.ejJDZkT8p0@minbar> Date: Wed, 27 Mar 2024 12:13:09 +0000 In-Reply-To: <4336515.ejJDZkT8p0@minbar> (Matthias Kretz's message of "Wed, 27 Mar 2024 11:30:12 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-14.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,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: Matthias Kretz writes: > On Wednesday, 27 March 2024 11:07:14 CET Richard Sandiford wrote: >> I'm still worried about: >> >> #if _GLIBCXX_SIMD_HAVE_SVE >> constexpr inline int __sve_vectorized_size_bytes = __ARM_FEATURE_SVE_BITS >> / 8; #else >> constexpr inline int __sve_vectorized_size_bytes = 0; >> #endif >> >> and the direct use __ARM_FEATURE_SVE_BITS elsewhere, for the reasons >> discussed here (including possible ODR problems): >> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640037.html >> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643734.html >> >> Logically the vector length should be a template parameter rather than >> an invariant. Has this been resolved? If not, it feels like a blocker >> to me (sorry). > > The vector length is always a template parameter to all user-facing API. Some > examples > > 1. on aarch64 the following is independent of SVE flags (and status quo): > > simd is an alias for > simd > > fixed_size_simd is supposed to be ABI-stable anyway (passed via > the stack, alignof == sizeof). > > 2. with -msve-vector-bits=512: > > native_simd is an alias for > simd> > > simd> is an alias for > simd> > > 3. with -msve-vector-bits=256: > > native_simd is an alias for > simd> > > simd> is an alias for > simd> > > Implementation functions are either [[gnu::always_inline]] or tagged with the > ABI tag type and the __odr_helper template argument (to ensure not-inlined > inline functions have unique names). Ah, thanks for the explanation. I think the global native_float alias is problematic for reasons that you touched on in your later message. I'll reply more about that there. But in other respects this looks good. > Does that make __ARM_FEATURE_SVE_BITS usage indirect enough? In principle, the only use of __ARM_FEATURE_SVE_BITS should be to determine the definition of native_simd (with the caveats above). But current GCC restrictions might make that impractical. > Also for context, please consider that this is std::*experimental*::simd. The > underlying ISO document will likely get retracted at some point and the whole > API and implementation (hopefully) superseded by C++26. The main purpose of > the spec and implementation is to gather experience. Ah, ok. If this is a deliberate experiment for evidence-gathering purposes, rather than a long-term commitment, then I agree the barrier should be lower. So yeah, I'll withdraw my objection. I've no problem with this going into GCC 14 on the basis above. Thanks again to you and Srinivas for working on this. Richard