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 4D4603858D37 for ; Fri, 21 Apr 2023 09:54:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D4603858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com 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 CABB21480; Fri, 21 Apr 2023 02:55:36 -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 4FD783F5A1; Fri, 21 Apr 2023 02:54:52 -0700 (PDT) From: Richard Sandiford To: "Andre Vieira \(lists\)" Mail-Followup-To: "Andre Vieira \(lists\)" ,"gcc-patches\@gcc.gnu.org" , "jakub\@redhat.com" , Richard Biener , richard.sandiford@arm.com Cc: "gcc-patches\@gcc.gnu.org" , "jakub\@redhat.com" , Richard Biener Subject: Re: [RFC 0/X] Implement GCC support for AArch64 libmvec References: Date: Fri, 21 Apr 2023 10:54:51 +0100 In-Reply-To: (Andre Vieira's message of "Fri, 21 Apr 2023 10:28:43 +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=-24.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: "Andre Vieira (lists)" writes: > On 20/04/2023 17:13, Richard Sandiford wrote: >> "Andre Vieira (lists)" writes: >>> On 20/04/2023 15:51, Richard Sandiford wrote: >>>> "Andre Vieira (lists)" writes: >>>>> Hi all, >>>>> >>>>> This is a series of patches/RFCs to implement support in GCC to be able >>>>> to target AArch64's libmvec functions that will be/are being added to glibc. >>>>> We have chosen to use the omp pragma '#pragma omp declare variant ...' >>>>> with a simd construct as the way for glibc to inform GCC what functions >>>>> are available. >>>>> >>>>> For example, if we would like to supply a vector version of the scalar >>>>> 'cosf' we would have an include file with something like: >>>>> typedef __attribute__((__neon_vector_type__(4))) float __f32x4_t; >>>>> typedef __attribute__((__neon_vector_type__(2))) float __f32x2_t; >>>>> typedef __SVFloat32_t __sv_f32_t; >>>>> typedef __SVBool_t __sv_bool_t; >>>>> __f32x4_t _ZGVnN4v_cosf (__f32x4_t); >>>>> __f32x2_t _ZGVnN2v_cosf (__f32x2_t); >>>>> __sv_f32_t _ZGVsMxv_cosf (__sv_f32_t, __sv_bool_t); >>>>> #pragma omp declare variant(_ZGVnN4v_cosf) \ >>>>> match(construct = {simd(notinbranch, simdlen(4))}, device = >>>>> {isa("simd")}) >>>>> #pragma omp declare variant(_ZGVnN2v_cosf) \ >>>>> match(construct = {simd(notinbranch, simdlen(2))}, device = >>>>> {isa("simd")}) >>>>> #pragma omp declare variant(_ZGVsMxv_cosf) \ >>>>> match(construct = {simd(inbranch)}, device = {isa("sve")}) >>>>> extern float cosf (float); >>>>> >>>>> The BETA ABI can be found in the vfabia64 subdir of >>>>> https://github.com/ARM-software/abi-aa/ >>>>> This currently disagrees with how this patch series implements 'omp >>>>> declare simd' for SVE and I also do not see a need for the 'omp declare >>>>> variant' scalable extension constructs. I will make changes to the ABI >>>>> once we've finalized the co-design of the ABI and this implementation. >>>> >>>> I don't see a good reason for dropping the extension("scalable"). >>>> The problem is that since the base spec requires a simdlen clause, >>>> GCC should in general raise an error if simdlen is omitted. >>> Where can you find this in the specs? I tried to find it but couldn't. >>> >>> Leaving out simdlen in a 'omp declare simd' I assume is OK, our vector >>> ABI defines behaviour for this. But I couldn't find what it meant for a >>> omp declare variant, obviously can't be the same as for declare simd, as >>> that is defined to mean 'define a set of clones' and only one clone can >>> be associated to a declare variant. >> >> I was going from https://www.openmp.org/spec-html/5.0/openmpsu25.html , >> which says: >> >> The simd trait can be further defined with properties that match the >> clauses accepted by the declare simd directive with the same name and >> semantics. The simd trait must define at least the simdlen property and >> one of the inbranch or notinbranch properties. >> >> (probably best to read it in the original -- it's almost incomprehensible >> without markup) >> > I'm guessing the keyword here is 'trait' which I'm guessing is different > from a omp declare simd directive, which is why it's not required to > have a simdlen clause in an omp declare simd (see Jakub's comment). Sure. The thread above is about whether we need extension("scalable") or should drop it. And extension("scalable") is only used in omp declare variant. This was in response to "I also do not see a need for the 'omp declare variant' scalable extension constructs". Not having a simdlen on an omp declare simd is of course OK (and the VFABI defines behaviour for that case). Richard