| Message ID | 5493ec17bd3da2c94bfe5d63a02b493a9acb41f7.camel@marvell.com |
|---|---|
| State | New |
| Headers | show |
| Series | [Aarch64] Implement TARGET_GET_MULTILIB_ABI_NAME for aarch64 (for use in Fortran vector header file) | expand |
On 2/19/19 11:32 PM, Steve Ellcey wrote: > I am not sure if we > need all of those but it seemed better to have them and not use them > than to find out we need them later. Hi. About the SVE: isn't the ABI dependent on the bit width of vectors? Martin
Martin Liška <mliska@suse.cz> writes: > On 2/19/19 11:32 PM, Steve Ellcey wrote: >> I am not sure if we >> need all of those but it seemed better to have them and not use them >> than to find out we need them later. > > Hi. > > About the SVE: isn't the ABI dependent on the bit width of vectors? It's dependent on the types. There are ABI types for Advanced SIMD vectors and ABI types for SVE vectors. The two end up being the same length at runtime on when the SVE vector length is 128 bits, but they're still separate types with separate conventions. (E.g. __attribute__((vector_size)) never creates an ABI-level SVE vector, even with -msve-vector-bits=N, but it can create an ABI-level Advanced SIMD vector.) I think we should leave the SVE stuff out for now though. ISTM that: !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64') !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_sve') is trying to say that there's both an Advanced SIMD implementation of sin and an SVE implementation of sin. But AFAICT the patch would just treat the two the same way when SVE is enabled, which I think in practice means that both would declare an Advanced SIMD function. Once we support SVE vector functions, how would the header file declare the Advanced SIMD function when SVE is enabled on the command line? Or similarly for other architectures with multiple vector ISAs? For C I think this would be done with #pragma GCC target push/pop. Is there any significance to the names of the multilibs? E.g. are we supposed to follow Debian conventions? Thanks, Richard
On 2/20/19 11:04 AM, Richard Sandiford wrote: > Martin Liška <mliska@suse.cz> writes: >> On 2/19/19 11:32 PM, Steve Ellcey wrote: >>> I am not sure if we >>> need all of those but it seemed better to have them and not use them >>> than to find out we need them later. >> >> Hi. >> >> About the SVE: isn't the ABI dependent on the bit width of vectors? > > It's dependent on the types. There are ABI types for Advanced SIMD > vectors and ABI types for SVE vectors. The two end up being the same > length at runtime on when the SVE vector length is 128 bits, but they're > still separate types with separate conventions. > > (E.g. __attribute__((vector_size)) never creates an ABI-level SVE vector, > even with -msve-vector-bits=N, but it can create an ABI-level Advanced > SIMD vector.) > > I think we should leave the SVE stuff out for now though. ISTM that: > > !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64') > !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_sve') > > is trying to say that there's both an Advanced SIMD implementation of sin > and an SVE implementation of sin. But AFAICT the patch would just treat > the two the same way when SVE is enabled, which I think in practice means > that both would declare an Advanced SIMD function. > > Once we support SVE vector functions, how would the header file declare > the Advanced SIMD function when SVE is enabled on the command line? > Or similarly for other architectures with multiple vector ISAs? > For C I think this would be done with #pragma GCC target push/pop. I guess that should be handled internally in glibc via e.g. ifunc mechanism. Glibc ABI for SIMD functions should follow normal calling conventions. > > Is there any significance to the names of the multilibs? E.g. are we > supposed to follow Debian conventions? No, consensus about the names would be only only shared in between a compiler and a C library. Thanks, Martin > > Thanks, > Richard >
Martin Liška <mliska@suse.cz> writes: > On 2/20/19 11:04 AM, Richard Sandiford wrote: >> Martin Liška <mliska@suse.cz> writes: >>> On 2/19/19 11:32 PM, Steve Ellcey wrote: >>>> I am not sure if we >>>> need all of those but it seemed better to have them and not use them >>>> than to find out we need them later. >>> >>> Hi. >>> >>> About the SVE: isn't the ABI dependent on the bit width of vectors? >> >> It's dependent on the types. There are ABI types for Advanced SIMD >> vectors and ABI types for SVE vectors. The two end up being the same >> length at runtime on when the SVE vector length is 128 bits, but they're >> still separate types with separate conventions. >> >> (E.g. __attribute__((vector_size)) never creates an ABI-level SVE vector, >> even with -msve-vector-bits=N, but it can create an ABI-level Advanced >> SIMD vector.) >> >> I think we should leave the SVE stuff out for now though. ISTM that: >> >> !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64') >> !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_sve') >> >> is trying to say that there's both an Advanced SIMD implementation of sin >> and an SVE implementation of sin. But AFAICT the patch would just treat >> the two the same way when SVE is enabled, which I think in practice means >> that both would declare an Advanced SIMD function. >> >> Once we support SVE vector functions, how would the header file declare >> the Advanced SIMD function when SVE is enabled on the command line? >> Or similarly for other architectures with multiple vector ISAs? >> For C I think this would be done with #pragma GCC target push/pop. > > I guess that should be handled internally in glibc via e.g. ifunc mechanism. > Glibc ABI for SIMD functions should follow normal calling conventions. The vector architecture determines the function interface though. It's part of the mangling scheme and decides the types of the vector parameters and results. E.g. Advanced SIMD vector sin and SVE vector sin have different (public) names and different interfaces. So at least in C, "#pragma omp declare simd" doesn't just say that a vector version exists, it says that a vector version exists for a specific architecture. > > Is there any significance to the names of the multilibs? E.g. are we > > supposed to follow Debian conventions? > > No, consensus about the names would be only only shared in between a compiler > and a C library. OK, great. Thanks, Richard
On Wed, Feb 20, 2019 at 10:04:04AM +0000, Richard Sandiford wrote: > Martin Liška <mliska@suse.cz> writes: > > About the SVE: isn't the ABI dependent on the bit width of vectors? > > It's dependent on the types. There are ABI types for Advanced SIMD > vectors and ABI types for SVE vectors. The two end up being the same > length at runtime on when the SVE vector length is 128 bits, but they're > still separate types with separate conventions. > > (E.g. __attribute__((vector_size)) never creates an ABI-level SVE vector, > even with -msve-vector-bits=N, but it can create an ABI-level Advanced > SIMD vector.) > > I think we should leave the SVE stuff out for now though. ISTM that: > > !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64') > !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_sve') The if clause is optional, you don't need to use it if you don't need to (as in, if glibc is e.g. going to implement those functions for all aarch64 multilibs or if only for some of them but it isn't expected they'd be used together on the same host except perhaps for multiarch; say if you implemented it for little-endian only, the question is if could be using the same header for both little-endian and big-endian compilations or not). And, as I said in the thread, there is always an option to add some !GCC$ builtin if clause properties in generic code if it is useful (e.g. ilp32/lp64/llp64 or the above mentioned endianity), instead of having each backend invent them on their own. So, the question is, do you have any of those implemented in glibc already, or plan to do so soon, and if so, how will the corresponding C header look like. The x86 math-vector.h is wrapped with #if defined __x86_64__ && defined __FAST_MATH__ and thus we really need to limit it to the x32 and x86_64 multilibs, not ia32. BTW, I wonder about the __FAST_MATH__, for C it means we enable those only for -ffast-math or -Ofast, does it mean that for Fortran we enable it even with -O2 -ftree-vectorize or -O3? Jakub
On Wed, 2019-02-20 at 10:04 +0000, Richard Sandiford wrote: > > (E.g. __attribute__((vector_size)) never creates an ABI-level SVE vector, > even with -msve-vector-bits=N, but it can create an ABI-level Advanced > SIMD vector.) > > I think we should leave the SVE stuff out for now though. ISTM that: > > !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64') > !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_sve') > > is trying to say that there's both an Advanced SIMD implementation of sin > and an SVE implementation of sin. But AFAICT the patch would just treat > the two the same way when SVE is enabled, which I think in practice means > that both would declare an Advanced SIMD function. It looks like you are right. I did not know that GCC would essentially use the non-SVE vector functions to handle SVE vectors. So right now, GCC doesn't seem to need to differentiate between SVE and non-SVE. > Once we support SVE vector functions, how would the header file declare > the Advanced SIMD function when SVE is enabled on the command line? I guess this is what I was thinking the aarch64_sve if would be for, but there is a difference between supporting SVE (using non-SVE vector functions) and supporting SVE with functions that can take and return an SVE vector. I think that we should use 'if('aarch64_sve')' to mean SVE is enabled and we want GCC to call SVE vector functions. So right now this would always return false, until such time as GCC is changed to do calls with SVE vectors as arguments. Given that it would always return false I guess we could just drop it out for now. Steve Ellcey sellcey@marvell.com FYI: If anyone is interested here is a test program I was compiling to see what GCC does with SVE, I compiled with -march=armv8.5-a, -march=armv8.5-a+sve and -msve-vector-bits=[256,2048,scalable] to see what sort of code got generated. I was a little surprised that using -march=armv8.5-a (without the +sve) and -msve-vector-bits= did not give a warning. Why set sve-vector-bits if SVE is not enabled. __attribute__ ((__simd__ ("notinbranch"))) extern float xsinf (float __x) __attribute__ ((__nothrow__ , __leaf__, __const__)); __attribute__ ((__simd__ ("notinbranch"))) extern float xcosf (float __x) __attribute__ ((__nothrow__ , __leaf__, __const__)); void foo (float * __restrict__ a,float * __restrict__ b,float * __restrict__ c) { int i; for (i = 0; i < 10000; i++) a[i] = xsinf(b[i]) * xcosf(c[i]); }
Steve Ellcey <sellcey@marvell.com> writes: > On Wed, 2019-02-20 at 10:04 +0000, Richard Sandiford wrote: >> (E.g. __attribute__((vector_size)) never creates an ABI-level SVE vector, >> even with -msve-vector-bits=N, but it can create an ABI-level Advanced >> SIMD vector.) >> >> I think we should leave the SVE stuff out for now though. ISTM that: >> >> !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64') >> !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_sve') >> >> is trying to say that there's both an Advanced SIMD implementation of sin >> and an SVE implementation of sin. But AFAICT the patch would just treat >> the two the same way when SVE is enabled, which I think in practice means >> that both would declare an Advanced SIMD function. > > It looks like you are right. I did not know that GCC would essentially > use the non-SVE vector functions to handle SVE vectors. So right now, > GCC doesn't seem to need to differentiate between SVE and non-SVE. > >> Once we support SVE vector functions, how would the header file declare >> the Advanced SIMD function when SVE is enabled on the command line? > > I guess this is what I was thinking the aarch64_sve if would be for, > but there is a difference between supporting SVE (using non-SVE vector > functions) and supporting SVE with functions that can take and return > an SVE vector. I think that we should use 'if('aarch64_sve')' to mean > SVE is enabled and we want GCC to call SVE vector functions. So right > now this would always return false, until such time as GCC is changed > to do calls with SVE vectors as arguments. That isn't a global decision though. Whether we use SVE or not when it's available depends on the context. The ideal would be to try both SVE and Advanced SIMD and pick whichever gives the lowest cost. (We're hoping to do that for GCC 10.) The header file should just declare the functions that are available. That includes declaring SVE versions even if SVE is currently disabled, because SVE could be enabled later using target pragmas or target_clones attributes (one we support those). We might want a new syntax for this. > Given that it would always return false I guess we could just drop it > out for now. Yeah, agreed. > FYI: If anyone is interested here is a test program I was compiling to > see what GCC does with SVE, I compiled with -march=armv8.5-a, > -march=armv8.5-a+sve and -msve-vector-bits=[256,2048,scalable] to see > what sort of code got generated. I was a little surprised that using > -march=armv8.5-a (without the +sve) and -msve-vector-bits= did not give > a warning. Why set sve-vector-bits if SVE is not enabled. The idea was that -msve-vector-bits= would still affect any SVE-specific code in a TU that contains both SVE and non-SVE code. E.g. if you use target_clones (again once it's supported) to provide SVE and non-SVE versions of a function, the -msve-vector-bits= would affect the SVE version. I'm torn about about whether we should proactively add the ILP32 and big-endian conditions now or wait until there's a specific need. Unless anyone strongly objects, let's keep them for now. Thanks, Richard
On Tue, 2019-02-26 at 10:17 +0000, Richard Sandiford wrote: > > I'm torn about about whether we should proactively add the ILP32 and > big-endian conditions now or wait until there's a specific need. > Unless anyone strongly objects, let's keep them for now. > > Thanks, > Richard OK, here is a new patch with the ILP32 and big-endian conditions still in place but the sve stuff removed. Retested on aarch64 with no regressions. OK for checkin? Steve Ellcey sellcey@marvell.com 2018-02-26 Steve Ellcey <sellcey@marvell.com> * config/aarch64/aarch64.c (aarch64_get_multilib_abi_name): New function. (TARGET_GET_MULTILIB_ABI_NAME): New macro. 2018-02-26 Steve Ellcey <sellcey@marvell.com> * gfortran.dg/simd-builtins-1.f90: Update for aarch64*-*-*. * gfortran.dg/simd-builtins-2.f90: Ditto. * gfortran.dg/simd-builtins-6.f90: Ditto. * gfortran.dg/simd-builtins-8.f90: New test. * gfortran.dg/simd-builtins-8.h: New header file. diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index 91e79d3..b8125d5 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -18722,6 +18722,17 @@ aarch64_comp_type_attributes (const_tree type1, const_tree type2) return 1; } +/* Implement TARGET_GET_MULTILIB_ABI_NAME */ + +static const char * +aarch64_get_multilib_abi_name (void) +{ + if (TARGET_BIG_END) + return TARGET_ILP32 ? "aarch64_be_ilp32" : "aarch64_be"; + return TARGET_ILP32 ? "aarch64_ilp32" : "aarch64"; +} + + /* Implement TARGET_STACK_PROTECT_GUARD. In case of a global variable based guard use the default else return a null tree. */ @@ -19244,6 +19255,9 @@ aarch64_libgcc_floating_mode_supported_p #undef TARGET_COMP_TYPE_ATTRIBUTES #define TARGET_COMP_TYPE_ATTRIBUTES aarch64_comp_type_attributes +#undef TARGET_GET_MULTILIB_ABI_NAME +#define TARGET_GET_MULTILIB_ABI_NAME aarch64_get_multilib_abi_name + #if CHECKING_P #undef TARGET_RUN_TARGET_SELFTESTS #define TARGET_RUN_TARGET_SELFTESTS selftest::aarch64_run_selftests diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 index 6d79ef8..5cb3eb5 100644 --- a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 @@ -1,5 +1,6 @@ -! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } -! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" } +! { dg-do compile { target i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } } +! { dg-additional-options "-nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" } +! { dg-additional-options "-msse2 -mno-avx" { target i?86-*-linux* x86_64-*-linux* } } program test_overloaded_intrinsic real(4) :: x4(3200), y4(3200) @@ -14,6 +15,7 @@ program test_overloaded_intrinsic print *, y8 end -! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */ -! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ -! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } } +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } +! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } +! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" { target i?86-*-linux* x86_64-*-* } } } +! { dg-final { scan-assembler "bl.*_ZGVnN4v_sinf" { target aarch64*-*-* } } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 index f0e6bc1..2e5bc22 100644 --- a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 +++ b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 @@ -1,11 +1,12 @@ -! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } -! { dg-additional-options "-msse2 -nostdinc -Ofast -fdump-tree-optimized" } +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } } } +! { dg-additional-options "-nostdinc -Ofast -fdump-tree-optimized" } +! { dg-additional-options "-msse2" { target i?86-*-linux* x86_64-*-linux* } } program test_overloaded_intrinsic real(4) :: x4(3200), y4(3200) real(8) :: x8(3200), y8(3200) - ! this should be using simd clone + ! this should not be using simd clone y4 = sin(x4) print *, y4 @@ -18,3 +19,4 @@ end ! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ ! { dg-final { scan-tree-dump-not "simdclone" "optimized" } } */ ! { dg-final { scan-assembler-not "call.*_ZGVbN4v_sinf" } } +! { dg-final { scan-assembler-not "bl.*_ZGVnN4v_sinf" } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 index 2ffa807..60bcac7 100644 --- a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 +++ b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 @@ -1,5 +1,6 @@ -! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } -! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fdump-tree-optimized" } +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } } } +! { dg-additional-options "-nostdinc -Ofast -fdump-tree-optimized" } +! { dg-additional-options "-msse2 -mno-avx" { target i?86-*-linux* x86_64-*-linux* } } !GCC$ builtin (sin) attributes simd (inbranch) !GCC$ builtin (sinf) attributes simd (notinbranch) @@ -21,4 +22,5 @@ end ! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */ ! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ -! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } } +! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" { target i?86-*-linux* x86_64-*-* } } } +! { dg-final { scan-assembler "bl.*_ZGVnN4v_sinf" { target aarch64*-*-* } } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-8.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-8.f90 index e69de29..0237235 100644 --- a/gcc/testsuite/gfortran.dg/simd-builtins-8.f90 +++ b/gcc/testsuite/gfortran.dg/simd-builtins-8.f90 @@ -0,0 +1,19 @@ +! { dg-do compile { target { aarch64*-*-linux* } } } +! { dg-additional-options "-nostdinc -Ofast -fpre-include=simd-builtins-8.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + y4 = sin(x4) + print *, y4 + + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ilp32 } } } */ +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ilp32 } } } */ + +! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64 } } } */ +! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-8.h b/gcc/testsuite/gfortran.dg/simd-builtins-8.h index e69de29..2eade39 100644 --- a/gcc/testsuite/gfortran.dg/simd-builtins-8.h +++ b/gcc/testsuite/gfortran.dg/simd-builtins-8.h @@ -0,0 +1,4 @@ +!GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64') +!GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_be') +!GCC$ builtin (sinf) attributes simd (notinbranch) if('aarch64_ilp32') +!GCC$ builtin (sinf) attributes simd (notinbranch) if('aarch64_be_ilp32')
Steve Ellcey <sellcey@marvell.com> writes: > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c > index 91e79d3..b8125d5 100644 > --- a/gcc/config/aarch64/aarch64.c > +++ b/gcc/config/aarch64/aarch64.c > @@ -18722,6 +18722,17 @@ aarch64_comp_type_attributes (const_tree type1, const_tree type2) > return 1; > } > > +/* Implement TARGET_GET_MULTILIB_ABI_NAME */ > + > +static const char * > +aarch64_get_multilib_abi_name (void) > +{ > + if (TARGET_BIG_END) > + return TARGET_ILP32 ? "aarch64_be_ilp32" : "aarch64_be"; > + return TARGET_ILP32 ? "aarch64_ilp32" : "aarch64"; > +} > + > + Nit: too many blank lines. OK otherwise, thanks. Richard
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 index 6d79ef8dc46..5cb3eb5132a 100644 --- a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 @@ -1,5 +1,6 @@ -! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } -! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" } +! { dg-do compile { target i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } } +! { dg-additional-options "-nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" } +! { dg-additional-options "-msse2 -mno-avx" { target i?86-*-linux* x86_64-*-linux* } } program test_overloaded_intrinsic real(4) :: x4(3200), y4(3200) @@ -14,6 +15,7 @@ program test_overloaded_intrinsic print *, y8 end -! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */ -! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ -! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } } +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } +! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } +! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" { target i?86-*-linux* x86_64-*-* } } } +! { dg-final { scan-assembler "bl.*_ZGVnN4v_sinf" { target aarch64*-*-* } } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 index f0e6bc13862..2e5bc22716b 100644 --- a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 +++ b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 @@ -1,11 +1,12 @@ -! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } -! { dg-additional-options "-msse2 -nostdinc -Ofast -fdump-tree-optimized" } +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } } } +! { dg-additional-options "-nostdinc -Ofast -fdump-tree-optimized" } +! { dg-additional-options "-msse2" { target i?86-*-linux* x86_64-*-linux* } } program test_overloaded_intrinsic real(4) :: x4(3200), y4(3200) real(8) :: x8(3200), y8(3200) - ! this should be using simd clone + ! this should not be using simd clone y4 = sin(x4) print *, y4 @@ -18,3 +19,4 @@ end ! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ ! { dg-final { scan-tree-dump-not "simdclone" "optimized" } } */ ! { dg-final { scan-assembler-not "call.*_ZGVbN4v_sinf" } } +! { dg-final { scan-assembler-not "bl.*_ZGVnN4v_sinf" } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 index 2ffa807e6b6..60bcac78f3e 100644 --- a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 +++ b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 @@ -1,5 +1,6 @@ -! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } -! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fdump-tree-optimized" } +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } } } +! { dg-additional-options "-nostdinc -Ofast -fdump-tree-optimized" } +! { dg-additional-options "-msse2 -mno-avx" { target i?86-*-linux* x86_64-*-linux* } } !GCC$ builtin (sin) attributes simd (inbranch) !GCC$ builtin (sinf) attributes simd (notinbranch) @@ -21,4 +22,5 @@ end ! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */ ! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ -! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } } +! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" { target i?86-*-linux* x86_64-*-* } } } +! { dg-final { scan-assembler "bl.*_ZGVnN4v_sinf" { target aarch64*-*-* } } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-8.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-8.f90 index e69de29bb2d..0237235b5ae 100644 --- a/gcc/testsuite/gfortran.dg/simd-builtins-8.f90 +++ b/gcc/testsuite/gfortran.dg/simd-builtins-8.f90 @@ -0,0 +1,19 @@ +! { dg-do compile { target { aarch64*-*-linux* } } } +! { dg-additional-options "-nostdinc -Ofast -fpre-include=simd-builtins-8.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + y4 = sin(x4) + print *, y4 + + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ilp32 } } } */ +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ilp32 } } } */ + +! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64 } } } */ +! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-8.h b/gcc/testsuite/gfortran.dg/simd-builtins-8.h index e69de29bb2d..610fd52a535 100644 --- a/gcc/testsuite/gfortran.dg/simd-builtins-8.h +++ b/gcc/testsuite/gfortran.dg/simd-builtins-8.h @@ -0,0 +1,8 @@ +!GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64') +!GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_sve') +!GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_be') +!GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_be_sve') +!GCC$ builtin (sinf) attributes simd (notinbranch) if('aarch64_ilp32') +!GCC$ builtin (sinf) attributes simd (notinbranch) if('aarch64_ilp32_sve') +!GCC$ builtin (sinf) attributes simd (notinbranch) if('aarch64_be_ilp32') +!GCC$ builtin (sinf) attributes simd (notinbranch) if('aarch64_be_ilp32_sve')