[PATCH][RFC]Overloading intrinsics

[Richard Biener]

On Fri, Nov 2, 2018 at 8:21 PM Thomas Koenig <tkoenig@netcologne.de> wrote:
>
> Am 02.11.18 um 09:18 schrieb Richard Biener:
> > On Thu, Nov 1, 2018 at 8:40 PM Thomas Koenig <tkoenig@netcologne.de> wrote:
> >>
> >> Hi Martin,
> >>
> >>> module vector_math
> >>>     interface
> >>>       elemental function sin(arg)
> >>>         !GCC$ attributes simd_notinbranch :: sin
> >>>         real, intent(in) :: arg
> >>>         real :: sin
> >>>       end function sin
> >>>     end interface
> >>> end module
> >>
> >> I'm glad that this project we discussed at the GNU Cauldron is
> >> moving forward!
> >>
> >> Regarding the syntax: I am not sure that using an external function
> >> and then trying to coerce it to an intrinsic is something that is
> >> easily or cleanly done (as you yourself noted).
> >>
> >> Would it be possible to use something like
> >>
> >> module x
> >>     !GCC$ attributes simd_notinbranch, real(4) :: sin
> >>     !GCC$ attributes simd_notinbranch, real(8) :: sin
> >> end module x
> >
> > That might very well work better indeed.
>
> Mabe it would not even need a module - just having encountered
> the attributes line could be enough to modify the declaration.
>
> > Are there any
> > math library routines that are _not_ intrinsics?
>
> If you mean glibc math functions, there are a few missing -
> Fortran does not have cbrt, copysign and exp2, just to mention the
> first few that strike me reading the list in alphabetical order.
>
> > Are all
> > builtins we initialize through mathbuiltins.def also
> > Fortran intrinsics?
>
> You have to be a bit careful here about generic functions (which many
> of the intrinsics are). For example, in Fortran, SIN is a generic
> function which can take different argument types.  This is then
> mapped to the specific function, which may be something like
> __builtin_sinf.
>
> > The important implementation detail
> > is that we need to amend those builtin declarations via
> > the module - so one of my thoughts (for future improvement...)
> > would be to re-organize the mathbuiltins.def thing more
> > like an intrinsic module that is unconditionally USEd.  Of
> > course if there's no way to "declare" an intrinsic in fortran
> > syntax that becomes somewhat difficult.
>
> I'm not sure we really need a module. Just modifying the
> declarations (changing whatever generates the declaration
> of __builtin_sinf to use something else) directly might
> be enough.

Hmm, OK.  So of course I originally thought of doing
an "include file" but a module looked more "modern"...

So if we'd instead do sth like the C -include command-line
option and have glibc just produce a textual file with
!GCC$ attributes lines then would that work when being
pre-"included" to each fortran source?  That would even
solve the issue of having multiple .mod variants for
several GCC versions...

> Actually, you can affirm that something is an intrinsic
> function, via the INTRINSIC statement or attribute.
> You can't do that twice, though, but something like
>
> intrinsic :: sin
> !GCC$ attributes simd_notinbranch, real(4) :: sin
> !GCC$ attributes simd_notinbranch, real(8) :: sin
>
> would be legal.
>
> (The intended use of INTRINSIC is something else:
> A compiler can provide additional intrinsics, more than
> what the languages specifies. This ist mostly harmless because
> a user can still use the name for his own variables or
> procedures.  However, if you use these extensions, it
> is sometimes a good idea to specify them as INTRINSIC,
> so that if you try to compile the code with another
> compiler, you get at least a clean error message).
>
> Regards
>
>         Thomas