Re: use ARM intrinsics in pg_lfind32() where available
От | Nathan Bossart |
---|---|
Тема | Re: use ARM intrinsics in pg_lfind32() where available |
Дата | |
Msg-id | 20220825045729.GA1458024@nathanxps13 обсуждение исходный текст |
Ответ на | Re: use ARM intrinsics in pg_lfind32() where available (John Naylor <john.naylor@enterprisedb.com>) |
Ответы |
Re: use ARM intrinsics in pg_lfind32() where available
|
Список | pgsql-hackers |
On Thu, Aug 25, 2022 at 10:38:34AM +0700, John Naylor wrote: > On Thu, Aug 25, 2022 at 1:01 AM Nathan Bossart <nathandbossart@gmail.com> 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
В списке pgsql-hackers по дате отправления: