Re: use ARM intrinsics in pg_lfind32() where available - Mailing list pgsql-hackers

From John Naylor
Subject Re: use ARM intrinsics in pg_lfind32() where available
Date
Msg-id CAFBsxsFLBzf=0g-E6doX1dkVN81YBGS+9ff-1=r-eMriN3HGxA@mail.gmail.com
Whole thread Raw
In response to Re: use ARM intrinsics in pg_lfind32() where available  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: use ARM intrinsics in pg_lfind32() where available
List pgsql-hackers
On Mon, Aug 29, 2022 at 3:19 PM John Naylor
<john.naylor@enterprisedb.com> wrote:
>
> It turns out MSVC animal drongo doesn't like this cast -- on x86 they
> are the same underlying type. Will look into that as more results come
> in.

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
}

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



pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: effective_multixact_freeze_max_age issue
Next
From: Amit Kapila
Date:
Subject: Re: Reducing the chunk header sizes on all memory context types