From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id B14463858439 for ; Thu, 9 Feb 2023 12:55:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B14463858439 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x332.google.com with SMTP id e12-20020a0568301e4c00b0068bc93e7e34so499167otj.4 for ; Thu, 09 Feb 2023 04:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=LDsrqd2SNDJWm9LVveo4PnmTovMGC7tMneVG4aDhEaQ=; b=BIP625KCla3+tFtvTlSbEKyWwYAhylpS5mqnh55D2jn0exXKPK+k54TNb5fhDGIop/ zwL4p04tbA5FZmKvPohFOOZx9dbRS8Y5Gbv1VPzB0g6aiqmkWEiZg05RkTuXCg0BKWK0 /7DrsU8Gn0BcFilmZtxXDeIohyW32nhSFFhL14T3sbZiWZQdn+fHMlzM+Z80GP2mxSXs sxnl0epJtsIztvHQOfihmzKw0g7G/sm/9tvnNI0p24XuZmmosrqBYIte+FRuOJMtvR7S 1+ye/yj76SMjXLa5t3FHeXBC6VpskQLcmYN0UGvpO8CZJurSTbZ2V9VbLFuivpe+opfA EuTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LDsrqd2SNDJWm9LVveo4PnmTovMGC7tMneVG4aDhEaQ=; b=GRqDNCzVtOM3DDgLKUJGvqgqYJttiTseen/pWpdmxc1ZOcFBE3LxzttPj/Rt3nS7x1 S4CfAwc8YyVDsGasSFL0ibRyaMNr95yRdS2uc5yg/tXST+/A3H/ADUVNwSMAswj6cmsT zn98dUTn74na9uIOX+exlJgikPfBfFfUSBcnKsAOu1kZONEZOZwZrLmEMH5fBF2GqnsR 8JgfI7jxj1JZz+aXkTrgWUiqzbnr4aY8MCkFmGS2IsGdSqnIYM+2UqoB35Q0JK3J95mG LOqcq6P31LIZNdGhf/3eoIq/H84At1CFT+sHnZGINqD6roqYB2BT73Xli+Pz0Wf83zSR JzdQ== X-Gm-Message-State: AO0yUKUeQizofKu0INjDoG2326Aj70QiZWPfZ1FGI4Fk3n+SgvsSabGo 6mp7T0xskbzKC4USZMy6IKTxyITcmyHIn/3gV2E= X-Google-Smtp-Source: AK7set8YELSOw7YC/x6iyW1NS/rLS4xGPwrBlmZ0X3lW80ZbjZOt4sFFuxI34mLJig/C3eHJfIyqiA== X-Received: by 2002:a9d:647:0:b0:68b:cb6a:d1c5 with SMTP id 65-20020a9d0647000000b0068bcb6ad1c5mr6120276otn.36.1675947306845; Thu, 09 Feb 2023 04:55:06 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c2:8ced:4490:9a44:1abc:1757? ([2804:1b3:a7c2:8ced:4490:9a44:1abc:1757]) by smtp.gmail.com with ESMTPSA id t5-20020a4adbc5000000b00511e01623bbsm660366oou.7.2023.02.09.04.55.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Feb 2023 04:55:04 -0800 (PST) Message-ID: <5601b4c8-1b9a-6c21-00ee-034c9e93a31f@linaro.org> Date: Thu, 9 Feb 2023 09:55:00 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH] [RFC] Proposal for implementing AArch64 port of libmvec Content-Language: en-US To: Joe Ramsay , libc-alpha@sourceware.org, Szabolcs Nagy References: <20230207113555.66008-1-Joe.Ramsay@arm.com> <6565ff59-1a71-bdca-83f3-1f8b4f8f2e35@arm.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <6565ff59-1a71-bdca-83f3-1f8b4f8f2e35@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 09/02/23 09:43, Joe Ramsay wrote: > Thanks for the comments. I will attempt a patch that addresses them, in the meantime just a few questions: > > On 08/02/2023 13:11, Adhemerval Zanella Netto wrote: >> >> >> On 07/02/23 08:35, Joe Ramsay via Libc-alpha wrote: >>> Hi, >>> >>> The attached patch is an attempt to enable libmvec on AArch64. The >>> proposed change is mainly implementing build infrastructure to add the >>> new routines to ABI, tests and benchmarks. I have demonstrated how >>> this all fits together by adding implementations for vector cos, in >>> both single and double precision, targeting both Advanced SIMD and >>> SVE. >>> >>> The implementations of the routines themselves are just loops over the >>> scalar routine from libm for now, as we are more concerned with >>> getting the plumbing right at this point. We plan to contribute vector >>> routines from the Arm Optimized Routines repo that are compliant with >>> requirements described in the libmvec wiki. >>> >>> Any comments/thoughts much appreciated! In particular, the patch >>> raises the minimum GCC to 10, in order to be able to submit routines >>> written using ACLE instead of assembly. This is clearly a big jump, >>> but we have options if this is not acceptable. One option would be to >>> submit compiler-generated assembly, similar to the equivalent routines >>> under sysdeps/x86_64. If GCC 9 is an acceptable compromise then this >>> would only have to be for SVE routines. >> >> Using C implementation with intrinsics would be idea, there are more easily >> maintained and can leverage compiler improvements.  I rather do it instead >> of the assembly dump Intel did. >> >> The minimum GCC 10 is not ideal, however I don't see it as blocker either >> (it should be up to arch-maintainers).  One option might be check if >> compiler does not support building libmvec, disable the build and related >> checks.  It is not ideal either, since the resulting glibc won't have >> a complete ABI. >> >> > OK, let's see what arch-maintainers make of it. >>> >>> Also, are there plans to merge libmvec into libm, or will they be kept >>> separate? >> >> There is none afaik.  The libpthread, librt, etc. merge was done to >> fix long standing design and maintanance issues that is not really presented >> with libm and libmvec.  There is still the partial upgrade one, but >> it is still present with a disjoint ld, libc, libm anyway. >> >> However, it is feasible to merge if your willing to work on it.  We will >> need to keep the x86_64 lib with the sentinel compat symbol (similar to >> what we did for libpthread). >> >> What I would like to avoid is to have different arquitectures using different >> approaches, for instance aarch64 begin merged while having x86_64 still >> using a different library.  It add a slight more complexity to the build >> process and extra arch specific boilerplate code. >> > This sounds good - keeping them separate would be our choice too. I have not come across the sentinel compat symbol - is this something we need to do for AArch64 also? The sentinel compat symbols are required for the case if you want to merge x86 libmvec on libm, similar to what rt/librt-compat.c and nptl/libpthread-compat.c does. They are required so old binaries linked to libmvec does not fail at loading time, since they will have libmvec as DT_NEEDED. >> >> I think these tests should move to configure tests instead, it advertises beforehand >> the user that it needs to update the compiler instead through a compiler error. >> >> The configure check will then check for both advsimd and SVE support, so there is >> no need for __ADVSIMD_VEC_MATH_SUPPORTED or __SVE_VEC_MATH_SUPPORTED. >> > Apologies, I don't quite understand what you mean by this. I put these tests in so that users could compile against the new symbols with math.h as long as they had a sufficiently new compiler, but wouldn't get undefined types in math.h if they were using an old compiler that didn't have e.g. __Float32x4_t. (I think I remarked in the original message that new symbols hadn't been added to math.h, but this was not correct). Ah right, I missed that this is an *installed header*. In this case the __GNUC_PREREQ does make sense (sorry for the noise).