[PATCH][RFC]Overloading intrinsics

[Martin Liška]

On 11/9/18 4:33 PM, Richard Biener wrote:
> 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.

Good, you already mentioned that in previous emails.

I'm sending another version of the patch that implements that. I know we are quite
close to the end of stage1, but I would be very happy to have it included in GCC 9.1.
Is it doable?

Thanks,
Martin

> 
> Richard.
> 
>> Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Come-up-with-fvectorized-functions.patch
Type: text/x-patch
Size: 9336 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20181110/c9ae465f/attachment.bin>