Hi Richard, hi all,
On 01.03.23 09:18, Richard Biener via Gcc-patches wrote:
I thought we were moving towards using the simd attribute instead and
moving away from these kind of patches.
Though since gcn is a special target that including math.h normally
does not happen for offloading this might be still usefull.
Yes, this particular target hook is considered legacy. See how for example
glibc provides a math-vector-fortran.h file announcing them to the fortran
compiler in case you were wondering how to target non-C family frontends.
[Not having looked in depth at the patch, the Newlib libm patches, and at this
suggestion.]
With offloading there is the problem that we only parse the C/C++/Fortran code
only once - targeting the host compiler - and then use the the intermediate
representation both for generating the code for that system (like: x86-64) but
also
for the offload region (like: gcn).
At the moment, I fail how to easily handle this. For instance, 'gamma' is not
offered
for x86-64 by glibc's libm (as SIMD) but Newlib for gcn has it (according to
Kwok's patch).
I could imagine some dance with
omp declare variant match(device={arch(gcn)})
combined with 'declare simd' for the arch variants to get this working.
Ignoring some potential issues with declare variant and getting the code only
active on
one device and not on the host and issues surrounded that, we still need to get
this
into the compiler while parsing.
I think this means creating some 'math-extra.h' included in GCC; this then
needs to be
included at parse time into C/C++/fortran (at least when compiling with
-fopenmp or
-fopenacc for if ENABLE_OFFLOADING) and will provide the 'declare variant' +
'declare simd'.
At least I don't see any other way - and as we have functions in both GLIBC and
Newlib,
I don't see how any header file not maintained by + shipping with GCC would
work.
Thoughts on this?
Regarding the current SIMD use, see:
For Fortran, GLIBC has:
/usr/include/finclude/math-vector-fortran.h
!GCC$ builtin (pow) attributes simd (notinbranch) if('x86_64')
→
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/finclude/math-vector-fortran.h;hb=refs/heads/master
For "math.h" users (C, C++), GLICB has:
/usr/include/x86_64-linux-gnu/bits/math-vector.h
#if defined __x86_64__ && defined __FAST_MATH__
...
# define __DECL_SIMD_x86_64 _Pragma ("omp declare simd notinbranch")
# elif __GNUC_PREREQ (6,0)
/* W/o OpenMP use GCC 6.* __attribute__ ((__simd__)). */
# define __DECL_SIMD_x86_64 __attribute__ ((__simd__ ("notinbranch")))
...
# define __DECL_SIMD_cos __DECL_SIMD_x86_64
→
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;hb=refs/heads/master
For completeness, there were a while (2-3 years ago) some patches to extend the
SIMD support for AMD.
And LLVM, that parses the source files multiple times, not only partially
avoids this issue
by including the offload-target's header files - it has some target specific .h
of its own
like:
https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/__clang_cuda_math.h
https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/__clang_hip_math.h
which runs directly the vendor math functions.
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
