libmvec in gcc to have vector math in fortran

libmvec in gcc to have vector math in fortran

[Szabolcs Nagy]

i had a query earlier about libmvec vector functions in fortran:
https://gcc.gnu.org/ml/gcc/2017-11/msg00007.html

but there were no simple solutions to make math functions vectorizable
in fortran, because it's hard to make libc headers with simd attributes
visible to the fortran front end.

i think a possible workaround is to have a dummy libmvec implementation
in libgcc.a (or more likely as a separate libgccmvec.a) that just calls
scalar functions from libm like

vdouble _ZGVbN2v_sin(vdouble x)
{
   return (vdouble){sin(x[0]), sin(x[1])};
}

and similarly for all relevant single and double precision functions
for all vector lengths and other supported variants.

then gcc knows that there is an implementation for these functions
available and with the right link order a better implementation from
libmvec can override these dummy implementations. (the cost model
cannot assume a faster vector algorithm than the scalar one though)

- this allows vectorizing loops with math functions even in fortran,
- and on targets without a libmvec implementation (but with a vector abi),
- and allows users to provide their own vector math implementation
more easily without hacking around glibc math.h (which may not support
vector math or only enable it for a small subset of math functions).

gcc needs a new cflag and ldflag to enable this.
(maybe -mveclibabi= already present in x86 and ppc can be used for this)

Re: libmvec in gcc to have vector math in fortran

[Janne Blomqvist]

On Tue, Apr 10, 2018 at 12:45 PM, Szabolcs Nagy <szabolcs.nagy@arm.com>
wrote:

> i had a query earlier about libmvec vector functions in fortran:
> https://gcc.gnu.org/ml/gcc/2017-11/msg00007.html
>
> but there were no simple solutions to make math functions vectorizable
> in fortran, because it's hard to make libc headers with simd attributes
> visible to the fortran front end.
>
> i think a possible workaround is to have a dummy libmvec implementation
> in libgcc.a (or more likely as a separate libgccmvec.a) that just calls
> scalar functions from libm like
>
> vdouble _ZGVbN2v_sin(vdouble x)
> {
>   return (vdouble){sin(x[0]), sin(x[1])};
> }
>
> and similarly for all relevant single and double precision functions
> for all vector lengths and other supported variants.
>
> then gcc knows that there is an implementation for these functions
> available and with the right link order a better implementation from
> libmvec can override these dummy implementations. (the cost model
> cannot assume a faster vector algorithm than the scalar one though)
>
> - this allows vectorizing loops with math functions even in fortran,
> - and on targets without a libmvec implementation (but with a vector abi),
> - and allows users to provide their own vector math implementation
> more easily without hacking around glibc math.h (which may not support
> vector math or only enable it for a small subset of math functions).
>
> gcc needs a new cflag and ldflag to enable this.
> (maybe -mveclibabi= already present in x86 and ppc can be used for this)
>
>
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.

-- 
Janne Blomqvist

Re: libmvec in gcc to have vector math in fortran

[Szabolcs Nagy]

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.

Re: libmvec in gcc to have vector math in fortran

[Jakub Jelinek]

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.

	Jakub

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

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

Re: libmvec in gcc to have vector math in fortran

[Jakub Jelinek]

On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
> > 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).

Then we'd run into module binary format changing every release, so hard for
glibc to ship that.

Another thing is how would we express it in the module,
we could just use OpenMP syntax,
      interface
        function sin(x) bind(C,name="__builtin_sin") result(res)
          import
	  !$omp declare simd notinbranch
          real(c_double) :: res
          real(c_double),value :: x
        end function
      end interface
but we'd need to temporarily enable OpenMP while parsing that module.
I see Fortran now supports already
!GCC$ attributes stdcall, fastcall::test
Could we support
!GCC$ attributes simd
and
!GCC$ attributes simd('notinbranch')
too?

	Jakub

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek <jakub@redhat.com> wrote:
>On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
>> > 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).
>
>Then we'd run into module binary format changing every release, so hard
>for
>glibc to ship that.

It's just nobody bothered to implement version dependent parsing (it's plain text after all). 

>Another thing is how would we express it in the module,
>we could just use OpenMP syntax,
>      interface
>        function sin(x) bind(C,name="__builtin_sin") result(res)
>          import
>	  !$omp declare simd notinbranch
>          real(c_double) :: res
>          real(c_double),value :: x
>        end function
>      end interface
>but we'd need to temporarily enable OpenMP while parsing that module.
>I see Fortran now supports already
>!GCC$ attributes stdcall, fastcall::test
>Could we support
>!GCC$ attributes simd
>and
>!GCC$ attributes simd('notinbranch')
>too?

I guess that would be useful indeed. 

Richard. 

>	Jakub

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek <jakub@redhat.com> wrote:
>On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
>> > 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).
>
>Then we'd run into module binary format changing every release, so hard
>for
>glibc to ship that.
>
>Another thing is how would we express it in the module,
>we could just use OpenMP syntax,
>      interface
>        function sin(x) bind(C,name="__builtin_sin") result(res)
>          import
>	  !$omp declare simd notinbranch
>          real(c_double) :: res
>          real(c_double),value :: x
>        end function
>      end interface
>but we'd need to temporarily enable OpenMP while parsing that module.
>I see Fortran now supports already
>!GCC$ attributes stdcall, fastcall::test
>Could we support
>!GCC$ attributes simd
>and
>!GCC$ attributes simd('notinbranch')
>too?

Maybe we can also generate this module in a fixinlclude way? 

>	Jakub

Re: libmvec in gcc to have vector math in fortran

[Szabolcs Nagy]

On 10/04/18 14:27, Richard Biener wrote:
> On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
>>> 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).
>>
>> Then we'd run into module binary format changing every release, so hard
>> for
>> glibc to ship that.
>>
>> Another thing is how would we express it in the module,
>> we could just use OpenMP syntax,
>>       interface
>>         function sin(x) bind(C,name="__builtin_sin") result(res)
>>           import
>> 	  !$omp declare simd notinbranch
>>           real(c_double) :: res
>>           real(c_double),value :: x
>>         end function
>>       end interface
>> but we'd need to temporarily enable OpenMP while parsing that module.
>> I see Fortran now supports already
>> !GCC$ attributes stdcall, fastcall::test
>> Could we support
>> !GCC$ attributes simd
>> and
>> !GCC$ attributes simd('notinbranch')
>> too?
> 
> Maybe we can also generate this module in a fixinlclude way?
> 

ideally everything should work magically but i think
it's good to have a big hammer solution that's easy
to reason about.

the gcc vectorizer should be testable independently
of glibc, and users should be able to specify what
can be vectorized.

if this is via a per-frontend declaration syntax,
then i see implementation and usability issues, while
those are sorted out a single flag that requests every
function known to gcc to be vectorized sounds to me a
viable big hammer solution: easy to implement and
enables users to start experimenting with simd math.

(the implementation may use a preincluded fortran
module internally, but i think it makes sense to
have a single flag ui too)

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On Tue, Apr 17, 2018 at 3:54 PM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 10/04/18 14:27, Richard Biener wrote:
>>
>> On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek <jakub@redhat.com>
>> wrote:
>>>
>>> On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
>>>>
>>>> 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).
>>>
>>>
>>> Then we'd run into module binary format changing every release, so hard
>>> for
>>> glibc to ship that.
>>>
>>> Another thing is how would we express it in the module,
>>> we could just use OpenMP syntax,
>>>       interface
>>>         function sin(x) bind(C,name="__builtin_sin") result(res)
>>>           import
>>>           !$omp declare simd notinbranch
>>>           real(c_double) :: res
>>>           real(c_double),value :: x
>>>         end function
>>>       end interface
>>> but we'd need to temporarily enable OpenMP while parsing that module.
>>> I see Fortran now supports already
>>> !GCC$ attributes stdcall, fastcall::test
>>> Could we support
>>> !GCC$ attributes simd
>>> and
>>> !GCC$ attributes simd('notinbranch')
>>> too?
>>
>>
>> Maybe we can also generate this module in a fixinlclude way?
>>
>
> ideally everything should work magically but i think
> it's good to have a big hammer solution that's easy
> to reason about.
>
> the gcc vectorizer should be testable independently
> of glibc, and users should be able to specify what
> can be vectorized.
>
> if this is via a per-frontend declaration syntax,
> then i see implementation and usability issues, while
> those are sorted out a single flag that requests every
> function known to gcc to be vectorized sounds to me a
> viable big hammer solution: easy to implement and
> enables users to start experimenting with simd math.
>
> (the implementation may use a preincluded fortran
> module internally, but i think it makes sense to
> have a single flag ui too)

OK, so we could add a -fveclibabi=openmp which means
implicitely annotating all math (or others we see fit) builtins
with openmp-simd.

But then the user has to provide a library with implementations.
Or we arrange for them to be emitted in each TU, somehow
weakly binding, if the target supports that, implementing the
desired ABI but using trivial implementations dispatching to
the scalar libm routines.

Richard.

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On Tue, Apr 10, 2018 at 3:07 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
> > > 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).
>
> Then we'd run into module binary format changing every release, so hard for
> glibc to ship that.
>
> Another thing is how would we express it in the module,
> we could just use OpenMP syntax,
>       interface
>         function sin(x) bind(C,name="__builtin_sin") result(res)
>           import
>           !$omp declare simd notinbranch
>           real(c_double) :: res
>           real(c_double),value :: x
>         end function
>       end interface
> but we'd need to temporarily enable OpenMP while parsing that module.

As-is the above doesn't work - it doesn't seem to redeclare sin() in a way
that it is 'const', thus dependence analysis rejects calls to it.

I'm playing with the following

subroutine bar (a)
  use, intrinsic :: iso_c_binding, only: c_double
  interface
    pure function sin(x) bind(C,name="sin") result(res)
     !$omp declare simd notinbranch
     import
     real(c_double) :: res
     real(c_double),value :: x
  end function sin
  end interface
  real(8) a(100,100)
  do I=1,100
   do J = 1,100
    a(j,i) = sin(a(j,i))
   end do
 end do
end subroutine bar

'pure' makes it pure but there doesn't seem to be a way to make it const?
Any hint on how to improve the interface above?  With
-fopemp -fopenmp-simd -Ofast the loop should be vectorized
(if I got index order correct).

That is, fortran doesn't seem to do anything like "merging" the above
declaration with the existing builtin so the binding above needs to be
complete.

I'm still thinking of exposing libmvec using a include/module that gets
implicitely picked up by gfortran if present.

Richard.

> I see Fortran now supports already
> !GCC$ attributes stdcall, fastcall::test
> Could we support
> !GCC$ attributes simd
> and
> !GCC$ attributes simd('notinbranch')
> too?
>
>         Jakub

Re: libmvec in gcc to have vector math in fortran

[Florian Weimer]

* Richard Biener:

> 'pure' makes it pure but there doesn't seem to be a way to make it const?

Does Fortran support setting the rounding mode?

In C, sin is not const because it depends on the current rounding
mode.

Re: libmvec in gcc to have vector math in fortran

[Szabolcs Nagy]

On 15/06/18 08:59, Florian Weimer wrote:
> * Richard Biener:
> 
>> 'pure' makes it pure but there doesn't seem to be a way to make it const?
> 
> Does Fortran support setting the rounding mode?
> 

yes, but vec math is only enabled with -ffast-math (so it can
assume -fno-rounding-math)

> In C, sin is not const because it depends on the current rounding
> mode.
> 

hm i don't see const in glibc even in case of -ffast-math compilation,
i wonder if that can be changed.

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On Fri, Jun 15, 2018 at 10:39 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> On 15/06/18 08:59, Florian Weimer wrote:
> > * Richard Biener:
> >
> >> 'pure' makes it pure but there doesn't seem to be a way to make it const?
> >
> > Does Fortran support setting the rounding mode?
> >
>
> yes, but vec math is only enabled with -ffast-math (so it can
> assume -fno-rounding-math)
>
> > In C, sin is not const because it depends on the current rounding
> > mode.
> >
>
> hm i don't see const in glibc even in case of -ffast-math compilation,
> i wonder if that can be changed.

For sin() it also depends on -fno-math-errno (default for fortran) given
sin() may set errno according to the manpage (that means it isn't
even pure by default).

Richard.

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On Fri, Jun 15, 2018 at 9:59 AM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Richard Biener:
>
> > 'pure' makes it pure but there doesn't seem to be a way to make it const?
>
> Does Fortran support setting the rounding mode?
>
> In C, sin is not const because it depends on the current rounding
> mode.

It is (well, the GCC builtin) by default because -fno-rounding-math
is default.  Note that using "reads global memory" (aka pure and not
const) is a bit of a stretch for "accesses the FP state" ;)  It's basically
a workaround for the fact that GCC doesn't "implement" FENV access.

That said, good to see some glibc folks jump in on this thread.
I'd like to see glibc provide a fortran intrinsic header advertising
the libmvec routines it has.  We probably do need some gfortran
adjustments here but I think that glibc advertising is better than
hard-coding lists into GCC (like we do for some targets with
their -mveclibabi= option).

Richard.

Re: libmvec in gcc to have vector math in fortran

[Florian Weimer]

* Richard Biener:

> That said, good to see some glibc folks jump in on this thread.
> I'd like to see glibc provide a fortran intrinsic header advertising
> the libmvec routines it has.  We probably do need some gfortran
> adjustments here but I think that glibc advertising is better than
> hard-coding lists into GCC (like we do for some targets with
> their -mveclibabi= option).

The advantage of putting into GCC is that it will work irrespective of
the installed glibc header version, so if we get this going:

  <https://sourceware.org/ml/libc-alpha/2018-05/msg00501.html>

you could use libmvec along with really old glibcs (probably as far
back as 2.12, maybe even older).

But then we might into a different direction altogether.

Another question is wheter the Fortran header can be generated by
something like -fdump-ada-spec, so that we don't have to maintain it
separately from the C header.

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On Fri, Jun 15, 2018 at 11:08 AM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Richard Biener:
>
> > That said, good to see some glibc folks jump in on this thread.
> > I'd like to see glibc provide a fortran intrinsic header advertising
> > the libmvec routines it has.  We probably do need some gfortran
> > adjustments here but I think that glibc advertising is better than
> > hard-coding lists into GCC (like we do for some targets with
> > their -mveclibabi= option).
>
> The advantage of putting into GCC is that it will work irrespective of
> the installed glibc header version, so if we get this going:
>
>   <https://sourceware.org/ml/libc-alpha/2018-05/msg00501.html>
>
> you could use libmvec along with really old glibcs (probably as far
> back as 2.12, maybe even older).

Well, ok - I obviously meant bundling the header with libmvec, not with
glibc (which currently is the same).

Putting it into GCC means that you have mismatches in both directions.

I was also considering to somehow auto-generate a header based
on what the C headers advertise at GCC install time.
[or put a C parser into the fortran frontend, eh...]

> But then we might into a different direction altogether.
>
> Another question is wheter the Fortran header can be generated by
> something like -fdump-ada-spec, so that we don't have to maintain it
> separately from the C header.

Sure, see above - I think that's possible and it doesn't have to be as
complicated as -fdump-ada-spec.  Instead a simple script in your
favorite language will do the job.

First and foremost we need a syntax that actually works for the
Fortran frontend and a way to automatically include this special
header / module.

Richard.

Re: libmvec in gcc to have vector math in fortran

[Thomas Koenig]

Hi Richard,

> First and foremost we need a syntax that actually works for the
> Fortran frontend and a way to automatically include this special
> header / module.

I can imagine parsing the relevant headers while compiling gfortran
and generating C code from it, which could then be #included in the
compiler source code. It should be possible to extend mathbuiltins.def
that way.

How does that sound?

Regards

	Thomas

Re: libmvec in gcc to have vector math in fortran

[Joseph Myers]

On Fri, 15 Jun 2018, Thomas Koenig wrote:

> Hi Richard,
> 
> > First and foremost we need a syntax that actually works for the
> > Fortran frontend and a way to automatically include this special
> > header / module.
> 
> I can imagine parsing the relevant headers while compiling gfortran
> and generating C code from it, which could then be #included in the
> compiler source code. It should be possible to extend mathbuiltins.def
> that way.

The libmvec functions present depend on the multilib (for example, glibc 
only currently supports them for x86_64, not for 32-bit x86).  Given this 
multilib dependence, parsing the glibc headers when building the compiler 
itself is probably not a sensible option.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On Fri, Jun 15, 2018 at 10:59 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Fri, 15 Jun 2018, Thomas Koenig wrote:
>
> > Hi Richard,
> >
> > > First and foremost we need a syntax that actually works for the
> > > Fortran frontend and a way to automatically include this special
> > > header / module.
> >
> > I can imagine parsing the relevant headers while compiling gfortran
> > and generating C code from it, which could then be #included in the
> > compiler source code. It should be possible to extend mathbuiltins.def
> > that way.
>
> The libmvec functions present depend on the multilib (for example, glibc
> only currently supports them for x86_64, not for 32-bit x86).  Given this
> multilib dependence, parsing the glibc headers when building the compiler
> itself is probably not a sensible option.

I'm thinking of sth like the C stdc-predef.h header which is always included
by the compiler.  So it needs to be sth parseable by gfortran which means
it needs to be a module or sth equivalent to a fortran include file.
GCC supports -include on the command-line, gfortran does not and it
could also support sth like -use FOO to import module FOO.  The rest could
be then done by specs processing (or similar to the stdc-predef.h via
a fortran specific target hook).

Richard.

>
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: libmvec in gcc to have vector math in fortran

[Joseph Myers]

On Mon, 18 Jun 2018, Richard Biener wrote:

> I'm thinking of sth like the C stdc-predef.h header which is always included
> by the compiler.  So it needs to be sth parseable by gfortran which means
> it needs to be a module or sth equivalent to a fortran include file.

To me that suggests something provided by the C library (which might 
contain preprocessor conditionals, the Fortran front end supports 
preprocessing with the target-specific predefined macros being in effect)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On June 18, 2018 5:06:08 PM GMT+02:00, Joseph Myers <joseph@codesourcery.com> wrote:
>On Mon, 18 Jun 2018, Richard Biener wrote:
>
>> I'm thinking of sth like the C stdc-predef.h header which is always
>included
>> by the compiler.  So it needs to be sth parseable by gfortran which
>means
>> it needs to be a module or sth equivalent to a fortran include file.
>
>To me that suggests something provided by the C library (which might 
>contain preprocessor conditionals, the Fortran front end supports 
>preprocessing with the target-specific predefined macros being in
>effect)

Yes. 

Richard.