[llvm] [AMDGPU] Add AMDPAL support for llvm.debugtrap (PR #219179)

[Matt Arsenault via llvm-commits]

Alexander =?utf-8?q?Hück?= <alexander.huck at amd.com>,
Alexander =?utf-8?q?Hück?= <alexander.huck at amd.com>,
Alexander =?utf-8?q?Hück?= <alexander.huck at amd.com>,
Alexander =?utf-8?q?Hück?= <alexander.huck at amd.com>,
Alexander =?utf-8?q?Hück?= <alexander.huck at amd.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/219179 at github.com>


================
@@ -20990,6 +21038,35 @@ address. The *spill table* itself represents a set of 32-bit values
 managed by the PAL runtime in GPU-accessible memory that can be made
 indirectly accessible to a hardware shader.
 
+.. _amdgpu-amdpal-trap-handler-abi:
+
+Trap Handler ABI
+~~~~~~~~~~~~~~~~
+
+For code objects generated for the AMDPAL OS, the runtime installs a trap
+handler that supports the ``s_trap`` instruction only when the ``trap-handler``
+target feature is enabled. The handler must be resumable and must define trap
+ID 3 as the LLVM debug trap. For usage see
+:ref:`amdgpu-trap-handler-for-amdpal-os-table`.
+
+  .. table:: AMDGPU Trap Handler for AMDPAL OS
+     :name: amdgpu-trap-handler-for-amdpal-os-table
+
+     ================== =============== =============== ======================================
+     Usage              Code Sequence   Trap Handler    Description
+                                        Inputs
+     ================== =============== =============== ======================================
+     ``llvm.trap``      ``s_endpgm``    *none*          Causes the wavefront to be terminated.
+     ``llvm.debugtrap`` ``s_trap 0x03`` *none*          Causes the wave to enter the PAL debug
+                                                        trap handler. Execution resumes after
+                                                        the configured debug action completes.
+     ================== =============== =============== ======================================
+
+The ``trap-handler`` feature is not enabled by the AMDPAL target triple; a
+frontend must enable it only when the PAL runtime implements this ABI. If the
+feature is disabled, ``llvm.debugtrap`` produces a compiler warning and no trap
+instruction.
----------------
arsenm wrote:

We probably should have it on by default and opt-out, and move it out of subtarget features 

I also don't think debug trap should warn in this case.


> AMDPAL OS, the runtime installs a trap handler that supports the

When does it do this? When it loads an object that uses trap handlers or dispatches a kernel using it?


https://github.com/llvm/llvm-project/pull/219179