func_david PROC
        PUSH     {r4,r5}
        ADD      r12,r0,r1,LSL #2
        LDR      r3,[r0,#0]
        ADD      r1,r0,#4
        SUB      r12,r12,r1
        TST      r3,#1
        ADDNE    r3,r3,r2,LSL #1
        STRNE    r3,[r0,#0]
        MOV      r0,#1
        ADD      r4,r0,r12,ASR #2
        CMP      r4,#1
        BLE      |L1.316|
|L1.280|
        MOV      r3,r1
        ADD      r0,r0,#1
        ADD      r1,r1,#4
        LDR      r12,[r3,#0]
        TST      r12,#1
        ADDNE    r12,r12,r2,LSL #1
        STRNE    r12,[r3,#0]
        CMP      r4,r0
        BGT      |L1.280|
|L1.316|
        POP      {r4,r5}
        BX       lr
        ENDP

The comment was:

“hardwarebug_20100130.c”, line 58: #1636-D: Could not optimize: Complicated use of variable (q)

Stack alignment is only necessary in non-leaf functions as you stated. So every once in a while you will see single registers pushed on the stack. Why the compiler thought this was needed in your example, I don’t know.

Regards
Marcus

void func(struct bf1_31 *p, int n, int a)
{
    struct bf1_31 *pend= &p[n];
    do {
        struct bf1_31 *q;
        if ((q=p++)->a)
            q->b += a;
    } while (p < pend);
}

Using old RVCT3.1 build 569 produces:

func PROC
        ADD      r12,r0,r1,LSL #2
        PUSH     {lr}
|L1.8|
        MOV      r3,r0
        LDR      r1,[r0],#4
        TST      r1,#1
        ADDNE    r1,r1,r2,LSL #1
        STRNE    r1,[r3,#0]
        CMP      r0,r12
        BCC      |L1.8|
        POP      {pc}
        ENDP

This same source even generates good –thumb code.

I’m however mystified why it pushes LR and pops PC in a leaf function. Maybe the branch predictor
influences cache victim selection to not immediately evict the calling code.

But I think the compiler will push multiples of two registers for architecture v5te and up to keep the stack 8-byte aligned. For that I'd blame xScale’s LDRD/STRD.

I think a fairer thing to say is “even the best compilers are still no match for the best humans, given infinite time and ingenuity.”

I frequently am pleasantly surprised at how clever a compiler is being on my behalf. For example, gcc knows how to turn “n / 1000000UL;” into “(n * 1125899907) >> 50″. Maybe if you locked me in a room for an hour and demanded that I optimize that expression I would have come up with that. But the compiler thought of it for me in a fraction of a second.

After all, everything a compiler does is something a human thought of first, so naturally a compiler isn’t going to outdo the smartest human with an expertise for the architecture. But it’s definitely going to outdo a lot of people. It’s also much less error-prone.

Also, picking on GCC-on-ARM is like bullying the pipsqueak on the playground. :)

void func(struct bf1_31 *p, int n, int a)
{
    int i;

    unsigned int *q = (unsigned int *)p;

    #pragma unroll(1) // prevent loop unrolling for comparison
    for (i=0; i<n; i++) {
        if (*q & 1)
            *q++ = *q + 2*a;
    }
}

This is hardly more portable than assembler (depends on bit-field
layout) and took about ten times as long to come up with :-) but this
is the compiler generated assembler code (RVCT, Build 697, -O3 -Otime):

func PROC
        CMP      r1,#0
        BXLE     lr
|L1.148|
        LDR      r3,[r0,#0]
        TST      r3,#1
        ADDNE    r3,r3,r2,LSL #1
        STRNE    r3,[r0],#4
        SUBS     r1,r1,#1
        BNE      |L1.148|
        BX       lr
        ENDP

Regards
Marcus