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 1oR4w1-0000r5-DW for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Aug 2022 04:57:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oR4vz-0000bV-Fv for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Aug 2022 04:57:39 +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 1oR4vy-0000bG-V9 for pgsql-hackers@lists.postgresql.org; Thu, 25 Aug 2022 04:57:39 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oR4vs-0007tR-Cx for pgsql-hackers@postgresql.org; Thu, 25 Aug 2022 04:57:37 +0000 Received: by mail-pj1-x102f.google.com with SMTP id x63-20020a17090a6c4500b001fabbf8debfso3658650pjj.4 for ; Wed, 24 Aug 2022 21:57:32 -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=ZUctvl1MVHMlPj1IzsDCl/xea3zIJ91CPf7r9rePrmo=; b=GeW/NnzXw8DNZ1omkxjVwb0f+lln6pEuc6He0JjPzY1h7EdQqswwCKpqF+dOc+1N04 QArB3FO2znmAGhjQeF1P+9Y9wdG2he5QZKcBKJmvqX/jKo7vLaku1r9KQYkpxMOCHm64 zu3BMcxxEU6z3BwDD2Ob0hM2YTffx9dzEgC/e/aMOTw2Rh2HpN/pRxQV8kKPcyp83Hns ttGp+WE8aE9sLlRfNZLgydwURE+Apy9azJ1I47egYIzwb7quTjjgFCcPKD+3gGh1DKcw NMHNuPNuqv7UXA8/uduoPt7nMjoppR9ut+bc6BUnG6tR43IkaC3aR4KuP9SEZQJjQbZE LWTg== 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=ZUctvl1MVHMlPj1IzsDCl/xea3zIJ91CPf7r9rePrmo=; b=ii5iMy/NfMTS0fnhg1pN7urYS3fqjMKBtK122JVj/9K2FqE32bOHVlW5Mu0dFdEU7w /vRdEND3MY3jDQO+emumKz+Y9D7D3/gXQKYr5qtdGydgUglm+r8A7JTMfGl1fZa9cgSs IziwRVuZiAd84SM7SkiP9ZfVquOFPD//IHLgwT4MvRZutNpHoXhAOAky5rSDyQb+KhZq 20p9EggWYknCgAifJx8YdKJ1kACSkECMg19IukMcqfa6NSf38ITRJaDtGgOfXGkMBYTE 3Jagmcdc2sW3M0XrguDiZqDmT1qaBx2gLeEQIR4xoO94d8tAeax3ebg/Poj2Ndc7pkv6 jl6w== X-Gm-Message-State: ACgBeo15SCiCghSwmEVPg+oOL2F3emonc6CH6qoZ+p+H59PMZRLMjwJk Q/BYcwwswPkwsRC3Khe8YSQ= X-Google-Smtp-Source: AA6agR5hLJDMZXxRmk5tlIzL10mloG4pcYLKAOqGaHuYXtZ9r4nyZtxRdlx8Vhi5rGngyOmueTJg4A== X-Received: by 2002:a17:902:f542:b0:173:a8a:d7bf with SMTP id h2-20020a170902f54200b001730a8ad7bfmr2094019plf.134.1661403451203; Wed, 24 Aug 2022 21:57:31 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id y65-20020a626444000000b005371689d70fsm4004149pfb.120.2022.08.24.21.57.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 21:57:30 -0700 (PDT) Date: Wed, 24 Aug 2022 21:57:29 -0700 From: Nathan Bossart To: John Naylor Cc: Andres Freund , pgsql-hackers Subject: Re: use ARM intrinsics in pg_lfind32() where available Message-ID: <20220825045729.GA1458024@nathanxps13> References: <20220819200829.GA395728@nathanxps13> <20220819212602.brjkd6ppgbohvo6g@awork3.anarazel.de> <20220819222814.GA401294@nathanxps13> <20220822211547.GA1126462@nathanxps13> <20220824180111.GB1302810@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 Thu, Aug 25, 2022 at 10:38:34AM +0700, John Naylor wrote: > On Thu, Aug 25, 2022 at 1:01 AM Nathan Bossart wrote: >> On Wed, Aug 24, 2022 at 11:07:03AM +0700, John Naylor wrote: >> > - Can a user on ARM64 ever get a runtime fault if the machine attempts >> > to execute NEON instructions? >> >> IIUC yes, although I'm not sure how likely it is in practice. > > Given the quoted part above, it doesn't seem likely, but we should try > to find out for sure, because a runtime fault is surely not acceptable > even on a toy system. 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. As originally suspected, I believe that simply checking for __aarch64__ would be sufficient, but I don't think it would be unreasonable to also check for __ARM_NEON to be safe. >> Interestingly, Clang still defines __ARM_NEON__ even when >> +nosimd is specified. > > POLA violation, but if no one has complained to them, it's a good bet > the instructions are always available. Sorry, I should've been more specific. In my testing, I could include or omit __ARM_NEON using +[no]simd, but __ARM_NEON__ (with two underscores at the end) was always there. My brief research seems to indicate this might be unique to Darwin, but in the end, it looks like __ARM_NEON (without the trailing underscores) is the most widely used. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com