Is this a bug or is llvm processing conservative?

Hi, All developers:

I have this code. For (*b)[2], It is reasonable that llvm thinks it’s unaligned access. and I think the array pointer always points to 4 - byte aligned array elements.

image001.png

CMD: clang --target=arm-none-eabi -mcpu=cortex-r52 -mthumb -O0 -emit-llvm -S test.c -o test.ll

LLVM think it’s an align 1 store, I don’t think so.

image002.png

CMD: llc -mattr=+strict-align test.ll

If the CPU does not support non-aligned access, The access is divided into four one-byte access.

image003.png

CMD: llc -mattr=-strict-align test.ll

If the CPU support non-aligned access, It’s a normal four-byte access.

image004.png

But gcc always think it’s an aligned access ,and processed him as a four-byte access. I think this is reasonable.

CMD1: arm-none-eabi-gcc -mcpu=cortex-r52 -mthumb -munaligned-access -O0 -emit-llvm -S test.c -o test.s

CMD2: arm-none-eabi-gcc -mcpu=cortex-r52 -mthumb -mno-unaligned-access -O0 -emit-llvm -S test.c -o test.s

image005.png

Why does LLVM think it’s a one-byte-aligned access? I think it makes more sense to access the number of aligned based on the type of the array element to which the array pointer points

test.c (356 Bytes)

test.ll (1.72 KB)

llvm-align-access.s (1.88 KB)

llvm-no-align-access.s (1.82 KB)

gcc-no-unaligned-access.s (882 Bytes)

gcc-unaligned-access.s (882 Bytes)

Perhaps “(*b)[2]” is out of bounds?

image001.png

image002.png

image003.png

image004.png

image005.png