[patch][v2] Fortran: Add OpenMP 'interop' directive parsing support

[Tobias Burnus]

Now also supports the following (note the variable name): 
'init(targetsync, target)' – and I fixed an ICE when the variable 
parsing failed.

Comments before I commit it?

Tobias

Tobias Burnus wrote:
> This patch adds Fortran parsing support for OpenMP's 'interop' 
> directive (which stops with a 'sorry' in trans-openmp.cc as the middle 
> end support is still missing).
>
> Tested on x86-64-gnu-linux.
>
> Comments, suggestions, remarks?
>
> * * *
>
> Background:
>
> 'interop' makes it easier to call, e.g., a CUDA-BLAS function directly 
> as it permits to map an OpenMP device number (→ "target" modifier 
> required) to the "foreign runtime" device number or to get directly a 
> stream object (→ if "targetsync" modifier specified) with dependency 
> tracking.
>
> Just calling '!$omp interop init(obj)' works but that leaves the 
> decision which type of object should be returned to the run time.
>
> Using 'prefer_type', the user can ask for a specific type. Permits is 
> a string such as "hip" or an integer constant such as 
> omp_ifr_cuda_driver – and the old-style syntax is 'prefer_type(<const 
> integer expr|literal string> [ , <c.int expr|string> ...])'.  [Note 
> thatn a constant integer expression is permitted.]
>
> The new syntax permits additional attributes like for 'sycl' 
> requesting an 'in-order' queue (instead of the default 'out-of-order' 
> queue when obtaining a stream. The new syntax is 'prefer_type( {...} 
> [, {...} ... } ) where '{ ... }' is a list of either 
> 'attr("ompx_...")' (i.e. 'attr(...)' with literal string arg that 
> starts with ompx_ and does not contain a ',') or 
> 'fr(<identifier|string literal>)' where the identifier is an integer 
> constant. 'fr' can be present or not, but only once per {...} while 
> multiple 'attr' may be used. [Note that as non-string only an 
> identifier is permitted (i.e. a integer parameter).]
>
> I decided for the used way to encode the string – but I am open to 
> other representations as well. In my WIP/RFC patch is is used as shown 
> in plugin-*.c in the patch 
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661207.html
>
> The available foreign runtimes and values that can be returned values 
> are hidden in that patch and more readable in the documentation patch 
> at https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661365.html
>
> If someone wants to delve into the details of the 'interop' feature: 
> Have a look at OpenMP 5.1 (5.2) *and* TR13 and the additional 
> definition document at https://www.openmp.org/specifications/ ('hsa': 
> publishing pending).
>
> * * *
>
> Tobias
>
> PS: In the dump, I am a bit lazy and add spurious tailing ','. As it 
> is only a dump, I decided adding a bunch of checks to ensure that a 
> ',' only gets printed if needed is not really required. If you think 
> otherwise, I can surely add a bunch of 'if' an only print it 
> conditionally.
>
> PPS: In order to to use 'interop', mainly the part in middle is 
> missing, i.e. some middle-end gimplification with a call into libgomp 
> – and the libgomp function. A stub version of the latter and some 
> (loosely) tested plugin handling does exist as WIP/RFC patch, see 
> patch link above. - Besides gimplify and the libgomp function, a bunch 
> of tests and, obviously, the C and C++ FE counterpart to this patch 
> have to be implemented.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interop-fortran-FE-v2.diff
Type: text/x-patch
Size: 42715 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20240905/25712398/attachment-0001.bin>