Re: use ARM intrinsics in pg_lfind32() where available

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: use ARM intrinsics in pg_lfind32() where available
Date: 2022-08-29 10:49:46
Message-ID: CAFBsxsHoJUgXfSYuuhuasTDCw85DtrKx=Wga8j7y5+sPMOam6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 29, 2022 at 4:28 PM John Naylor
<john(dot)naylor(at)enterprisedb(dot)com> wrote:
>
> Here's the simplest fix I can think of:
>
> /*
> * Exactly like vector8_is_highbit_set except for the input type, so
> it still looks
> * at each _byte_ separately.
> *
> * XXX x86 uses the same underlying type for vectors with 8-bit,
> 16-bit, and 32-bit
> * integer elements, but Arm does not, hence the need for a separate function.
> * We could instead adopt the behavior of Arm's vmaxvq_u32(), i.e. check each
> * 32-bit element, but that would require an additional mask operation on x86.
> */
> static inline bool
> vector32_is_highbit_set(const Vector32 v)
> {
> #if defined(USE_NEON)
> return vector8_is_highbit_set((Vector8) v);
> #else
> return vector8_is_highbit_set(v);
> #endif
> }

Bowerbird just reported the same error, so I went ahead and pushed a
fix with this.

--
John Naylor
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-08-29 11:04:51 Re: Handle infinite recursion in logical replication setup
Previous Message Jelte Fennema 2022-08-29 10:47:28 Re: [PATCH] Optimize json_lex_string by batching character copying