[PATCH][RFC]Overloading intrinsics

[Richard Biener]

On Fri, Nov 9, 2018 at 3:16 PM Martin Liška <mliska@suse.cz> wrote:
>
> On 11/9/18 12:59 PM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 7:39 PM Thomas Koenig <tkoenig@netcologne.de> wrote:
> >>
> >> Am 08.11.18 um 14:33 schrieb Martin Liška:
> >>> As Richi mentioned, the list of middle-end built-ins does not scale well.
> >>
> >> It is not clear to me what that means. Could you elaborate?
> >> At the moment, this would still be my preferred solution.
> >>
> >> (If it is a problem of too-long lines:  Repeated uses of the
> >> option with different names should just work, or can
> >> be made to work).
> >>
> >>> So the way discussed in this sub-thread looks preferred.
> >>
> >> I have given this some more thought.
> >>
> >> First, any solution should include sincos and other functions
> >> that are not Fortran intrnisics.
> >
> > As I said I agree with the fact that the Fortran FE needs to annotate
> > the middle-end builtins.  That means we are talking about a way
> > to declare/amend the C ABI math functions with additional attributes.
> >
> > This means that technically using
> >
> > intrinsic :: ...
> >
> > isn't correct.  That leaves us with the choice of adding a custom
> > "pragma" where we can of course choose the syntax freely.
> > I guess
> >
> > !GCC$ ...
> >
> > at the start of a translation unit doesn't affect any behavior you
> > quote below.
> >
> > Whether the proposed syntax needs to mimic fortran syntax
> > remains a question but a simplistic
> >
> > !GCC$ builtin "sinf" attributes omp-simd-notinbranch
> >
> > would work up to the point where when parsing this the FE needs
> > to lookup the corresponding builtin for "sinf".  math-builtins.def
> > seems to only contain the unsuffixed names and we likely build
> > variants with f and l somewhere during processing.  But eventually
> > we should be able to process math-builtins.def for this lookup
> > (and ignore ones that are not listed given the user would have to
> > declare a fortran function with appropriate C binding himself).
> >
> > Note that the sincos vectorized variant from glibc is useless
> > (it uses the wrong ABI)
> >
> >> Second, if you include any additional lines from an external
> >> file, they have to be syntactially valid outside any translation
> >> unit, or you will run into the exact problem that you
> >> describe below:
> >>
> >>> Does it mean that the '#include "vector-math.f90"' should be put before
> >>> a program directive?
> >>
> >> The problem is that you can start a valid program without a PROGRAM
> >> statement, so
> >>
> >>         intrnisic :: sin
> >>         end
> >>
> >> is a valid program, and for
> >>
> >>        intrinsic :: sin
> >>        program foo
> >>
> >> the compiler correctly complains.  So, you need to take out the
> >> need for the intrinsic:: sin line.
> >>
> >> (Also, the user is free to declare a variable sin, although it
> >> is not advisable).
> >>
> >>>> So, you could use either the intrinsic name with the precision or (maybe
> >>>> that is an even better idea) the name of the C function that is
> >>>> overloaded.
> >>>
> >>> I've got it. It's implemented in attached patch.
> >>
> >> It's not quite clear to me Which of the two options you mean :-)
> >> Regards
> >>
> >>         Thomas
> Hi.
>
> I'm attaching patch draft that can leverage defined syntax:
>
> $ cat vector-math.f90
> !GCC$ builtin sinf attributes omp_simd_notinbranch
> !GCC$ builtin cosf attributes omp_simd_notinbranch
>
> $ cat usage.F90
> #include "vector-math.f90"
> program test_overloaded_intrinsic
>   real(4) :: x4(3200), y4(3200)
>   real(8) :: x8(3200), y8(3200)
>
>   ! this should be using simd clone
>   y4 = sin(x4)
>   print *, y4
>
>   ! this should not be using simd clone
>   y4 = sin(x8)
>   print *, y8
> end
>
> $ ./xgcc -B. ~/Programming/testcases/usage.F90  -c -Ofast -fdump-tree-optimized=/dev/stdout | grep sin
>   vect__3.14_11 = sinf.simdclone.0 (vect__2.13_61);
>   _6 = __builtin_sin (_5);
>
> The question still remains which way use to provide automatic inclusion of the "header" file?

I'd say go the C family way - add a target hook telling you if and
what to pre-include.

Richard.

> Martin