backends will turn OOB InsertElement into OOB store

[regehr]

here's a slightly modified version of one of our unit tests:

define void @insert_store_nonconst_index_not_known_valid_by_and(ptr %p, i8 zeroext %val, i32 %idx) {
 %x4 = load <16 x i8>, ptr %p, align 16
 %x6 = insertelement <16 x i8> %x4, i8 %val, i32 %idx
 store <16 x i8> %x6, ptr %p, align 16
 ret void
}

the issue is what happens when %idx is out of bounds. LangRef says that in this case the insertelement poisons the vector. however, here's what we get on AArch64 (other backends seem similar):

insert_store_nonconst_index_not_known_valid_by_and:
        strb    w1, [x0, w2, uxtw]
        ret

this is, of course, much worse than a vector full of poison. there would seem to be two solutions. first, bounds-checking on vector element access indices. second, we change LangRef to make this situation immediate UB.

cc @nunoplopes @tanmaytirpankar

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: John Regehr (regehr)

here's a slightly modified version of one of our unit tests: ```llvm define void @insert_store_nonconst_index_not_known_valid_by_and(ptr %p, i8 zeroext %val, i32 %idx) { %x4 = load <16 x i8>, ptr %p, align 16 %x6 = insertelement <16 x i8> %x4, i8 %val, i32 %idx store <16 x i8> %x6, ptr %p, align 16 ret void } ```

the issue is what happens when %idx is out of bounds. LangRef says that in this case the insertelement poisons the vector. however, here's what we get on AArch64 (other backends seem similar):

insert_store_nonconst_index_not_known_valid_by_and:
        strb    w1, [x0, w2, uxtw]
        ret

this is, of course, much worse than a vector full of poison. there would seem to be two solutions. first, bounds-checking on vector element access indices. second, we change LangRef to make this situation immediate UB.

cc @nunoplopes @tanmaytirpankar

[topperc]

I suspect https://reviews.llvm.org/D152276