[GlobalOpt] Incorrect handling of memset in global ctor evaluation

[nikic]

@llvm.global_ctors = appending global [1 x { i32, ptr, ptr }] [
  { i32, ptr, ptr } { i32 65535, ptr @ctor, ptr null }
]

@g = global { i32, i32 } { i32 0, i32 1 }

define internal void @ctor() {
  call void @llvm.memset.p0.i64(ptr @g, i8 0, i64 8, i1 false)
  ret void
}

declare void @llvm.memset.p0.i64(ptr, i8, i64, i1)

; RUN: opt -globalopt < %s

@llvm.global_ctors = appending global [0 x { i32, ptr, ptr }] zeroinitializer
@g = local_unnamed_addr global { i32, i32 } { i32 0, i32 1 }

The memset is removed, but the global is not zeroed. This is because

llvm-project/llvm/lib/Transforms/Utils/Evaluator.cpp

Lines 441 to 442 in 10f7255

	Constant *DestVal =
	ComputeLoadResult(getVal(Ptr), MSI->getValue()->getType());

only checks whether the first byte is zero, not all bytes that are being set.

[nikic]

This is trickier than I thought. I think there are two complications here:

1. We can't simply read a larger value, because the read value might be refinement. For example, if we have { i32 0, i32 undef }, and read a i64 from that, then that i64 could legally be i64 0, but the memset would very much not be redundant.
2. Even if we have a zeroinitializer, I think we can still run into issues with padding. If we 8-byte memset a { i8, i32 } zeroinitializer, then dropping the memset would leave the last 3 bytes in the middle uninitialized. However, those bytes might still be accessed (through a different type) and the lack of a memset would become visible.

Now, in practice, it's probably the case that any uninitialized part of a global effectively becomes zero-initialized, but that's probably not something we should rely on on the IR level.

[nikic]

Candidate patch: https://reviews.llvm.org/D128532 Doesn't cover the second point though.