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 1oS4nT-0002JD-08 for pgsql-hackers@arkaria.postgresql.org; Sat, 27 Aug 2022 23:00:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oS4nQ-00056d-UR for pgsql-hackers@arkaria.postgresql.org; Sat, 27 Aug 2022 23:00:56 +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 1oS4nQ-00056U-HO for pgsql-hackers@lists.postgresql.org; Sat, 27 Aug 2022 23:00:56 +0000 Received: from mail-pf1-x429.google.com ([2607:f8b0:4864:20::429]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oS4nM-0006Zb-EU for pgsql-hackers@postgresql.org; Sat, 27 Aug 2022 23:00:55 +0000 Received: by mail-pf1-x429.google.com with SMTP id 142so4892298pfu.10 for ; Sat, 27 Aug 2022 16:00:52 -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=Q/EIshh/yI+a5ZejRIzHgjHKPCoZkZgIsEEw+N0izUs=; b=RnlCjX/TO2A0noIVmlc0jpr5n6lYREgwNEqad8m7RdBw/dXGW5GkNDptnKET0EGKP3 BV/c8VlSFJ7mpCyXBMn3ghPvQJuHJ0+OIT/V3rOoRO6MxHVFsuRrzsODbgVa5zTLCn9Q /h8qddXIHwNigW18KBnh6GkgdTm9KcqiyJMPjY0BaGAiLd+x0o1K2jAO1VRrCufwPDGb r+OJ2A4jHpNbAay70hqDJOvPUw1GX7y5PoVMRnsYTgJZlkSWMbry2N7KjAN27xwLLHsP ToC3Ohff2dw2rGeztGy3ExHkjnKSC7uwdkAvrv7am6P9H+5ehg7II6LjiVFmPN/jcw9Z vgqQ== 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=Q/EIshh/yI+a5ZejRIzHgjHKPCoZkZgIsEEw+N0izUs=; b=qWs4XJzO/NhuW5WHIvMPVCCoPUDH03Jr/TmiyYpi93M+Vei6TnWiXnfVRrd80jnbx1 OdXVQwrVlhEjV1Rd3r/4y9OTBqk11utazgLLRmMQwKP07724pnBR4ct5O4pwJHSA6Sd1 NvvnGetkgbLaqdWu/rhfxQgMrCvd8Ao72SkdX74bAQT1M/1WdFTsHkkRjbdQVu5ZBVI2 EG7lcQqsLuXYvUjjXuhqFm1dKaQF0kmqwxJgV7Ol636Ga+IkjyL9tLpeuPMaRpgaAtlH 9sbb5EmUcaE7TU8M35kXA7hRpokfY3RzWac7YsJAbZx9v6qhEo1f72ZKZsS8ZasNtsUz O9Mw== X-Gm-Message-State: ACgBeo1+cJwAO60tULM4RoChKKTxFYLVJWUZznYyU5u6Qp5cU3oErWA9 CxUWZSmSI3+mX7oP5UduhOM= X-Google-Smtp-Source: AA6agR6PYIEp0LFXxuPxpztjo1kVudlCuewkxFwtFVrYWhRojitCsMNmB+ilGX94ZN3rxCn/r/COfQ== X-Received: by 2002:a63:205e:0:b0:42a:98c6:182a with SMTP id r30-20020a63205e000000b0042a98c6182amr8255212pgm.482.1661641251477; Sat, 27 Aug 2022 16:00:51 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id ft15-20020a17090b0f8f00b001fbbbe38387sm3864283pjb.10.2022.08.27.16.00.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Aug 2022 16:00:51 -0700 (PDT) Date: Sat, 27 Aug 2022 16:00:49 -0700 From: Nathan Bossart To: Thomas Munro Cc: John Naylor , Andres Freund , pgsql-hackers Subject: Re: use ARM intrinsics in pg_lfind32() where available Message-ID: <20220827230049.GA111000@nathanxps13> References: <20220824180111.GB1302810@nathanxps13> <20220825045729.GA1458024@nathanxps13> <20220826045115.GA1638993@nathanxps13> <20220826061347.GA1777731@nathanxps13> <20220826182403.GA1917683@nathanxps13> <20220827221234.GA15951@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 Sun, Aug 28, 2022 at 10:39:09AM +1200, Thomas Munro wrote: > On Sun, Aug 28, 2022 at 10:12 AM Nathan Bossart > wrote: >> Yup. The problem is that AFAICT there's no equivalent to >> _mm_movemask_epi8() on aarch64, so you end up with something like >> >> vmaxvq_u8(vandq_u8(v, vector8_broadcast(0x80))) != 0 >> >> But for pg_lfind32(), we really just want to know if any lane is set, which >> only requires a call to vmaxvq_u32(). I haven't had a chance to look too >> closely, but my guess is that this ultimately results in an extra AND >> operation in the aarch64 path, so maybe it doesn't impact performance too >> much. The other option would be to open-code the intrinsic function calls >> into pg_lfind.h. I'm trying to avoid the latter, but maybe it's the right >> thing to do for now... What do you think? > > Ahh, this gives me a flashback to John's UTF-8 validation thread[1] > (the beginner NEON hackery in there was just a learning exercise, > sadly not followed up with real patches...). He had > _mm_movemask_epi8(v) != 0 which I first translated to > to_bool(bitwise_and(v, vmovq_n_u8(0x80))) and he pointed out that > vmaxvq_u8(v) > 0x7F has the right effect without the and. I knew there had to be an easier way! I'll give this a try. Thanks. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com