This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libmvec in gcc to have vector math in fortran
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Janne Blomqvist <blomqvist dot janne at gmail dot com>, nd at arm dot com, GCC Development <gcc at gcc dot gnu dot org>, Fortran List <fortran at gcc dot gnu dot org>, Steve Ellcey <sellcey at cavium dot com>
- Date: Tue, 10 Apr 2018 14:55:43 +0200
- Subject: Re: libmvec in gcc to have vector math in fortran
- References: <6a8d496b-d830-5eb2-eba3-c2e452d06493@arm.com> <CAO9iq9FvH9Mbmec+tDO5_31vaKiu3p=WGhAXuFFUq8EJEeiQ-g@mail.gmail.com> <80c395e1-9de5-1d9c-35b6-1ccfdfa6a9e5@arm.com> <20180410102954.GB8577@tucnak>
On Tue, Apr 10, 2018 at 12:29 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Apr 10, 2018 at 11:22:03AM +0100, Szabolcs Nagy wrote:
>> On 10/04/18 11:14, Janne Blomqvist wrote:
>> > As I mentioned previously in that thread you linked to, the fortran
>> > frontend never generates a direct call to libm sin(), or for that matter
>> > ZGVbN2v_sin(). Instead it generates a "call" to __builtin_sin(). And
>> > similarly for other libm functions that have gcc builtins. The
>> > middle-end optimizers are then free to do whatever optimizations they
>> > like on that __builtin_sin call, such as constant folding, and at least
>> > as far as the fortran frontend is concerned, vectorizing if -mveclibabi=
>> > or such is in effect.
>>
>> the generated builtin call is not the issue (same happens in c),
>> the knowledge about libc declarations is.
>>
>> the middle-end has no idea what functions can be vectorized,
>> only the libc knows it and declares this in c headers.
>>
>> this is the problem i'm trying to solve.
>
> And the easiest solution is in the Fortran FE based on some flag
> (e.g. -mveclibabi=glibc) through a target hook add
> __attribute__((__simd__ ("notinbranch")))
> to the builtins like __builtin_sin etc. that have them in the
> glibc header (x86_64 -m64 and -ffast-math only):
>
> # undef __DECL_SIMD_cos
> # define __DECL_SIMD_cos __DECL_SIMD_x86_64
> # undef __DECL_SIMD_cosf
> # define __DECL_SIMD_cosf __DECL_SIMD_x86_64
> # undef __DECL_SIMD_sin
> # define __DECL_SIMD_sin __DECL_SIMD_x86_64
> # undef __DECL_SIMD_sinf
> # define __DECL_SIMD_sinf __DECL_SIMD_x86_64
> # undef __DECL_SIMD_sincos
> # define __DECL_SIMD_sincos __DECL_SIMD_x86_64
> # undef __DECL_SIMD_sincosf
> # define __DECL_SIMD_sincosf __DECL_SIMD_x86_64
> # undef __DECL_SIMD_log
> # define __DECL_SIMD_log __DECL_SIMD_x86_64
> # undef __DECL_SIMD_logf
> # define __DECL_SIMD_logf __DECL_SIMD_x86_64
> # undef __DECL_SIMD_exp
> # define __DECL_SIMD_exp __DECL_SIMD_x86_64
> # undef __DECL_SIMD_expf
> # define __DECL_SIMD_expf __DECL_SIMD_x86_64
> # undef __DECL_SIMD_pow
> # define __DECL_SIMD_pow __DECL_SIMD_x86_64
> # undef __DECL_SIMD_powf
> # define __DECL_SIMD_powf __DECL_SIMD_x86_64
>
> The sincos/sincosf stuff is questionable, because some glibc versions
> implement it incorrectly and the simd ("notinbranch") attribute isn't that
> useful for it anyway, we'd want to use extra clauses so that it doesn't need
> to do scatter stores.
I wonder if it is possible for glibc to ship a "module" for fortran instead
containing the appropriate declarations and gfortran auto-include that
(if present).
Hard-coding stuff like suggested above is of course possible but not
very forward compatible with changes in glibc.
Richard.
> Jakub