On Tue, Apr 17, 2018 at 3:54 PM, Szabolcs Nagy <szabolcs.n...@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 <ja...@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.

Reply via email to