Re: [PATCH] amdgcn: Enable SIMD vectorization of math functions

[Tobias Burnus <tobias@codesourcery.com>]

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