Test and document stackmap corner case: when the frame size isn't statically known

[vext01]

Summary

When a function does a dynamic stack allocation, is it impossible to know the size of the stack statically. If such a function uses stackmaps, then the stack size field is populated with UINT64_MAX to indicate this, however this is not tested or documented.

This change tests and documents this case.

Brought to my attention by @ptersilie , thanks.

[arsenm]

llvm/test/CodeGen/AArch64/stackmap-dynamic-alloca.ll

26

I'm surprised this isn't eliminated as dead

[vext01]

I think the reason the alloca isn't optimised out is that:

stackmap and patchpoint intrinsics are considered to potentially read and write all memory

https://llvm.org/docs/StackMaps.html#id12

But to be doubly sure it can't be optimised out, in this revised diff I've made use of the value returned by alloca.

Looks good?

[arsenm]

llvm/test/CodeGen/SystemZ/stackmap-dynamic-alloca.ll

28

This is undefined behavior. The argument use is good enough

[vext01]

Removed UB.

llvm/docs/StackMaps.rst

Header {
     uint8  : Reserved (expected to be 0)
     uint16 : Reserved (expected to be 0)
   }
   uint32 : NumFunctions
   uint32 : NumConstants
   uint32 : NumRecords
   StkSizeRecord[NumFunctions] {
     uint64 : Function Address
-    uint64 : Stack Size
+    uint64 : Stack Size (or UINT64_MAX if not statically known)
     uint64 : Record Count
   }
   Constants[NumConstants] {
     uint64 : LargeConstant
   }
   StkMapRecord[NumRecords] {
     uint64 : PatchPoint ID
     uint32 : Instruction Offset

llvm/test/CodeGen/AArch64/stackmap-dynamic-alloca.ll

+; RUN: llc < %s -mtriple=arm64-linux-gnu | FileCheck %s
+
+; When a function does a dynamic stack allocation, the function's stack size
+; is reported as UINT64_MAX.
+
+; CHECK-LABEL:  .section  .llvm_stackmaps
+; CHECK-NEXT:  __LLVM_StackMaps:
+; Header
+; CHECK-NEXT:   .byte 3
+; CHECK-NEXT:   .byte 0
+; CHECK-NEXT:   .hword 0
+; Num Functions
+; CHECK-NEXT:   .word 1
+; Num LargeConstants
+; CHECK-NEXT:   .word 0
+; Num Callsites
+; CHECK-NEXT:   .word 1
+
+; Functions and stack size
+; CHECK-NEXT:   .xword f
+; CHECK-NEXT:   .xword -1
+
+define void @f(i32 %nelems) {
+entry:
+  %mem = alloca i32, i32 %nelems
+  call void (i64, i32, ...) @llvm.experimental.stackmap(i64 0, i32 0, i32* %mem)
+  ret void
+}
+
+declare void @llvm.experimental.stackmap(i64, i32, ...)

llvm/test/CodeGen/SystemZ/stackmap-dynamic-alloca.ll

+; RUN: llc < %s -mtriple=s390x-linux-gnu | FileCheck %s
+
+; When a function does a dynamic stack allocation, the function's stack size
+; is reported as UINT64_MAX.
+
+; CHECK:       .section .llvm_stackmaps
+; CHECK-NEXT:  __LLVM_StackMaps:
+; Header
+; CHECK-NEXT:   .byte 3
+; CHECK-NEXT:   .byte 0
+; CHECK-NEXT:   .short 0
+; Num Functions
+; CHECK-NEXT:   .long 1
+; Num LargeConstants
+; CHECK-NEXT:   .long 0
+; Num Callsites
+; CHECK-NEXT:   .long 1
+
+; Functions and stack size
+; CHECK-NEXT:   .quad f
+; CHECK-NEXT:   .quad -1
+
+define void @f(i32 %nelems) {
+entry:
+  %mem = alloca i32, i32 %nelems
+  call void (i64, i32, ...) @llvm.experimental.stackmap(i64 0, i32 0, i32* %mem)
+  ret void
+}
+
+declare void @llvm.experimental.stackmap(i64, i32, ...)

llvm/test/CodeGen/X86/stackmap-dynamic-alloca.ll

+; RUN: llc < %s -mtriple=x86_64-apple-darwin -mcpu=corei7 | FileCheck %s
+
+; When a function does a dynamic stack allocation, the function's stack size is
+; reported as UINT64_MAX.
+
+; CHECK-LABEL:  .section  __LLVM_STACKMAPS,__llvm_stackmaps
+; CHECK-NEXT:  __LLVM_StackMaps:
+; Header
+; CHECK-NEXT:   .byte 3
+; CHECK-NEXT:   .byte 0
+; CHECK-NEXT:   .short 0
+; Num Functions
+; CHECK-NEXT:   .long 1
+; Num LargeConstants
+; CHECK-NEXT:   .long 0
+; Num Callsites
+; CHECK-NEXT:   .long 1
+
+; Functions and stack size
+; CHECK-NEXT:   .quad _f
+; CHECK-NEXT:   .quad -1
+
+define void @f(i32 %nelems) {
+entry:
+  %mem = alloca i32, i32 %nelems
+  call void (i64, i32, ...) @llvm.experimental.stackmap(i64 0, i32 0, i32* %mem)
+  ret void
+}
+
+declare void @llvm.experimental.stackmap(i64, i32, ...)