[clang] [llvm] Add metadata for const C/C++ scalar types to track initial values of escaped alloca (PR #157676)

[Vladislav Belov via llvm-commits]

vbe-sc wrote:

> Consider:
> 
> ```
> void f(int*);
> void g() {
>   for (int i = 0; i < 10; ++i) {
>     const int j = i;
>     f(&j);
>   }
> }
> ```
> 
> There's "one store"... but consider what happens if the loop is unrolled.

To be honest, I still don't quite understand your arguments regarding the potential problems associated with this optimization. Let's consider your example (slightly modified):

```c
void f(int*);
int g() {
  int k = 0;
  for (int i = 0; i < 4; ++i) {
    const int j = i;
    f(&j);
    k += j;
  }
  return k;
}
```

Let's assume there was no unrolling before applying the SROA optimization: then everything is obviously fine, we simply propagate the induction variable into the sum instead of loading the value from the alloca.

IR before SROA:

```
define dso_local i32 @g() #0 {
entry:
  %k = alloca i32, align 4
  %i = alloca i32, align 4
  %j = alloca i32, align 4, !immutable !5
  call void @llvm.lifetime.start.p0(ptr %k) #3
  store i32 0, ptr %k, align 4, !tbaa !6
  call void @llvm.lifetime.start.p0(ptr %i) #3
  store i32 0, ptr %i, align 4, !tbaa !6
  br label %for.cond

for.cond:                                         ; preds = %for.body, %entry
  %0 = load i32, ptr %i, align 4, !tbaa !6
  %cmp = icmp slt i32 %0, 4
  br i1 %cmp, label %for.body, label %for.cond.cleanup

for.cond.cleanup:                                 ; preds = %for.cond
  call void @llvm.lifetime.end.p0(ptr %i) #3
  %1 = load i32, ptr %k, align 4, !tbaa !6
  call void @llvm.lifetime.end.p0(ptr %k) #3
  ret i32 %1

for.body:                                         ; preds = %for.cond
  call void @llvm.lifetime.start.p0(ptr %j) #3
  %2 = load i32, ptr %i, align 4, !tbaa !6
  store i32 %2, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef %j)
  %3 = load i32, ptr %j, align 4, !tbaa !6
  %4 = load i32, ptr %k, align 4, !tbaa !6
  %add = add nsw i32 %4, %3
  store i32 %add, ptr %k, align 4, !tbaa !6
  call void @llvm.lifetime.end.p0(ptr %j) #3
  %5 = load i32, ptr %i, align 4, !tbaa !6
  %inc = add nsw i32 %5, 1
  store i32 %inc, ptr %i, align 4, !tbaa !6
  br label %for.cond, !llvm.loop !10
}
```

IR after:

```
define dso_local i32 @g() #0 {
entry:
  %j = alloca i32, align 4, !immutable !5
  br label %for.cond

for.cond:                                         ; preds = %for.body, %entry
  %k.0 = phi i32 [ 0, %entry ], [ %add, %for.body ]
  %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.body ]
  %cmp = icmp slt i32 %i.0, 4
  br i1 %cmp, label %for.body, label %for.cond.cleanup

for.cond.cleanup:                                 ; preds = %for.cond
  ret i32 %k.0

for.body:                                         ; preds = %for.cond
  call void @llvm.lifetime.start.p0(ptr %j) #3
  store i32 %i.0, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef %j)
  %0 = load i32, ptr %j, align 4, !tbaa !6
  %add = add nsw i32 %k.0, %i.0
  call void @llvm.lifetime.end.p0(ptr %j) #3
  %inc = add nsw i32 %i.0, 1
  br label %for.cond, !llvm.loop !10
}
```

We simply propagated `%i.0` into `%add = add nsw i32 %k.0, %i.0`, and `%3 = load i32, ptr %j, align 4, !tbaa !6` now becomes dead code.

The result is a much more optimized IR, since the compiler now folds the return value into 6. And instead of:

```
define dso_local i32 @g() local_unnamed_addr #0 {
entry:
  %j = alloca i32, align 4, !immutable !5
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 0, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  %0 = load i32, ptr %j, align 4, !tbaa !6
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 1, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  %1 = load i32, ptr %j, align 4, !tbaa !6
  %add.1 = add nsw i32 %1, %0
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 2, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  %2 = load i32, ptr %j, align 4, !tbaa !6
  %add.2 = add nsw i32 %2, %add.1
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 3, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  %3 = load i32, ptr %j, align 4, !tbaa !6
  %add.3 = add nsw i32 %3, %add.2
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  ret i32 %add.3
}
```

only this remains:

```
define dso_local noundef i32 @g() local_unnamed_addr #0 {
entry:
  %j = alloca i32, align 4, !immutable !5
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 0, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 1, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 2, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 3, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  ret i32 6
```

And now let's assume that for some reason this transformation was not performed before the FullUnrollPass. Then we would have the following IR. As **it's not legal** to has an alloca in the middle of function, it would not be dupicated

```
define dso_local i32 @g() local_unnamed_addr #0 {
entry:
  %j = alloca i32, align 4, !immutable !5
  br label %for.body

for.body:                                         ; preds = %entry
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 0, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  %0 = load i32, ptr %j, align 4, !tbaa !6
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 1, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  %1 = load i32, ptr %j, align 4, !tbaa !6
  %add.1 = add nsw i32 %1, %0
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 2, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  %2 = load i32, ptr %j, align 4, !tbaa !6
  %add.2 = add nsw i32 %2, %add.1
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  call void @llvm.lifetime.start.p0(ptr nonnull %j) #3
  store i32 3, ptr %j, align 4, !tbaa !6
  call void @f(ptr noundef nonnull %j) #3
  %3 = load i32, ptr %j, align 4, !tbaa !6
  %add.3 = add nsw i32 %3, %add.2
  call void @llvm.lifetime.end.p0(ptr nonnull %j) #3
  ret i32 %add.3
}
```

Since there are multiple `store` operations to `immutable` alloca here, the optimization will conservatively not be performed at all.

> There's also more subtle issues; we don't guarantee "one store" actually remains a single store instruction.

Unfortunately, I find it difficult to imagine such a case for trivial scalar types in C and C++ languages. However, even if that were the case, the IR would simply remain as it is, rather than being transformed into something incorrect.

https://github.com/llvm/llvm-project/pull/157676