llvm-6502/test/Transforms/PlaceSafepoints/statepoint-frameescape.ll
Reid Kleckner 8f32e5f0d6 Rename llvm.frameescape and llvm.framerecover to localescape and localrecover
Summary:
Initially, these intrinsics seemed like part of a family of "frame"
related intrinsics, but now I think that's more confusing than helpful.
Initially, the LangRef specified that this would create a new kind of
allocation that would be allocated at a fixed offset from the frame
pointer (EBP/RBP). We ended up dropping that design, and leaving the
stack frame layout alone.

These intrinsics are really about sharing local stack allocations, not
frame pointers. I intend to go further and add an `llvm.localaddress()`
intrinsic that returns whatever register (EBP, ESI, ESP, RBX) is being
used to address locals, which should not be confused with the frame
pointer.

Naming suggestions at this point are welcome, I'm happy to re-run sed.

Reviewers: majnemer, nicholas

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D11011

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241633 91177308-0d34-0410-b5e6-96231b3b80d8
2015-07-07 22:25:32 +00:00

29 lines
748 B
LLVM

; RUN: opt %s -S -place-safepoints | FileCheck %s
declare void @llvm.localescape(...)
; Do we insert the entry safepoint after the localescape intrinsic?
define void @parent() gc "statepoint-example" {
; CHECK-LABEL: @parent
entry:
; CHECK-LABEL: entry
; CHECK-NEXT: alloca
; CHECK-NEXT: localescape
; CHECK-NEXT: statepoint
%ptr = alloca i32
call void (...) @llvm.localescape(i32* %ptr)
ret void
}
; This function is inlined when inserting a poll. To avoid recursive
; issues, make sure we don't place safepoints in it.
declare void @do_safepoint()
define void @gc.safepoint_poll() {
; CHECK-LABEL: gc.safepoint_poll
; CHECK-LABEL: entry
; CHECK-NEXT: do_safepoint
; CHECK-NEXT: ret void
entry:
call void @do_safepoint()
ret void
}