From: | Niyas Sait <niyas(dot)sait(at)linaro(dot)org> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] Add native windows on arm64 support |
Date: | 2022-12-01 17:20:20 |
Message-ID: | 7ff7c416-fdfe-517f-a65c-9e5bd8ff8cec@linaro.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/11/2022 06:58, Michael Paquier wrote:
>>> #if defined(_WIN64)
>>> static __forceinline void
>>> spin_delay(void)
>>> {
>>> +#ifdef _M_ARM64
>>> + /*
>>> + * arm64 way of hinting processor for spin loops optimisations
>>> + * ref: https://community.arm.com/support-forums/f/infrastructure-solutions-forum/48654/ssetoneon-faq
>>> + */
>>> + __isb(_ARM64_BARRIER_SY);
>>> +#else
>>> _mm_pause();
>>> +#endif
>>> }
>>> #else
>>> static __forceinline void
>>
>> I think we should just apply this, there seems very little risk of making
>> anything worse, given the gating to _WIN64 && _M_ARM64.
>
> Seems so. Hmm, where does _ARM64_BARRIER_SY come from? Perhaps it
> would be better to have a comment referring to it from a different
> place than the forums of arm, like some actual docs?
_ARM64_BARRIER_SY is defined in Microsoft Arm64 intrinsic documentation
-
https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics?view=msvc-170#BarrierRestrictions
I couldn't find something more official for the sse2neon library part.
--
Niyas
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-12-01 17:21:39 | Re: Documentation for building with meson |
Previous Message | Niyas Sait | 2022-12-01 17:17:53 | Re: [PATCH] Add native windows on arm64 support |