Revert changelog conflict

Author: LonelyCat124

changelog

@@ -1,4 +1,11 @@
-   2) PR #3464 towards #3463. Reverse the order to build maximal regions.
+   4) PR #3465 for #2757. Adds the --script-kwargs command line
+   option to pass arguments to transformation scripts.
+ 
+   3) PR #3480 for #3478. Updates OMPParallelLoopTrans to correctly
+   use the kwargs approach.
+
+   2) PR #3455 for #3170. Adds support for fields and operators with
+   explicit real32 and real64 kinds.
 
    1) PR #3472 for #3471. Let the transformations get_options method
    account for sub-transformation options.

config/psyclone.cfg

@@ -91,7 +91,9 @@ precision_map = i_def: 4,
                 r_solver: 4,
                 r_tran: 8,
                 r_bl: 8,
-                r_um: 8
+                r_um: 8,
+                real64: 8,
+                real32: 4
 
 # Specify whether we generate code to perform runtime correctness checks.
 # Allowed values:

doc/user_guide/getting_going.rst

@@ -191,8 +191,6 @@ command. To list the available options run: ``psyclone -h``, it should output::
       -v, --version         display version information
       -c CONFIG, --config CONFIG
                             config file with PSyclone specific options
-      -s SCRIPT, --script SCRIPT
-                            filename of a PSyclone optimisation recipe
       --enable-cache        whether to enable caching of imported module dependencies (if
                             enabled, it will generate a .psycache file of each imported module in
                             the same location as the imported source file).
@@ -230,6 +228,12 @@ command. To list the available options run: ``psyclone -h``, it should output::
       --fixed-form          forces PSyclone to parse this file as fixed format (default is to
                             look at the input file extension).
 
+    Transformation scripts:
+      -s SCRIPT, --script SCRIPT
+                            filename of a PSyclone optimisation recipe
+      --script-kwargs SCRIPT_KWARGS
+                            Keyword arguments for the transformation script.
+
     Directory management:
       -I INCLUDE, --include INCLUDE
                             path to Fortran INCLUDE or module files

doc/user_guide/lfric.rst

@@ -432,7 +432,7 @@ Mixed Precision
 
 The LFRic API supports the ability to specify the precision required
 by the model via precision variables. To make use of this, the code
-developer must declare scalars, arrays, fields and operators in the algorithm
+developer must declare scalars, arrays, fields and operators in the Algorithm
 layer with the required LFRic-supported precision. In the current
 implementation there are two supported precisions for ``REAL`` data and
 one each for ``INTEGER`` and ``LOGICAL`` data. The actual precision used in
@@ -471,6 +471,10 @@ associated kernel metadata description and their precision:
 +--------------------------+---------------------------------------+-----------+
 | R_TRAN_FIELD_TYPE        | GH_FIELD, GH_REAL                     | R_TRAN    |
 +--------------------------+---------------------------------------+-----------+
+| FIELD_REAL32_TYPE        | GH_FIELD, GH_REAL                     | REAL32    |
++--------------------------+---------------------------------------+-----------+
+| FIELD_REAL64_TYPE        | GH_FIELD, GH_REAL                     | REAL64    |
++--------------------------+---------------------------------------+-----------+
 | INTEGER_FIELD_TYPE       | GH_FIELD, GH_INTEGER                  | I_DEF     |
 +--------------------------+---------------------------------------+-----------+
 | OPERATOR_TYPE            | GH_OPERATOR, GH_REAL                  | R_DEF     |
@@ -479,13 +483,18 @@ associated kernel metadata description and their precision:
 +--------------------------+---------------------------------------+-----------+
 | R_TRAN_OPERATOR_TYPE     | GH_OPERATOR, GH_REAL                  | R_TRAN    |
 +--------------------------+---------------------------------------+-----------+
+| OPERATOR_REAL32_TYPE     | GH_OPERATOR, GH_REAL                  | REAL32    |
++--------------------------+---------------------------------------+-----------+
+| OPERATOR_REAL64_TYPE     | GH_OPERATOR, GH_REAL                  | REAL64    |
++--------------------------+---------------------------------------+-----------+
 | COLUMNWISE_OPERATOR_TYPE | GH_COLUMNWISE_OPERATOR, GH_REAL       | R_SOLVER  |
 +--------------------------+---------------------------------------+-----------+
 
 As can be seen from the above table, the kernel metadata does not
 capture all of the precision options. For example, from the metadata
 it is not possible to determine whether a ``REAL`` scalar, ``REAL`` field
-or ``REAL`` operator has precision ``R_DEF``, ``R_SOLVER`` or ``R_TRAN``.
+or ``REAL`` operator has precision ``R_DEF``, ``R_SOLVER``, ``R_TRAN``
+or one of the Fortran intrinsic precisions (``REAL32``, ``REAL64``).
 
 If a scalar, array, field, or operator is specified with a particular
 precision in the algorithm layer then any associated kernels that it
@@ -601,6 +610,10 @@ outlined in the table below:
 +-------------------------+------------------+--------------+
 | ``r_tran_field_type``   | ``real``         | ``r_tran``   |
 +-------------------------+------------------+--------------+
+| ``field_real32_type``   | ``real``         | ``real32``   |
++-------------------------+------------------+--------------+
+| ``field_real64_type``   | ``real``         | ``real64``   |
++-------------------------+------------------+--------------+
 | ``integer_field_type``  | ``integer``      | ``i_def``    |
 +-------------------------+------------------+--------------+
 
@@ -701,7 +714,8 @@ a message that indicates the problem.
 | Fortran Datatype | Supported Precision      |
 +==================+==========================+
 | ``real``         | ``r_def``, ``r_bl``,     |
-|                  | ``r_solver``, ``r_tran`` |
+|                  | ``r_solver``, ``r_tran``,|
+|                  | ``real32``, ``real64``   |
 +------------------+--------------------------+
 | ``integer``      | ``i_def``                |
 +------------------+--------------------------+
@@ -731,6 +745,10 @@ outlined in the table below:
 +----------------------------+------------------+--------------+
 | ``r_tran_operator_type``   | ``real``         | ``r_tran``   |
 +----------------------------+------------------+--------------+
+| ``operator_real32_type``   | ``real``         | ``real32``   |
++----------------------------+------------------+--------------+
+| ``operator_real64_type``   | ``real``         | ``real64``   |
++----------------------------+------------------+--------------+
 
 .. _lfric-mixed-precision-cma-operators:
 

doc/user_guide/psyclone_command.rst

@@ -74,8 +74,6 @@ by the command:
       -v, --version         display version information
       -c CONFIG, --config CONFIG
                             config file with PSyclone specific options
-      -s SCRIPT, --script SCRIPT
-                            filename of a PSyclone optimisation recipe
       --enable-cache        whether to enable caching of imported module dependencies (if
                             enabled, it will generate a .psycache file of each imported module in
                             the same location as the imported source file).
@@ -115,6 +113,12 @@ by the command:
       --fixed-form          forces PSyclone to parse this file as fixed format (default is to
                             look at the input file extension).
 
+    Transformation scripts:
+      -s SCRIPT, --script SCRIPT
+                            filename of a PSyclone optimisation recipe
+      --script-kwargs SCRIPT_KWARGS
+                            Keyword arguments for the transformation script.
+
     Directory management:
       -I INCLUDE, --include INCLUDE
                             path to Fortran INCLUDE or module files

doc/user_guide/user_scripts.rst

@@ -89,6 +89,46 @@ and/or kernels) contained within the provided tree.
 The :ref:`examples section<examples>` provides a list of psyclone user scripts
 and associated usage instructions for multiple applications.
 
+.. _script_kwargs:
+
+Arguments for Scripts
+---------------------
+Scripts can take optional keyword arguments specified on the command line
+using the option `--script-kwargs`. The keyword arguments are specified
+in a string containing comma-delimited keyword:value pairs. For example:
+
+
+.. code-block:: shell
+
+    psyclone -s ./optimise.py input_source.f90 \
+             --script-kwargs "omp: True, tiling: [4,4]"
+
+This will result in the additional keyword arguments for any transformation call:
+
+.. code-block:: python
+
+    def trans(psyir, omp: bool, tiling: list[int]):
+        # Modify psyir tree
+
+The arguments specified will be converted into a Python-style dictionary, e.g.
+``omp: True, tiling: [4,4]`` will be parsed as ``{omp: True, tiling: [4,4]}``.
+Therefore, the specified keyword arguments must make a valid dictionary.
+For example, ``[1,2]`` is not a valid keyword argument, because ``{[1,2]}``
+is not valid Python (a list is not hashable), and ``1:2`` would not be valid,
+because the keys of keyword arguments must be strings.
+
+Obviously, the called transformation functions (``trans``, but also
+``trans_alg``, see below) must accept the specified keyword arguments. If
+an undeclared keyword argument is specified on the command line, the following
+error will be raised:
+
+.. code-block:: shell
+
+    psyclone -s ./omp_gpu_profile_trans.py --script-kwargs "undeclared: True" ...
+    Traceback (most recent call last):
+    ...
+    TypeError: trans() got an unexpected keyword argument 'undeclared'
+
 
 .. _sec_script_globals:
 
@@ -142,3 +182,8 @@ associated with the merged invoke.
 
 An example of the use of a script making use of the ``trans_alg``
 function can be found in ``examples/gocean/eg7``.
+
+Note that the ``trans_alg`` function will receive the same keyword arguments
+as the ``trans`` function if the PSyclone command line option
+``--script-kwargs`` is used (see :ref:`script_kwargs`). It is therefore
+important that both functions accept the same keyword arguments.

examples/nemo/eg8/Makefile

@@ -60,7 +60,8 @@ PSYCLONE_PROFILING_LIB ?= ${PSYCLONE_PROFILING_DIR}/libsimple_timing.a
 PSYCLONE_PROFILING_LIBS ?= -L${PSYCLONE_PROFILING_DIR} -lsimple_timing
 
 transform:
-	ENABLE_PROFILING=1 ${PSYCLONE} -s ./omp_gpu_profile_trans.py ../code/tra_adv.F90 -o traadv_instrumented.F90
+	${PSYCLONE} -s ./omp_gpu_profile_trans.py --script-kwargs "profiling: True" \
+		../code/tra_adv.F90 -o traadv_instrumented.F90
 
 compile: transform traadv.exe
 

examples/nemo/eg8/README.md

@@ -18,7 +18,8 @@ make transform
 or explicitly:
 
 ```sh
-ENABLE_PROFILING=1 ${PSYCLONE} -s ./omp_gpu_profile_trans.py ../code/tra_adv.F90 -o traadv_instrumented.F90
+${PSYCLONE} -s ./omp_gpu_profile_trans.py --script-kwargs "profiling: True"  \
+            ../code/tra_adv.F90 -o traadv_instrumented.F90
 ```
 
 This emits transformed Fortran code with PSyData profiling around OpenMP target

examples/nemo/eg8/omp_gpu_profile_trans.py

@@ -33,13 +33,12 @@
 # POSSIBILITY OF SUCH DAMAGE.
 # -----------------------------------------------------------------------------
 
-import os
 import pathlib
 import sys
 from typing import List, Union
 from psyclone.psyir.nodes import (
-    Assignment, IfBlock, Node, OMPDirective, OMPTargetDirective, ProfileNode,
-    Routine, Schedule)
+    Assignment, FileContainer, IfBlock, Node, OMPDirective,
+    OMPTargetDirective, ProfileNode, Routine, Schedule)
 from psyclone.psyir.transformations import OMPTargetTrans, ProfileTrans
 from psyclone.transformations import OMPLoopTrans, TransformationError
 
@@ -50,9 +49,6 @@
     sys.path.insert(0, str(NEMO_SCRIPTS_DIR))
 
 
-PROFILING_ENABLED = os.environ.get("ENABLE_PROFILING", False)
-
-
 def add_omp_region_profiling_markers(children: Union[List[Node], Schedule]):
     """Insert profiling markers around all top-level OpenMP directives.
 
@@ -94,8 +90,16 @@ def add_omp_region_profiling_markers(children: Union[List[Node], Schedule]):
             add_omp_region_profiling_markers(child.children)
 
 
-def trans(psyir):
-    """Apply OpenMP offloading and insert profiling around target regions."""
+def trans(psyir: FileContainer, profiling: bool = False):
+    """
+    Apply OpenMP offloading and insert profiling around target regions.
+
+    :param psyir: the PSyIR of the file container to modify.
+    :param profiling: if set to True (using the PSyclone command line option
+        --scripts-kwargs "profiling: True"), also adds profiling
+        instrumentation to the generated code.
+    """
+
     from utils import normalise_loops, insert_explicit_loop_parallelism
 
     omp_target_trans = OMPTargetTrans()
@@ -119,5 +123,5 @@ def trans(psyir):
             collapse=True,
             enable_reductions=True
         )
-        if PROFILING_ENABLED:
+        if profiling:
             add_omp_region_profiling_markers(subroutine.children)

src/psyclone/domain/lfric/lfric_constants.py

@@ -384,6 +384,11 @@ def __init__(self) -> None:
 
         # ---------- Infrastructure module maps -------------------------------
 
+        # Those kind symbols used in LFRic that are actually
+        # Fortran intrinsics (and thus don't come from constants_mod).
+        LFRicConstants.INTRINSIC_KINDS = ("real32", "real64")
+        LFRicConstants.FORTRAN_ISO_MOD_NAME = "iso_fortran_env"
+
         # Dictionary allowing us to look-up the name of the Fortran module,
         # type and proxy-type associated with each LFRic data structure type.
         # Data structure type mandates its proxy name, Fortran intrinsic type
@@ -420,6 +425,18 @@ def __init__(self) -> None:
                            "proxy_type": "r_bl_field_proxy_type",
                            "intrinsic": "real",
                            "kind": "r_bl"},
+            # 'real'-valued field with explicit 32-bit precision
+            "r_32_field": {"module": "field_real32_mod",
+                           "type": "field_real32_type",
+                           "proxy_type": "field_real32_proxy_type",
+                           "intrinsic": "real",
+                           "kind": "real32"},
+            # 'real'-valued field with explicit 64-bit precision
+            "r_64_field": {"module": "field_real64_mod",
+                           "type": "field_real64_type",
+                           "proxy_type": "field_real64_proxy_type",
+                           "intrinsic": "real",
+                           "kind": "real64"},
             # 'integer'-valued field with data of kind 'i_def'
             "integer_field": {"module": "integer_field_mod",
                               "type": "integer_field_type",
@@ -432,6 +449,18 @@ def __init__(self) -> None:
                          "proxy_type": "operator_proxy_type",
                          "intrinsic": "real",
                          "kind": "r_def"},
+            # 'real'-valued operator with real32 data
+            "r_32_operator": {"module": "operator_real32_mod",
+                              "type": "operator_real32_type",
+                              "proxy_type": "operator_real32_proxy_type",
+                              "intrinsic": "real",
+                              "kind": "real32"},
+            # 'real'-valued operator with real32 data
+            "r_64_operator": {"module": "operator_real64_mod",
+                              "type": "operator_real64_type",
+                              "proxy_type": "operator_real64_proxy_type",
+                              "intrinsic": "real",
+                              "kind": "real64"},
             # 'real'-valued operator with data of kind 'r_solver'
             "r_solver_operator": {
                 "module": "r_solver_operator_mod",
@@ -454,6 +483,13 @@ def __init__(self) -> None:
                 "intrinsic": "real",
                 "kind": "r_solver"}}
 
+        # Construct a reverse map from type to the name of the LFRic
+        # data type for all real field types.
+        LFRicConstants.REAL_DATA_TYPE_RMAP = {}
+        for key, value in LFRicConstants.DATA_TYPE_MAP.items():
+            if value["intrinsic"] == "real" and "field" in key:
+                LFRicConstants.REAL_DATA_TYPE_RMAP[value["type"]] = key
+
         # Mapping from a vector type used in the algorithm-layer to
         # the actual type used in the PSy-layer.
         LFRicConstants.FIELD_VECTOR_TO_FIELD_MAP = {