[llvm-bugs] [Bug 45710] New: Alignment for array pointer access

[via llvm-bugs]

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: unassignedclangbugs at nondot.org
          Reporter: 2077213809 at qq.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200428/5eed719a/attachment.html>