AAarch64 backend turning OOB insertelement into OOB store

[regehr]

this function:

define <16 x i8> @f(i32 %0) {
  %2 = sub nuw i32 1, %0
  %3 = insertelement <16 x i8> zeroinitializer, i8 3, i32 %2
  ret <16 x i8> %3
}

is getting lowered to this AArch64:

_f:                                     ; @f
	sub	sp, sp, #16
	movi.2d	v0, #0000000000000000
	mov	w8, #1                          ; =0x1
	mov	x9, sp
	sub	w8, w8, w0
	mov	w10, #3                         ; =0x3
	orr	x8, x9, x8
	str	q0, [sp]
	strb	w10, [x8]
	ldr	q0, [sp], #16
	ret

I believe this is incorrect. if we pass an argument such as 5 into this function, then we get -4 put into w8, resulting in a nonsense address after we orr -4 with sp.

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: John Regehr (regehr)

this function: ```llvm define <16 x i8> @f(i32 %0) { %2 = sub nuw i32 1, %0 %3 = insertelement <16 x i8> zeroinitializer, i8 3, i32 %2 ret <16 x i8> %3 } ``` is getting lowered to this AArch64: ``` _f: ; @f sub sp, sp, #16 movi.2d v0, #0000000000000000 mov w8, #1 ; =0x1 mov x9, sp sub w8, w8, w0 mov w10, #3 ; =0x3 orr x8, x9, x8 str q0, [sp] strb w10, [x8] ldr q0, [sp], #16 ret ``` I believe this is incorrect. if we pass an argument such as 5 into this function, then we get -4 put into w8, resulting in a nonsense address after we orr -4 with sp.

[topperc]

If you pass 5 into the function, doesn't that cause poison due to the nuw on the sub?

[topperc]

But I guess we should have only poisoned the result instead of tramping random memory.

[regehr]

If you pass 5 into the function, doesn't that cause poison due to the nuw on the sub?

argh yes of course, sorry.

yes this is still a bug but I don't know how to evaluate how much (or if) it matters