[llvm-bugs] [Bug 37365] New: Potential improvement for loads from large structure on ARM32

[via llvm-bugs]

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

            Bug ID: 37365
           Summary: Potential improvement for loads from large structure
                    on ARM32
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Keywords: performance
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: lidija.besker at rt-rk.com
                CC: llvm-bugs at lists.llvm.org, mips32r2 at gmail.com

I have been looking into code compiled for ARM32 and I noticed difference in
files generated from LLVM and GCC. I used optimization for size and here is
what I got:
LLVM generates more instructions than GCC in case when it needs to load more
than one field from structure and offset of these fields is grater than 4095
(maximum value for immediate of LDR instruction) from the beginning of that
structure. Take a look at following example. 

typedef struct {
   char arr[8192];
   int a;
   int b;
   int c;
   int d;
   int e;
   int f;
   int g;
} S;

int foo(S *s) {
  return s->a + s->b + s->c + s->d + s->e + s->f + s->g;
}


objdump for clang:

00000000 <foo>:
   0:   e3a02004        mov     r2, #4
   4:   e3a01a02        mov     r1, #8192       ; 0x2000
   8:   e3822a02        orr     r2, r2, #8192   ; 0x2000
   c:   e7901001        ldr     r1, [r0, r1]
  10:   e7902002        ldr     r2, [r0, r2]
  14:   e0821001        add     r1, r2, r1
  18:   e3a02008        mov     r2, #8
  1c:   e3822a02        orr     r2, r2, #8192   ; 0x2000
  20:   e7902002        ldr     r2, [r0, r2]
  24:   e0811002        add     r1, r1, r2
  28:   e3a0200c        mov     r2, #12
  2c:   e3822a02        orr     r2, r2, #8192   ; 0x2000
  30:   e7902002        ldr     r2, [r0, r2]
  34:   e0811002        add     r1, r1, r2
  38:   e3a02010        mov     r2, #16
  3c:   e3822a02        orr     r2, r2, #8192   ; 0x2000
  40:   e7902002        ldr     r2, [r0, r2]
  44:   e0811002        add     r1, r1, r2
  48:   e3a02014        mov     r2, #20
  4c:   e3822a02        orr     r2, r2, #8192   ; 0x2000
  50:   e7902002        ldr     r2, [r0, r2]
  54:   e0811002        add     r1, r1, r2
  58:   e3a02018        mov     r2, #24
  5c:   e3822a02        orr     r2, r2, #8192   ; 0x2000
  60:   e7900002        ldr     r0, [r0, r2]
  64:   e0810000        add     r0, r1, r0
  68:   e12fff1e        bx      lr


objdump for gcc 

00000000 <foo>:
   0:   e2800a02        add     r0, r0, #8192   ; 0x2000
   4:   e890000c        ldm     r0, {r2, r3}
   8:   e0823003        add     r3, r2, r3
   c:   e5902008        ldr     r2, [r0, #8]
  10:   e0833002        add     r3, r3, r2
  14:   e590200c        ldr     r2, [r0, #12]
  18:   e0833002        add     r3, r3, r2
  1c:   e5902010        ldr     r2, [r0, #16]
  20:   e0833002        add     r3, r3, r2
  24:   e5902014        ldr     r2, [r0, #20]
  28:   e5900018        ldr     r0, [r0, #24]
  2c:   e0833002        add     r3, r3, r2
  30:   e0830000        add     r0, r3, r0
  34:   e12fff1e        bx      lr

I think this would be a good candidate for optimization.

-- 
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/20180508/15cf8d86/attachment.html>