[Bug target/64774] New: [ARM/thumb] missed optimization: pc relative ldr used when constant can be derived from register

[Bug target/64774] New: [ARM/thumb] missed optimization: pc relative ldr used when constant can be derived from register

[bruck.michael at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64774

            Bug ID: 64774
           Summary: [ARM/thumb] missed optimization: pc relative ldr used
                    when constant can be derived from register
           Product: gcc
           Version: 4.9.3
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bruck.michael at googlemail dot com

In the example the second write address of each function can either be
generated using 'str' with an immediate offset or using an adds with an
immediate addend.

The compiler does this for test1-3. For test4-6 it emits a pc-relative ldr
instruction and a 32bit constant. This increases size and likely impacts
execution speed.

cat test.c
void test1()
{
    *(unsigned *)4 = 0x666;
    *(unsigned *)(4 + 4) = 0x666;
}


void test2()
{
    *(unsigned *)4 = 0x666;
    *(unsigned *)(4 + 128) = 0x666;
}

void test3()
{
    *(unsigned *)0x444 = 0x666;
    *(unsigned *)(0x444 + 4) = 0x666;
}


void test4()
{
    *(unsigned *)0x444 = 0x666;
    *(unsigned *)(0x444 + 128) = 0x666;
}

void test5()
{
    *(unsigned *)0x44444444 = 0x666;
    *(unsigned *)(0x44444444 + 4) = 0x666;
}


void test6()
{
    *(unsigned *)0x44444444 = 0x666;
    *(unsigned *)(0x44444444 + 128) = 0x666;
}

arm-none-eabi-gcc -c test.c -mthumb -mcpu=cortex-m0 -mtune=cortex-m0 -Ofast -o
test.o

00000000 <test1>:
   0:    2204          movs    r2, #4
   2:    4b02          ldr    r3, [pc, #8]    ; (c <test1+0xc>)
   4:    6013          str    r3, [r2, #0]
   6:    6053          str    r3, [r2, #4]
   8:    4770          bx    lr
   a:    46c0          nop            ; (mov r8, r8)
   c:    00000666     .word    0x00000666

00000010 <test2>:
  10:    2204          movs    r2, #4
  12:    4b02          ldr    r3, [pc, #8]    ; (1c <test2+0xc>)
  14:    6013          str    r3, [r2, #0]
  16:    3280          adds    r2, #128    ; 0x80
  18:    6013          str    r3, [r2, #0]
  1a:    4770          bx    lr
  1c:    00000666     .word    0x00000666

00000020 <test3>:
  20:    4b02          ldr    r3, [pc, #8]    ; (2c <test3+0xc>)
  22:    4a03          ldr    r2, [pc, #12]    ; (30 <test3+0x10>)
  24:    6013          str    r3, [r2, #0]
  26:    6053          str    r3, [r2, #4]
  28:    4770          bx    lr
  2a:    46c0          nop            ; (mov r8, r8)
  2c:    00000666     .word    0x00000666
  30:    00000444     .word    0x00000444

00000034 <test4>:
  34:    4b02          ldr    r3, [pc, #8]    ; (40 <test4+0xc>)
  36:    4a03          ldr    r2, [pc, #12]    ; (44 <test4+0x10>)
  38:    6013          str    r3, [r2, #0]
  3a:    4a03          ldr    r2, [pc, #12]    ; (48 <test4+0x14>)
  3c:    6013          str    r3, [r2, #0]
  3e:    4770          bx    lr
  40:    00000666     .word    0x00000666
  44:    00000444     .word    0x00000444
  48:    000004c4     .word    0x000004c4

0000004c <test5>:
  4c:    4b02          ldr    r3, [pc, #8]    ; (58 <test5+0xc>)
  4e:    4a03          ldr    r2, [pc, #12]    ; (5c <test5+0x10>)
  50:    6013          str    r3, [r2, #0]
  52:    4a03          ldr    r2, [pc, #12]    ; (60 <test5+0x14>)
  54:    6013          str    r3, [r2, #0]
  56:    4770          bx    lr
  58:    00000666     .word    0x00000666
  5c:    44444444     .word    0x44444444
  60:    44444448     .word    0x44444448

00000064 <test6>:
  64:    4b02          ldr    r3, [pc, #8]    ; (70 <test6+0xc>)
  66:    4a03          ldr    r2, [pc, #12]    ; (74 <test6+0x10>)
  68:    6013          str    r3, [r2, #0]
  6a:    4a03          ldr    r2, [pc, #12]    ; (78 <test6+0x14>)
  6c:    6013          str    r3, [r2, #0]
  6e:    4770          bx    lr
  70:    00000666     .word    0x00000666
  74:    44444444     .word    0x44444444
  78:    444444c4     .word    0x444444c4


Compiled using:
https://launchpad.net/gcc-arm-embedded/4.9/4.9-2014-q4-major/+download/gcc-arm-none-eabi-4_9-2014q4-20141203-win32.exe

[Bug target/64774] [ARM/thumb] missed optimization: pc relative ldr used when constant can be derived from register

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64774

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm
           Priority|P3                          |P5
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-28
     Ever confirmed|0                           |1

--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Although the compiler tries to find some common cases, it is generally
infeasible to detect all the possible permutations that exist.  Furthermore, in
real code generating common expressions in this way can increase register
pressure and have additional impact on some optimization passes.

I don't hold out much hope of this sort of problem ever being entirely fixed.

[Bug target/64774] [ARM/thumb] missed optimization: pc relative ldr used when constant can be derived from register

[bruck.michael at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64774

--- Comment #2 from Michael Bruck <bruck.michael at googlemail dot com> ---
(In reply to Richard Earnshaw from comment #1)
> Although the compiler tries to find some common cases, it is generally
> infeasible to detect all the possible permutations that exist.  Furthermore,
> in real code generating common expressions in this way can increase register
> pressure and have additional impact on some optimization passes.
> 
> I don't hold out much hope of this sort of problem ever being entirely fixed.

I wonder if the logic that recognizes cases 1-3 could be expanded to work with
the rest too. It almost looks to me as if there is a bug that checks the size
of the constant and not the difference to decide what can be substituted with
an addition.

The register pressure issue could be avoided if the optimization is applied
later and only for cases where the value already happens to be in a register.