[PATCH][RFC]Overloading intrinsics
Martin Liška
mliska@suse.cz
Mon Nov 5 13:53:00 GMT 2018
On 11/5/18 11:13 AM, Richard Biener wrote:
> 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
Hi.
Thank you all for comments. I'm sending patch that works with following code snippets:
$ cat usage.F90
program test_overloaded_intrinsic
#include "vector-math.f90"
real :: x(3200), y(3200), z(3200)
! this should be using simd clone
y = sin(x)
print *, y
! this not
z = cos(x)
print *, z
z = sin (z)
print *, z
end
$ cat vector-math.f90
intrinsic :: sin
!GCC$ attributes simd_notinbranch :: sin
$ ./xgcc -B. -Ofast -c ~/Programming/testcases/usage.F90 -fdump-tree-optimized=/dev/stdout | grep sin
vect__3.23_101 = sinf.simdclone.0 (vect__2.22_100);
vect__9.17_87 = sinf.simdclone.0 (vect__8.16_10);
Now the question is how to add a new argument that will implicitly include additional file.
Should that be added to Fortran pre-processor? Hints welcomed.
Note that I removed the ', real(4)' from attribute definition as there's just single gfc_intrinsic_sym
for sin* functions in Fortran FE. Is it fine?
About the math functions that are not intrinsics. If I see correctly current list of vectorized
math functions is here:
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86/fpu/bits/math-vector.h;hb=HEAD
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-simd-attribute-propagation-for-a-vector_math.patch
Type: text/x-patch
Size: 4454 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20181105/9734d63d/attachment.bin>
More information about the Fortran
mailing list