[OpenMP][Docs] Updated the OpenMP documentation about building the OpenMP documentation with Sphinx

[AntonRydahl]

Summary

When I was trying to improve the OpenMP documentation, I found that the information in OpenMP/docs/README.md did not contain up-to-date information about how to build the OpenMP documentation with Sphinx. When I ran `make
docs-openmp-html`, the command failed because there were a few syntax errors in openmp/docs/design/Runtimes.rst. This commit fixes the syntax errors and updates the documentation on building the OpenMP documentation.

openmp/docs/README.txt

 OpenMP LLVM Documentation
 ==================
 
 OpenMP LLVM's documentation is written in reStructuredText, a lightweight
 plaintext markup language (file extension `.rst`). While the
 reStructuredText documentation should be quite readable in source form, it
 is mostly meant to be processed by the Sphinx documentation generation
 system to create HTML pages which are hosted on <https://llvm.org/docs/> and
 updated after every commit. Manpage output is also supported, see below.
 
 If you instead would like to generate and view the HTML locally, install
 Sphinx <http://sphinx-doc.org/> and then do:
 
     cd <build-dir>
-    cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_HTML=true <src-dir>
-    make
-    $BROWSER <build-dir>/projects/openmp/docs//html/index.html
+    cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_HTML=true -DCMAKE_MODULE_PATH=/path/to/llvm/cmake/modules <src-dir>
+    make docs-openmp-html
+    $BROWSER <build-dir>/docs/html/index.html
 
 The mapping between reStructuredText files and generated documentation is
 `docs/Foo.rst` <-> `<build-dir>/projects/openmp/docs//html/Foo.html` <->
 `https://openmp.llvm.org/docs/Foo.html`.
 
 If you are interested in writing new documentation, you will want to read
 `llvm/docs/SphinxQuickstartTemplate.rst` which will get you writing
 documentation very fast and includes examples of the most important

openmp/docs/design/Runtimes.rst

 
 .. note::
     On Windows with multiple processor groups, if the granularity is too coarse, it
     will be set to ``granularity=group``. For example, if two processor groups exist
     across one socket, and ``granularity=socket`` the runtime will shift the
     granularity down to group since that is the largest granularity allowed by the OS.
 
 KMP_HIDDEN_HELPER_AFFINITY (Windows, Linux)
-"""""""""""""""""""""""""""""
+"""""""""""""""""""""""""""""""""""""""""""
 
 Enables run-time library to bind hidden helper threads to physical processing units.
 This environment variable has the same syntax and semantics as ``KMP_AFFINIY`` but only
 applies to the hidden helper team.
 
 You must set this environment variable before the first parallel region, or
 certain API calls including ``omp_get_max_threads()``, ``omp_get_num_procs()``
 and any affinity API calls.

 concurrently map the same memory. If the memory is already mapped and the
 map clauses will only modify the reference counter from a non-zero count to
 another non-zero count, concurrent map clauses are supported regardless of
 this option. To disable forced atomic map clauses use "false"/"FALSE" as the
 value of the ``LIBOMPTARGET_MAP_FORCE_ATOMIC`` environment variable.
 The default behavior of LLVM 14 is to force atomic maps clauses, prior versions
 of LLVM did not.
 
+.. _libomptarget_jit_opt_level:
 
 LIBOMPTARGET_JIT_OPT_LEVEL
 """"""""""""""""""""""""""
 
 This environment variable can be used to change the optimization pipeline used
 to optimize the embedded device code as part of the device JIT. The value is
 corresponds to the ``-O{0,1,2,3}`` command line argument passed to ``clang``.
 

 
 This environment variable can be used to replace the embedded device code
 before the device JIT finishes compilation for the target. The value is
 expected to be a filename to an object file, thus containing the output of the
 assembler in object format for the respective target. The JIT optimization
 pipeline and backend are skipped and only target specific post-processing is
 performed on the object file before it is loaded onto the device.
 
+.. _libomptarget_jit_replacement_module:
+
 LIBOMPTARGET_JIT_REPLACEMENT_MODULE
 """""""""""""""""""""""""""""""""""
 
 This environment variable can be used to replace the embedded device code
 before the device JIT finishes compilation for the target. The value is
 expected to be a filename to an LLVM-IR file, thus containing an LLVM-IR module
 for the respective target. To obtain a device code image compatible with the
 embedded one it is recommended to extract the embedded one either before or
 after IR optimization. This can be done at compile time, after compile time via
 llvm tools (llvm-objdump), or, simply, by setting the
 :ref:`LIBOMPTARGET_JIT_PRE_OPT_IR_MODULE` or
 :ref:`LIBOMPTARGET_JIT_POST_OPT_IR_MODULE` environment variables.
 
+.. _libomptarget_jit_pre_opt_ir_module:
 
 LIBOMPTARGET_JIT_PRE_OPT_IR_MODULE
 """"""""""""""""""""""""""""""""""
 
 This environment variable can be used to extract the embedded device code
 before the device JIT runs additional IR optimizations on it (see
 :ref:`LIBOMPTARGET_JIT_OPT_LEVEL`). The value is expected to be a filename into
 which the LLVM-IR module is written. The module can be the analyzed, and
 transformed and loaded back into the JIT pipeline via
 :ref:`LIBOMPTARGET_JIT_REPLACEMENT_MODULE`.
 
+.. _libomptarget_jit_post_opt_ir_module:
 
 LIBOMPTARGET_JIT_POST_OPT_IR_MODULE
 """""""""""""""""""""""""""""""""""
 
 This environment variable can be used to extract the embedded device code after
 the device JIT runs additional IR optimizations on it (see
 :ref:`LIBOMPTARGET_JIT_OPT_LEVEL`). The value is expected to be a filename into
 which the LLVM-IR module is written. The module can be the analyzed, and
 transformed and loaded back into the JIT pipeline via
 :ref:`LIBOMPTARGET_JIT_REPLACEMENT_MODULE`.
 
 
 LIBOMPTARGET_MIN_THREADS_FOR_LOW_TRIP_COUNT
 """""""""""""""""""""""""""""""""""""""""""
 
 This environment variable defines a lower bound for the number of threads if a
 combined kernel, e.g., `target teams distribute parallel for`, has insufficient
 parallelism. Especially if the trip count of the loops is lower than the number
 of threads possible times the number of teams (aka. blocks) the device preferes
-(see also :ref:`LIBOMPTARGET_AMDGPU_TEAMS_PER_CU), we will reduce the thread
+(see also :ref:`LIBOMPTARGET_AMDGPU_TEAMS_PER_CU`), we will reduce the thread
 count to increase outer (team/block) parallelism. The thread count will never
 be reduced below the value passed for this environment variable though.
 
 
 
 .. _libomptarget_plugin:
 
 LLVM/OpenMP Target Host Runtime Plugins (``libomptarget.rtl.XXXX``)

 LIBOMPTARGET_AMDGPU_HSA_QUEUE_SIZE
 """"""""""""""""""""""""""""""""""
 
 This environment variable controls the size of each HSA queue in the AMDGPU
 plugin. The size is the number of AQL packets an HSA queue is expected to hold.
 It is also the number of AQL packets that can be pushed into each queue without
 waiting the driver to process them. The default value is ``512``.
 
+.. _libomptarget_amdgpu_teams_per_cu:
+
 LIBOMPTARGET_AMDGPU_TEAMS_PER_CU
 """"""""""""""""""""""""""""""""
 
 This environment variable controls the default number of teams relative to the
 number of compute units (CUs) of the AMDGPU device. The default number of teams
 is ``#default_teams = #teams_per_CU * #CUs``. The default value of teams per CU
 is ``4``.