While compiling compression code for LZMA for use with an embedded ARM target I have discovered a regression from previous editions of GCC.

I have pared this down to a trivial example (attached) which boils down to a application specific modulus operation (please note this is the *minimal* test case and obviously is a bit more complex buried in the middle of the compression system. The behavior exhibited remains the same in both the large and small systems.

The simple test case is compiled with  
arm-unknown-linux-gnu-gcc -Os -o foo test.c

and the resulting objdump is:

000083fc <foo>:
    83fc:       e92d4010        push    {r4, lr}
    8400:       e5d11000        ldrb    r1, [r1]
    8404:       e1a04000        mov     r4, r0
    8408:       e1a02001        mov     r2, r1
    840c:       ea000002        b       841c <foo+0x20>
    8410:       e5943004        ldr     r3, [r4, #4]
    8414:       e2833001        add     r3, r3, #1      ; 0x1
    8418:       e5843004        str     r3, [r4, #4]
    841c:       e242302d        sub     r3, r2, #45     ; 0x2d
    8420:       e352002c        cmp     r2, #44 ; 0x2c
    8424:       e20320ff        and     r2, r3, #255    ; 0xff
    8428:       8afffff8        bhi     8410 <foo+0x14>
    842c:       e1a00001        mov     r0, r1
    8430:       e3a0102d        mov     r1, #45 ; 0x2d
    8434:       eb000003        bl      8448 <__umodsi3>
    8438:       e20000ff        and     r0, r0, #255    ; 0xff
    843c:       e5840000        str     r0, [r4]
    8440:       e8bd8010        pop     {r4, pc}

if a differing optimisation is used:

arm-unknown-linux-gnu-gcc -O2 -o foo test.c

000083fc <foo>:
    83fc:       e92d4070        push    {r4, r5, r6, lr}
    8400:       e5d14000        ldrb    r4, [r1]
    8404:       e354002c        cmp     r4, #44 ; 0x2c
    8408:       e1a06000        mov     r6, r0
    840c:       9a00000e        bls     844c <foo+0x50>
    8410:       e244402d        sub     r4, r4, #45     ; 0x2d
    8414:       e20440ff        and     r4, r4, #255    ; 0xff
    8418:       e5905004        ldr     r5, [r0, #4]
    841c:       e3a0102d        mov     r1, #45 ; 0x2d
    8420:       e1a00004        mov     r0, r4
    8424:       eb00004f        bl      8568 <__umodsi3>
    8428:       e3a0102d        mov     r1, #45 ; 0x2d
    842c:       e1a03000        mov     r3, r0
    8430:       e1a00004        mov     r0, r4
    8434:       e20340ff        and     r4, r3, #255    ; 0xff
    8438:       eb000006        bl      8458 <__aeabi_uidiv>
    843c:       e2855001        add     r5, r5, #1      ; 0x1
    8440:       e20000ff        and     r0, r0, #255    ; 0xff
    8444:       e0855000        add     r5, r5, r0
    8448:       e5865004        str     r5, [r6, #4]
    844c:       e5864000        str     r4, [r6]
    8450:       e8bd8070        pop     {r4, r5, r6, pc}

Actually several optimization levels were tried and all produced similar output

GCC 4.2.2 and 4.2.4 (which are our current compliers) 
arm-unknown-linux-gnueabi-gcc -Os -o foo test.c
produce:

00008328 <foo>:
    8328:       e5d12000        ldrb    r2, [r1]
    832c:       ea000003        b       8340 <foo+0x18>
    8330:       e5903004        ldr     r3, [r0, #4]
    8334:       e20120ff        and     r2, r1, #255    ; 0xff
    8338:       e2833001        add     r3, r3, #1      ; 0x1
    833c:       e5803004        str     r3, [r0, #4]
    8340:       e352002c        cmp     r2, #44 ; 0x2c
    8344:       e242102d        sub     r1, r2, #45     ; 0x2d
    8348:       8afffff8        bhi     8330 <foo+0x8>
    834c:       e5802000        str     r2, [r0]
    8350:       e12fff1e        bx      lr



As can be seen the trivial loop is performed and the divisor and remainder found but then the __umodsi3 builtin is called to do the operation *again* and that used to assign the result which is already available from the loop!

This odd behavior is seen in cross built (and native) GCC 4.3.2 but not in 4.2.4 it seems to be present in current development builds however I have issues building those reliably so cannot give definite results.

The behavior is especially obvious with large performance and code size degradation in compression code on small embedded system. Also the additional need to link in the __umodsi3 implementation causes more space to be lost. 

This has also been observed in some circumstances within ARM kernels when using modulous on powers of two! the obvious optimisation using shifts is performed and then the value recomputed using __modsi3

Just for completeness here is the GCC 4.3.2 compiler used for the tests (the 4.3.4 produces identical compiled output but has other undesirable behaviors not relevant to this report)

arm-unknown-linux-gnu-gcc -v
Using built-in specs.
Target: arm-unknown-linux-gnu
Configured with: /opt/simtec/crosstool-ng/targets/src/gcc-4.3.2/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=arm-unknown-linux-gnu --prefix=/opt/simtec/arm-unknown-linux-gnu --with-sysroot=/opt/simtec/arm-unknown-linux-gnu/arm-unknown-linux-gnu/sys-root --enable-languages=c,c++,fortran,java --disable-multilib --with-float=soft --with-gmp=/opt/simtec/arm-unknown-linux-gnu --with-mpfr=/opt/simtec/arm-unknown-linux-gnu --with-pkgversion=crosstool-NG-1.3.0 --enable-__cxa_atexit --with-local-prefix=/opt/simtec/arm-unknown-linux-gnu/arm-unknown-linux-gnu/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace
Thread model: posix
gcc version 4.3.2 (crosstool-NG-1.3.0)