Bug 69460

Created attachment 37451 [details]
Test Source

Tested on GCC 4.9 and 5.2, under Linux (Ubuntu 15.10/64 bit)
I am using the pre-built toolchains available at https://launchpad.net/gcc-arm-embedded

When compiling for a Cortex M0 target i noticed some poor code generation with regard to literal tables.  I compared that code generation to code generation to Cortex M3 and it produces much better code.  It became apparent that the code generated for the M3 was actually legal M0 code and so could execute unmodified on a M0 core.  Accordingly, the Cortex M0 is needlessly producing suboptimal code vs the same code compiled for Cortex M3.

There are six tests in the test case, all accessing memory via different patterns.  ALL generate suboptimal code for Cortex M0 vs the Cortex M3 code generator, yet all code produced is legal Cortex M0 code. Example of the sub-optimal code generation:

Test 6:

/* Write 8 bit values to known register locations - using an array */
void test6(void)
{
    volatile uint8_t* const r = (uint8_t*)(0x40002800U); // Register Array

    r[0] = 0xFF;
    r[1] = 0xFE;
    r[2] = 0xFD;
    r[3] = 0xFC;
    r[4] = 0xEE;
    r[8] = 0xDD;
    r[12] = 0xCC;
}

Which, at -Os for -mcpu-cortex-m0 results in:
000000ec <test6>:
  ec: 22ff movs r2, #255 ; 0xff
  ee: 4b0a ldr r3, [pc, #40] ; (118 <test6+0x2c>)
  f0: 701a strb r2, [r3, #0]
  f2: 4b0a ldr r3, [pc, #40] ; (11c <test6+0x30>)
  f4: 3a01 subs r2, #1
  f6: 701a strb r2, [r3, #0]
  f8: 4b09 ldr r3, [pc, #36] ; (120 <test6+0x34>)
  fa: 3a01 subs r2, #1
  fc: 701a strb r2, [r3, #0]
  fe: 4b09 ldr r3, [pc, #36] ; (124 <test6+0x38>)
 100: 3a01 subs r2, #1
 102: 701a strb r2, [r3, #0]
 104: 4b08 ldr r3, [pc, #32] ; (128 <test6+0x3c>)
 106: 3a0e subs r2, #14
 108: 701a strb r2, [r3, #0]
 10a: 4b08 ldr r3, [pc, #32] ; (12c <test6+0x40>)
 10c: 3a11 subs r2, #17
 10e: 701a strb r2, [r3, #0]
 110: 4b07 ldr r3, [pc, #28] ; (130 <test6+0x44>)
 112: 3a11 subs r2, #17
 114: 701a strb r2, [r3, #0]
 116: 4770 bx lr
 118: 40002800 .word 0x40002800
 11c: 40002801 .word 0x40002801
 120: 40002802 .word 0x40002802
 124: 40002803 .word 0x40002803
 128: 40002804 .word 0x40002804
 12c: 40002808 .word 0x40002808
 130: 4000280c .word 0x4000280c

Each element accessed in the array of bytes has resulted in the address of that element appearing in the literal table. !!!!

By comparison the M3 build generates :

00000094 <test6>:
  94: 4b07 ldr r3, [pc, #28] ; (b4 <test6+0x20>)
  96: 22ff movs r2, #255 ; 0xff
  98: 701a strb r2, [r3, #0]
  9a: 22fe movs r2, #254 ; 0xfe
  9c: 705a strb r2, [r3, #1]
  9e: 22fd movs r2, #253 ; 0xfd
  a0: 709a strb r2, [r3, #2]
  a2: 22fc movs r2, #252 ; 0xfc
  a4: 70da strb r2, [r3, #3]
  a6: 22ee movs r2, #238 ; 0xee
  a8: 711a strb r2, [r3, #4]
  aa: 22dd movs r2, #221 ; 0xdd
  ac: 721a strb r2, [r3, #8]
  ae: 22cc movs r2, #204 ; 0xcc
  b0: 731a strb r2, [r3, #12]
  b2: 4770 bx lr
  b4: 40002800 .word 0x40002800

ALL of which is LEGAL M0 Code.

The Cortex M0 compile is:
72 Bytes Long, 22 Instructions and 7 Literal Table Entries and 7 reads from Code Space.

The Cortex M3 compile (which generates legal M0 code) is:
36 Bytes Long, 16 Instructions and 1 Literal Table Entry and 1 read from Code Space.

Significantly more efficient in every respect.

Given that Cortex M0 cores usually have less resources than Cortex M3 cores, I would expect the code generation to be the same between them, unless there is an ability to use an instruction which only exists on a Cortex M3.  This inefficient code generation will make Cortex M0 cores seem much less efficient and much slower than they are in reality.

Attached is a the test case and a script to build it.

The script builds the code for M0 and M3, it then dumps the M3 assembler, patches it so that it can be assembled as M0 assembler and assembles the result.
The reason for that is to confirm that the M3 generated code is LEGAL M0 Code, which it is.