[compiler-rt] [SystemZ][XRay] XRay runtime support for SystemZ (PR #113252)

Ulrich Weigand via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 23 07:36:54 PDT 2024


================
@@ -0,0 +1,111 @@
+//===-- xray_trampoline_s390x.s ---------------------------------*- ASM -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file is a part of XRay, a dynamic runtime instrumentation system.
+//
+// This implements the s390x-specific assembler for the trampolines.
+//
+//===----------------------------------------------------------------------===//
+
+    .text
+
+#if __VX__
+// Minimal stack frame size (160) plus space for 8 vector registers a 16 bytes.
+#define STACKSZ  288
+#else
+// Minimal stack frame size
+#define STACKSZ  160
+#endif
+
+//===----------------------------------------------------------------------===//
+
+    .globl  __xray_FunctionEntry
+    .p2align    4
+    .type   __xray_FunctionEntry, at function
+__xray_FunctionEntry:
+    # The registers r2-15 of the instrumented function are already saved in the
+    # stack frame. On entry, r2 contains the function id, and %r14 the address
+    # of the first instruction of the instrumented function.
+    # Register r14 will be stored in the slot reserved for compiler use.
+    stg     %r14, 8(%r15)
+    std     %f0, 128(%r15)
+    std     %f2, 136(%r15)
+    std     %f4, 144(%r15)
+    std     %f6, 152(%r15)
+    aghi    %r15, -STACKSZ
+#if __VX__
----------------
uweigand wrote:

I'm a bit concerned about this #if.  As I understand, the vector argument registers need to be saved if they're live during the call (i.e. caller and callee were built with vector support, and at least one of the arguments is of vector type), and the XRay library routine being called below might clobber the vector registers - this can happen if either itself or a routine it calls are built with vector support.

The #if here checks whether this trampoline is built with vector support.  This may not match whether or not caller and callee are built with vector support.  While it would typically match whether the XRay library routine is built with vector support (generally, the whole support library is built with the same flags), it might not necessarily match all routines *called* by the support library - e.g. they might call `memcpy` from a glibc that is built for vector support and uses vector registers.

I'm not sure if there is some way to ensure the called support routine never uses vector registers.   Maybe an alternative would be to provide two copies of the trampoline, one that saves VRs and one that does not, and then emit calls to the version that matches how the instrumented code is being compiled?

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


More information about the llvm-commits mailing list