[clang] [llvm] [SystemZ] Add support for __builtin_setjmp and __builtin_longjmp (PR #116642)

[Ulrich Weigand via cfe-commits]

================
@@ -4619,6 +4619,31 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl GD, unsigned BuiltinID,
     // Buffer is a void**.
     Address Buf = EmitPointerWithAlignment(E->getArg(0));
 
+    if (getTarget().getTriple().getArch() == llvm::Triple::systemz) {
+      // Call LLVM's EH setjmp, which is lightweight.
+      // We're not filling any fields of the jmp_buf here and leave
+      // it all to the back-end.
+      // Current LLVM implementation and documentation of the builtin is
+      // somewhat inconsistent with itself. The documentation starts out with:
+      // The buffer format and the overall functioning of this intrinsic is
+      // compatible with the GCC __builtin_setjmp implementation allowing code
+      // built with the clang and GCC to interoperate.
+      // But in GCC the format of the buffer is completely target-dependent,
+      // while LLVM attempts to impose some constraints on certain fields.
+      // 1. LLVM documentation continues with - The front end places the frame
+      // pointer in the first word - What clang puts into the first word,
+      // however, is the result of the frameaddress intrinsic - this value
+      // matches the frame pointer register contents on some but not all
+      // targets. On SystemZ these values differ, which would cause
+      // incompatibilties with GCC.
+      // 2. Clang front-end also writes the stack pointer into the third
+      // slot. Not only is this not even mentioned in the docs, it also does
+      // not match GCC behavior on all targets. On SystemZ we use the fourth
+      // slot.
----------------
uweigand wrote:

@anoopkg6 , we shouldn't add a long comment here why the documentation is wrong - instead, the patch should actually *fix* the documentation.  This particular bit would be in `docs/ExceptionHandling.rst`.   I would change the paragraph that currently reads:
```
The single parameter is a pointer to a five word buffer in which the calling
context is saved. The front end places the frame pointer in the first word, and
the target implementation of this intrinsic should place the destination address
for a `llvm.eh.sjlj.longjmp`_ in the second word. The following three words are
available for use in a target-specific manner.
```
to something like:
```
The single parameter is a pointer to a five word buffer in which the calling
context is saved.   The format and contents of the buffer are target-specific.
On certain targets, the front end places the frame pointer in the first word
and the stack pointer in the third word, while the target implementation of
this intrinsic fills in the remaining words.  On other targets, saving the
calling context to the buffer is left completely to the target implementation.
```
Then can we simply put a short notice in this file, along the lines of
"On this target, the back end fills in the context buffer completely."

@efriedma-quic would this be OK with you?

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