[stack-coloring] incorrect stack slot merging

[scui-ibm]

Here is a test case to illustrate the problem:

define signext i32 @afunc(ptr noalias nocapture dereferenceable(4) %.arg, ptr noalias nocapture dereferenceable(8) %.addr) {
entry:
  %T_0 = alloca i32, align 4
  %T_1 = alloca i32, align 4
  %T_2 = alloca i32, align 4
  %T_3 = alloca i32, align 4
  %_arg_ = load i32, ptr %.arg, align 4
  %_geq_0 = icmp sgt i32 %_arg_, -1
  br i1 %_geq_0, label %if_then_1, label %if_else_1

if_then_1:                                        ; preds = %entry
  %_sub_1 = add nsw i32 %_arg_, -1
  store i32 %_sub_1, ptr %T_3, align 4
  call void @llvm.lifetime.start.p0(i64 4, ptr %T_1)
  %_geq_1 = icmp sgt i32 %_sub_1, -1
  br i1 %_geq_1, label %if_then_2, label %if_else_2

if_then_2:                                        ; preds = %if_then_1
  %_sub_2 = add nsw i32 %_sub_1, -1
  call void @llvm.lifetime.start.p0(i64 4, ptr %T_0)
  %_geq_2 = icmp sgt i32 %_sub_2, -1
  br i1 %_geq_2, label %if_then_3, label %if_else_3

if_then_3:                                        ; preds = %if_then_2
  %_sub_3 = add nsw i32 %_sub_2, -1
  %_call = call i32 @afunc.1(i32 %_sub_3, ptr nonnull %.addr)
  br label %if_else_3

if_else_3:                                        ; preds = %if_then_3, %if_then_2
  %_addr_3 = load i64, ptr %.addr, align 8
  %_conv_3 = ptrtoint ptr %T_0 to i32
  %_sext_3 = sext i32 %_conv_3 to i64
  %_equ_3 = icmp eq i64 %_addr_3, %_sext_3
  br i1 %_equ_3, label %if_then_4, label %if_else_4

if_else_4:                                        ; preds = %if_else_3
  %_p2i_4 = ptrtoint ptr %T_0 to i32
  %_zext_4 = zext i32 %_p2i_4 to i64
  store i64 %_zext_4, ptr %.addr, align 8
  call void @llvm.lifetime.end.p0(i64 4, ptr %T_0)
  br label %if_else_2

if_else_2:                                        ; preds = %if_else_4, %if_then_1
  %_addr_2 = load i64, ptr %.addr, align 8
  %_conv_2 = ptrtoint ptr %T_1 to i32
  %_sext_2 = sext i32 %_conv_2 to i64
  %_equ_2 = icmp eq i64 %_addr_2, %_sext_2
  br i1 %_equ_2, label %if_then_4, label %if_else_41

if_else_41:                                       ; preds = %if_else_2
  %_p2i_41 = ptrtoint ptr %T_1 to i32
  %_zext_41 = zext i32 %_p2i_41 to i64
  store i64 %_zext_41, ptr %.addr, align 8
  call void @llvm.lifetime.end.p0(i64 4, ptr %T_1)
  br label %if_else_1

if_else_1:                                        ; preds = %if_else_41, %entry
  %_addr_1 = load i64, ptr %.addr, align 8
  %_conv_1 = ptrtoint ptr %T_2 to i32
  %_sext_1 = sext i32 %_conv_1 to i64
  %_equ_1 = icmp eq i64 %_addr_1, %_sext_1
  br i1 %_equ_1, label %if_then_4, label %if_else_42

if_else_42:                                       ; preds = %if_else_1
  ret i32 %_arg_

if_then_4:                                        ; preds = %if_else_1, %if_else_2, %if_else_3
  call void @_stop(ptr null, i32 -1, i32 11)
  unreachable
}

declare void @_stop(ptr, i32, i32)
declare i32 @afunc.1(i32, ptr noalias nocapture dereferenceable(8))
declare void @llvm.lifetime.start.p0(i64 immarg, ptr nocapture)
declare void @llvm.lifetime.end.p0(i64 immarg, ptr nocapture)

With llc -O2 t.ll -print-after-all, it can be shown that %stack.1.T_1 is merged with %stack.0.T_0, and thus marked dead.

Just before stack-coloring:

# *** IR Dump After Slot index numbering (slotindexes) ***:
# Machine code for function afunc: IsSSA, TracksLiveness
Frame Objects:
  fi#0: size=4, align=4, at location [SP]
  fi#1: size=4, align=4, at location [SP]
  fi#2: size=4, align=4, at location [SP]
  fi#3: size=4, align=4, at location [SP]

And after stack-coloring:

# *** IR Dump After Merge disjoint stack slots (stack-coloring) ***:
# Machine code for function afunc: IsSSA, TracksLiveness
Frame Objects:
  fi#0: size=4, align=4, at location [SP]
  fi#1: dead
  fi#2: size=4, align=4, at location [SP]
  fi#3: size=4, align=4, at location [SP]

For this test case, %stack.1.T_1 and %stack.0.T_0 cannot be merged. In the code, their addresses are compared, and should be different.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

[chaitanyav]

@scui-ibm is this still open to work on ?

[scui-ibm]

@scui-ibm is this still open to work on ?

@chaitanyav Yes, This is still a problem.