[llvm-bugs] [Bug 48350] New: The generation of non-aligned instructions ldm cannot be avoided.

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Dec 1 05:01:54 PST 2020


https://bugs.llvm.org/show_bug.cgi?id=48350

            Bug ID: 48350
           Summary: The generation of non-aligned instructions ldm cannot
                    be avoided.
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          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

My armv8 hardware environment supports non-aligned access, except for ldrd and
ldm class instructions.But whatever option I add, I can't prevent the compiler
from generating ldm/stm, which can cause my program to be misaligned.

The code is as follows:

```
extern void* getaddr();

typedef struct {
  unsigned int x[4];
  unsigned char y;
}A;

typedef struct {
  unsigned long long x;
}B;

typedef struct {
  A a;
  B b;
}Obj;

typedef struct {
  int x;
  A a;
  B b;
}Src;

int test(Obj *a)
{
  Src *b = getaddr();
  a->a = b->a;
}
```
clang --target=arm-none-eabi -S -O2 a.c -o -

I've tried -mllvm arm-assume-misaligned-load-store=true, -mno-unaligned-access,
even O0, and I can't stop this kind of instruction.

```

        .save   {r4, r5, r6, r10, r11, lr}
        push    {r4, r5, r6, r10, r11, lr}
        .setfp  r11, sp, #16
        add     r11, sp, #16
        mov     r6, r0
        bl      getaddr
        add     r0, r0, #4
        ldm     r0, {r1, r2, r3, r4, r5} // This directive may cause exceptions
but cannot disable generation.
        stm     r6, {r1, r2, r3, r4, r5}
        pop     {r4, r5, r6, r10, r11, lr}
        bx      lr
```

-- 
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/20201201/329469d9/attachment.html>


More information about the llvm-bugs mailing list