Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oRRJS-0002bx-Vl for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Aug 2022 04:51:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oRRJR-0007tI-QC for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Aug 2022 04:51:21 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oRRJR-0007t9-GT for pgsql-hackers@lists.postgresql.org; Fri, 26 Aug 2022 04:51:21 +0000 Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oRRJO-0002NZ-Tp for pgsql-hackers@postgresql.org; Fri, 26 Aug 2022 04:51:20 +0000 Received: by mail-pl1-x629.google.com with SMTP id d12so629562plr.6 for ; Thu, 25 Aug 2022 21:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=1xHCvmnVa4GNdw5xY5FooxmVnq9wMfpE1IGm+G5zDK8=; b=U9uy3HcwmDl1Xc5F/39uN27147S3xZmShFmu3JkicRVTuMl1zWW7NZrAuHhdQ7I2WF sod+JITFFbEj8Elv/+MJGNOdZExIUaB7bjQ9P9RdkL81TRbptyJqQNSSeVwO8f+I5r6x wOpca/4kiTawT4trxgdyz4u4uDlOs4f35O8tq5CRYEPvYEYTMUO9fAHu2OszQVIvfacO 06uq57BhA6T2AQBI8FIEV+9cA1028QeU356/VKvDZQuYXKDwY1KoLnbh9VaLFVymzvoR y79QfAL2P9bh0bFyddRPJehr53hkS8sRO+uEGw0DHGiJzi3yJ2pykyg4f22XCCANyHgW TVbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=1xHCvmnVa4GNdw5xY5FooxmVnq9wMfpE1IGm+G5zDK8=; b=xEbv9Uvy22YvGrHnuzmHMMd/7OdubOEjPzYwnF4dgwgKRY42dn8z1Acnn4bJUkx6c9 zIHT3Jyy2YFT66ZVWKRVOMDtpW6SFbJ5a000qubw+iDv8g+XVcICwH46dW8CQzpdZ7Ix QDdlr7Ikra61Rn/6k6Be6xUji2m0rmzSnB3PsRQJBGeUMxwNFAeE+Tiz0QhHJjm6k22/ 2vyUzQ2mW+r/0bajDIl699x6GrO9vCgFmBbAacNznHXiQuSVP9v0efrRiLLBFbQrLdli QEEeR1hgZejbAuJaEegPEa8CQiaapILFIUspCKOTIPO3xTewHVK23fQfbhuCO9w32+1N G07Q== X-Gm-Message-State: ACgBeo1DKoGK4EFFbDlMsGiYtWAcL7o/PUr1hb8HdC7sSs7bxwtid1fS SFGtAClBd0//uGjOzYVkqoQ= X-Google-Smtp-Source: AA6agR73rOvoFdhqq1PArLZw+BbgYP0jAAerf9zcnmTQp+OnkRMqBDdANfQNEoS7fcu2jKX0SBSMxw== X-Received: by 2002:a17:90b:4acc:b0:1f5:7f05:12e8 with SMTP id mh12-20020a17090b4acc00b001f57f0512e8mr2409252pjb.92.1661489477697; Thu, 25 Aug 2022 21:51:17 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id h13-20020a170902680d00b0016d1f474653sm464018plk.52.2022.08.25.21.51.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Aug 2022 21:51:17 -0700 (PDT) Date: Thu, 25 Aug 2022 21:51:15 -0700 From: Nathan Bossart To: John Naylor Cc: Andres Freund , pgsql-hackers Subject: Re: use ARM intrinsics in pg_lfind32() where available Message-ID: <20220826045115.GA1638993@nathanxps13> References: <20220819200829.GA395728@nathanxps13> <20220819212602.brjkd6ppgbohvo6g@awork3.anarazel.de> <20220819222814.GA401294@nathanxps13> <20220822211547.GA1126462@nathanxps13> <20220824180111.GB1302810@nathanxps13> <20220825045729.GA1458024@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Aug 26, 2022 at 10:45:10AM +0700, John Naylor wrote: > On Thu, Aug 25, 2022 at 11:57 AM Nathan Bossart > wrote: >> The ARM literature appears to indicate that Neon support is pretty standard >> on aarch64, and AFAICT it's pretty common to just assume it's available. > > This doesn't exactly rise to the level of "find out for sure", so I > went looking myself. This is the language I found [1]: > > "Both floating-point and NEON are required in all standard ARMv8 > implementations. However, implementations targeting specialized > markets may support the following combinations: > > No NEON or floating-point. > Full floating-point and SIMD support with exception trapping. > Full floating-point and SIMD support without exception trapping." Sorry, I should've linked to the documentation I found. I saw similar language in a couple of manuals, which is what led me to the conclusion that Neon support is relatively standard. > Since we assume floating-point, I see no reason not to assume NEON, > but a case could be made for documenting that we require NEON on > aarch64, in addition to exception trapping (for CRC runtime check) and > floating point on any Arm. Or even just say "standard". I don't > believe anyone will want to run Postgres on specialized hardware > lacking these features, so maybe it's a moot point. I'm okay with assuming Neon support for now. It's probably easier to add the __ARM_NEON check if/when someone complains than it is to justify removing it once it's there. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com