* [PATCH] libatomic: x86_64: Always try ifunc
@ 2023-06-03 11:25 Xi Ruoyao
2023-06-03 12:53 ` Bernhard Reutner-Fischer
2023-06-09 12:37 ` Ping: " Xi Ruoyao
0 siblings, 2 replies; 6+ messages in thread
From: Xi Ruoyao @ 2023-06-03 11:25 UTC (permalink / raw)
To: gcc-patches; +Cc: Jakub Jelinek, Xi Ruoyao
We used to skip ifunc check when CX16 is available. But now we use
CX16+AVX+Intel/AMD for the "perfect" 16b load implementation, so CX16
alone is not a sufficient reason not to use ifunc (see PR104688).
This causes a subtle and annoying issue: when GCC is built with a
higher -march= setting in CFLAGS_FOR_TARGET, ifunc is disabled and
the worst (locked) implementation of __atomic_load_16 is always used.
There seems no good way to check if the CPU is Intel or AMD from
the built-in macros (maybe we can check every known model like __skylake,
__bdver2, ..., but it will be very error-prune and require an update
whenever we add the support for a new x86 model). The best thing we can
do seems "always try ifunc" here.
Bootstrapped and tested on x86_64-linux-gnu. Ok for trunk?
libatomic/ChangeLog:
* configure.tgt: For x86_64, always set try_ifunc=yes.
---
libatomic/configure.tgt | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index a92ae9e8309..39dd5686f2e 100644
--- a/libatomic/configure.tgt
+++ b/libatomic/configure.tgt
@@ -100,9 +100,7 @@ EOF
fi
cat > conftestx.c <<EOF
#ifdef __x86_64__
-#ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16
-#error need -mcx16
-#endif
+#error ifunc is always wanted for 16B atomic load
#else
#ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
#error need -march=i686
--
2.41.0
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libatomic: x86_64: Always try ifunc
2023-06-03 11:25 [PATCH] libatomic: x86_64: Always try ifunc Xi Ruoyao
@ 2023-06-03 12:53 ` Bernhard Reutner-Fischer
2023-06-03 13:46 ` Xi Ruoyao
2023-06-09 12:37 ` Ping: " Xi Ruoyao
1 sibling, 1 reply; 6+ messages in thread
From: Bernhard Reutner-Fischer @ 2023-06-03 12:53 UTC (permalink / raw)
To: Xi Ruoyao, Xi Ruoyao via Gcc-patches, gcc-patches; +Cc: Jakub Jelinek
On 3 June 2023 13:25:32 CEST, Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>There seems no good way to check if the CPU is Intel or AMD from
>the built-in macros (maybe we can check every known model like __skylake,
>__bdver2, ..., but it will be very error-prune and require an update
>whenever we add the support for a new x86 model). The best thing we can
>do seems "always try ifunc" here.
IIRC there is __builtin_cpu_is (after initialisation) -- A couple of days ago, we wondered if it would be handy to lower that even in fortran without going through C, so i am pretty sure I don't make that up.. ;-)
Just a thought,
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libatomic: x86_64: Always try ifunc
2023-06-03 12:53 ` Bernhard Reutner-Fischer
@ 2023-06-03 13:46 ` Xi Ruoyao
2023-06-03 14:04 ` Bernhard Reutner-Fischer
0 siblings, 1 reply; 6+ messages in thread
From: Xi Ruoyao @ 2023-06-03 13:46 UTC (permalink / raw)
To: Bernhard Reutner-Fischer, Xi Ruoyao via Gcc-patches; +Cc: Jakub Jelinek
On Sat, 2023-06-03 at 14:53 +0200, Bernhard Reutner-Fischer wrote:
> On 3 June 2023 13:25:32 CEST, Xi Ruoyao via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
> > There seems no good way to check if the CPU is Intel or AMD from
> > the built-in macros (maybe we can check every known model like
> > __skylake,
> > __bdver2, ..., but it will be very error-prune and require an update
> > whenever we add the support for a new x86 model). The best thing we
> > can
> > do seems "always try ifunc" here.
>
> IIRC there is __builtin_cpu_is (after initialisation) -- A couple of
> days ago, we wondered if it would be handy to lower that even in
> fortran without going through C, so i am pretty sure I don't make that
> up.. ;-)
Unfortunately __builtin_cpu_is performs CPU detection on runtime, not
compile time.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libatomic: x86_64: Always try ifunc
2023-06-03 13:46 ` Xi Ruoyao
@ 2023-06-03 14:04 ` Bernhard Reutner-Fischer
0 siblings, 0 replies; 6+ messages in thread
From: Bernhard Reutner-Fischer @ 2023-06-03 14:04 UTC (permalink / raw)
To: Xi Ruoyao, Xi Ruoyao via Gcc-patches; +Cc: Jakub Jelinek
On 3 June 2023 15:46:02 CEST, Xi Ruoyao <xry111@xry111.site> wrote:
>Unfortunately __builtin_cpu_is performs CPU detection on runtime, not
>compile time.
Right, you were talking about configure, sorry.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Ping: [PATCH] libatomic: x86_64: Always try ifunc
2023-06-03 11:25 [PATCH] libatomic: x86_64: Always try ifunc Xi Ruoyao
2023-06-03 12:53 ` Bernhard Reutner-Fischer
@ 2023-06-09 12:37 ` Xi Ruoyao
2023-06-09 12:49 ` Jakub Jelinek
1 sibling, 1 reply; 6+ messages in thread
From: Xi Ruoyao @ 2023-06-09 12:37 UTC (permalink / raw)
To: gcc-patches; +Cc: Jakub Jelinek
Ping (in hopes that someone can review before the weekend).
On Sat, 2023-06-03 at 19:25 +0800, Xi Ruoyao wrote:
> We used to skip ifunc check when CX16 is available. But now we use
> CX16+AVX+Intel/AMD for the "perfect" 16b load implementation, so CX16
> alone is not a sufficient reason not to use ifunc (see PR104688).
>
> This causes a subtle and annoying issue: when GCC is built with a
> higher -march= setting in CFLAGS_FOR_TARGET, ifunc is disabled and
> the worst (locked) implementation of __atomic_load_16 is always used.
>
> There seems no good way to check if the CPU is Intel or AMD from
> the built-in macros (maybe we can check every known model like
> __skylake,
> __bdver2, ..., but it will be very error-prune and require an update
> whenever we add the support for a new x86 model). The best thing we
> can
> do seems "always try ifunc" here.
>
> Bootstrapped and tested on x86_64-linux-gnu. Ok for trunk?
>
> libatomic/ChangeLog:
>
> * configure.tgt: For x86_64, always set try_ifunc=yes.
> ---
> libatomic/configure.tgt | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
> index a92ae9e8309..39dd5686f2e 100644
> --- a/libatomic/configure.tgt
> +++ b/libatomic/configure.tgt
> @@ -100,9 +100,7 @@ EOF
> fi
> cat > conftestx.c <<EOF
> #ifdef __x86_64__
> -#ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16
> -#error need -mcx16
> -#endif
> +#error ifunc is always wanted for 16B atomic load
> #else
> #ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
> #error need -march=i686
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Ping: [PATCH] libatomic: x86_64: Always try ifunc
2023-06-09 12:37 ` Ping: " Xi Ruoyao
@ 2023-06-09 12:49 ` Jakub Jelinek
0 siblings, 0 replies; 6+ messages in thread
From: Jakub Jelinek @ 2023-06-09 12:49 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: gcc-patches
On Fri, Jun 09, 2023 at 08:37:20PM +0800, Xi Ruoyao wrote:
> Ping (in hopes that someone can review before the weekend).
>
> On Sat, 2023-06-03 at 19:25 +0800, Xi Ruoyao wrote:
> > We used to skip ifunc check when CX16 is available. But now we use
> > CX16+AVX+Intel/AMD for the "perfect" 16b load implementation, so CX16
> > alone is not a sufficient reason not to use ifunc (see PR104688).
> >
> > This causes a subtle and annoying issue: when GCC is built with a
> > higher -march= setting in CFLAGS_FOR_TARGET, ifunc is disabled and
> > the worst (locked) implementation of __atomic_load_16 is always used.
> >
> > There seems no good way to check if the CPU is Intel or AMD from
> > the built-in macros (maybe we can check every known model like
> > __skylake,
> > __bdver2, ..., but it will be very error-prune and require an update
> > whenever we add the support for a new x86 model). The best thing we
> > can
> > do seems "always try ifunc" here.
> >
> > Bootstrapped and tested on x86_64-linux-gnu. Ok for trunk?
> >
> > libatomic/ChangeLog:
> >
> > * configure.tgt: For x86_64, always set try_ifunc=yes.
Ok, thanks.
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-06-09 12:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-03 11:25 [PATCH] libatomic: x86_64: Always try ifunc Xi Ruoyao
2023-06-03 12:53 ` Bernhard Reutner-Fischer
2023-06-03 13:46 ` Xi Ruoyao
2023-06-03 14:04 ` Bernhard Reutner-Fischer
2023-06-09 12:37 ` Ping: " Xi Ruoyao
2023-06-09 12:49 ` Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).