https://bugs.llvm.org/show_bug.cgi?id=45710
Bug ID: 45710
Summary: Alignment for array pointer access
Product: clang
Version: 8.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: 2077213...@qq.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
When accessing an array pointer, the compiler considers it to be aligned 1,
even if the element it points to is aligned 4.
The code is as follows:
int alignaddress[10];
void test() {
int (*p)[] = &alignaddress;
(*p)[2] = 0x12;
}
clang -O0 --target=arm-none-eabi -emit-llvm -S test.c
IR: the store 0x12 is align 1
define dso_local void @test() #0 {
%1 = alloca [0 x i32]*, align 4
store [0 x i32]* bitcast ([10 x i32]* @alignaddress to [0 x i32]*), [0 x
i32]** %1, align 4
%2 = load [0 x i32]*, [0 x i32]** %1, align 4
%3 = getelementptr inbounds [0 x i32], [0 x i32]* %2, i32 0, i32 2
store i32 18, i32* %3, align 1
ret void
}
when we dont allow unaligned-access, it will use 4 strb instruction to access
CMD: llc -mattr=+strict-align test.ll
test:
.fnstart
@ %bb.0:
.pad #4
sub sp, sp, #4
ldr r0, .LCPI0_0
str r0, [sp]
ldr r0, [sp]
mov r1, #18
strb r1, [r0, #8]!
mov r1, #0
strb r1, [r0, #3]
strb r1, [r0, #2]
strb r1, [r0, #1]
add sp, sp, #4
bx lr
gcc think it is an aligned access.
CMD: arm-none-eabi-gcc -mno-unaligned-access -S test.c
test:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
str fp, [sp, #-4]!
add fp, sp, #0
sub sp, sp, #12
ldr r3, .L2
str r3, [fp, #-8]
ldr r3, [fp, #-8]
mov r2, #18
str r2, [r3, #8]
nop
add sp, fp, #0
@ sp needed
ldr fp, [sp], #4
bx lr
Is this a bug or is the llvm processing more conservative because the address
which the pointer points is unknown?
But in the following case, llvm thinks it's aligned 4.
int a;
void test() {
int *p = &a;
*p = 2;
}
However, in the current scenario, I think that the llvm processing is
incorrect.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
