As an alternative to https://reviews.llvm.org/D150192, we consider using the memory region declaration intrinsic, introduced in https://reviews.llvm.org/D115274, as another way to propagate the semantics of C/C++ array-indexing rules to LLVM IR.
For example, given the following C source
int f(long i) { int A[100]; return A[i]; }
where we would previously emit the following for the indexed array access
%0 = load i64, ptr %X.addr, align 8 %arrayidx = getelementptr inbounds [100 x i32], ptr %A, i64 0, i64 %0 %1 = load i32, ptr %arrayidx, align 4
we now emit
%0 = load i64, ptr %X.addr, align 8 %arrayidx = getelementptr inbounds [100 x i32], ptr %A, i64 0, i64 0 %arrayidx.bounded = call ptr @llvm.memory.region.decl.p0(ptr %arrayidx, i64 0, i64 6400) %arrayidx1 = getelementptr inbounds i32, ptr %arrayidx.bounded, i64 %0 %1 = load i32, ptr %arrayidx1, align 4
This patch is only only a proof-of-concept at this point, intended to gather feedback and bring https://reviews.llvm.org/D115274 back into focus. As was mentioned there (and as seen from test results), completing this patch would require patching a lot of optimizations. For example, InstructionCombiningPass works with GetElementPtrInsts directly and will not recognize an intrinsic call as such. Many other passes such as IndVarSimplifyPass, EarlyCSE, etc., routinely use a switch case or call isa<GetElementPtrInst>() to detect GEPs.
We'd be fine with doing that sort of work, if we get some initial thumbs up from the community that this is the way to go. Of course, we're also open to trying a different approach if it avoids the apparently unavoidable complexity of this one.
An example of alias analysis based on the intrinsic can be seen in this independent diff: https://reviews.llvm.org/differential/diff/528871/.
Depends on D115274