
Doing so can cause the resulting displacement after frame layout to become inexpressible (or cause over/underflow currently during frame layout). Fixes the error reported in https://github.com/llvm/llvm-project/pull/101840#issuecomment-2306975944.
48 lines
1.6 KiB
LLVM
48 lines
1.6 KiB
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
|
|
; RUN: llc < %s -mtriple=i386 --frame-pointer=all | FileCheck %s
|
|
|
|
; ISel will try to fold pointer arithmetic into the address displacement. However, we don't
|
|
; want to do that if the offset is very close to the expressible limit because the final frame
|
|
; layout may push it over/under the limit.
|
|
|
|
define i32 @foo(i1 %b) #0 {
|
|
; CHECK-LABEL: foo:
|
|
; CHECK: # %bb.0: # %entry
|
|
; CHECK-NEXT: pushl %ebp
|
|
; CHECK-NEXT: .cfi_def_cfa_offset 8
|
|
; CHECK-NEXT: .cfi_offset %ebp, -8
|
|
; CHECK-NEXT: movl %esp, %ebp
|
|
; CHECK-NEXT: .cfi_def_cfa_register %ebp
|
|
; CHECK-NEXT: subl $8, %esp
|
|
; CHECK-NEXT: movl __stack_chk_guard, %eax
|
|
; CHECK-NEXT: movl %eax, -4(%ebp)
|
|
; CHECK-NEXT: testb $1, 8(%ebp)
|
|
; CHECK-NEXT: jne .LBB0_1
|
|
; CHECK-NEXT: # %bb.2: # %entry
|
|
; CHECK-NEXT: xorl %eax, %eax
|
|
; CHECK-NEXT: jmp .LBB0_3
|
|
; CHECK-NEXT: .LBB0_1:
|
|
; CHECK-NEXT: movl $-2147483647, %eax # imm = 0x80000001
|
|
; CHECK-NEXT: leal -5(%ebp,%eax), %eax
|
|
; CHECK-NEXT: .LBB0_3: # %entry
|
|
; CHECK-NEXT: movl __stack_chk_guard, %ecx
|
|
; CHECK-NEXT: cmpl -4(%ebp), %ecx
|
|
; CHECK-NEXT: jne .LBB0_5
|
|
; CHECK-NEXT: # %bb.4: # %entry
|
|
; CHECK-NEXT: addl $8, %esp
|
|
; CHECK-NEXT: popl %ebp
|
|
; CHECK-NEXT: .cfi_def_cfa %esp, 4
|
|
; CHECK-NEXT: retl
|
|
; CHECK-NEXT: .LBB0_5: # %entry
|
|
; CHECK-NEXT: .cfi_def_cfa %ebp, 8
|
|
; CHECK-NEXT: calll __stack_chk_fail
|
|
entry:
|
|
%a = alloca i8, align 1
|
|
%0 = ptrtoint ptr %a to i32
|
|
%sub = add i32 %0, -2147483647
|
|
%retval.0 = select i1 %b, i32 %sub, i32 0
|
|
ret i32 %retval.0
|
|
}
|
|
|
|
attributes #0 = { sspreq }
|