mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-21 03:53:04 +02:00
59e5be82bb
If you're going to realign %sp to get object alignment properly (which the code does), and stack offsets and alignments are calculated going down from %fp (which they are), then the total stack size had better be a multiple of the alignment. LLVM did indeed ensure that. And then, after aligning, the sparc frame code added 96 (for sparcv8) to the frame size, making any requested alignment of 64-bytes or higher *guaranteed* to be misaligned. The test case added with r245668 even tests this exact scenario, and asserted the incorrect behavior, which I somehow failed to notice. D'oh. This change fixes the frame lowering code to align the stack size *after* adding the spill area, instead. Differential Revision: http://reviews.llvm.org/D12349 llvm-svn: 246042
23 lines
771 B
LLVM
23 lines
771 B
LLVM
; RUN: llc -march=sparc < %s | FileCheck %s
|
|
declare void @stack_realign_helper(i32 %a, i32* %b)
|
|
|
|
@foo = global i32 1
|
|
|
|
;; This is a function where we have a local variable of 64-byte
|
|
;; alignment. We want to see that the stack is aligned (the initial
|
|
;; andn), that the local var is accessed via stack pointer (to %o0), and that
|
|
;; the argument is accessed via frame pointer not stack pointer (to %o1).
|
|
|
|
;; CHECK-LABEL: stack_realign:
|
|
;; CHECK: andn %sp, 63, %sp
|
|
;; CHECK-NEXT: ld [%fp+92], %o0
|
|
;; CHECK-NEXT: call stack_realign_helper
|
|
;; CHECK-NEXT: add %sp, 128, %o1
|
|
|
|
define void @stack_realign(i32 %a, i32 %b, i32 %c, i32 %d, i32 %e, i32 %f, i32 %g) {
|
|
entry:
|
|
%aligned = alloca i32, align 64
|
|
call void @stack_realign_helper(i32 %g, i32* %aligned)
|
|
ret void
|
|
}
|