[llvm] 2f38604 - [docs] Update JITLink's support matrix in the JITLink doc.

[Lang Hames via llvm-commits]

Author: Lang Hames
Date: 2023-07-15T17:20:52-07:00
New Revision: 2f38604c792a6cfc22eedbe76f8ade5a13304f8d

URL: https://github.com/llvm/llvm-project/commit/2f38604c792a6cfc22eedbe76f8ade5a13304f8d
DIFF: https://github.com/llvm/llvm-project/commit/2f38604c792a6cfc22eedbe76f8ade5a13304f8d.diff

LOG: [docs] Update JITLink's support matrix in the JITLink doc.

Added: 
    

Modified: 
    llvm/docs/JITLink.rst

Removed: 
    


################################################################################
diff  --git a/llvm/docs/JITLink.rst b/llvm/docs/JITLink.rst
index bb1e7c3b31fcde..b17ce5e089cf2f 100644
--- a/llvm/docs/JITLink.rst
+++ b/llvm/docs/JITLink.rst
@@ -1082,48 +1082,68 @@ Major outstanding projects include:
   generic and should be split into an ELFLinkGraphBuilder base class along the
   same lines as the existing generic MachOLinkGraphBuilder.
 
-* Implement ELF support for arm64.
+* Implement support for arm32.
 
-  Once the architecture support code has been refactored to enable sharing and
-  ELF link graph construction has been refactored to allow re-use we should be
-  able to construct an ELF / arm64 JITLink implementation by combining
-  these existing pieces.
+* Implement support for other new architectures.
 
-* Implement support for new architectures.
-
-* Implement support for COFF.
-
-  There is no COFF implementation of JITLink yet. Such an implementation should
-  follow the MachO and ELF paths: a generic COFFLinkGraphBuilder base class that
-  can be specialized for each architecture.
+JITLink Availability and Feature Status
+---------------------------------------
 
-* Design and implement a shared-memory based JITLinkMemoryManager.
+The following table describes the status of the JITlink backends for various
+format / architecture combinations (as of July 2023).
 
-  One use-case that is expected to be common is out-of-process linking targeting
-  another process on the same machine. This allows JITs to sandbox JIT'd code.
-  For this use case a shared-memory based JITLinkMemoryManager would provide the
-  most efficient form of allocation. Creating one will require designing a
-  generic API for shared memory though, as LLVM does not currently have one.
+Support levels:
 
-JITLink Availability and Feature Status
----------------------------------------
+* None: No backend. JITLink will return an "architecture not supported" error.
+  Represented by empty cells in the table below.
+* Skeleton: A backend exists, but does not support commonly used relocations.
+  Even simple programs are likely to trigger an "unsupported relocation" error.
+  Backends in this state may be easy to improve by implementing new relocations.
+  Consider getting involved!
+* Basic: The backend supports simple programs, isn't ready for general use yet.
+* Usable: The backend is useable for general use for at least one code and
+  relocation model.
+* Good: The backend supports almost all relocations. Advanced features like
+  native thread local storage may not be available yet.
+* Complete: The backend supports all relocations and object format features.
 
 .. list-table:: Availability and Status
    :widths: 10 30 30 30
    :header-rows: 1
+   :stub-columns: 1
 
    * - Architecture
      - ELF
      - COFF
      - MachO
+   * - arm32
+     - Skeleton
+     -
+     -
    * - arm64
+     - Usable
+     -
+     - Good
+   * - LoongArch
+     - Good
+     -
+     -
+   * - PowerPC 64
+     - Usable
+     -
+     -
+   * - RISC-V
+     - Good
+     -
+     -
+   * - x86-32
+     - Basic
      -
      -
-     - Partial (small code model, PIC relocation model only)
    * - x86-64
-     - Partial
+     - Good
      -
-     - Full (except TLV and debugging)
+     - Good
 
 .. [1] See ``llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin`` for
        a full worked example.