[Bug target/53938] ARM target generates sub-optimal code (extra instructions) on load from memory

["rearnsha at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #4 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Trunk as of this weekend still generates:

        mov     r3, #-536870912
        ldrb    r1, [r3]        @ zero_extendqisi2
        ldrb    ip, [r3]        @ zero_extendqisi2
        and     r1, r1, #255
        ldrh    r2, [r3]
        tst     r1, #128
        movne   r1, #0
        tst     r2, #128
        movne   r2, #0
        mov     ip, ip, asl #24
        ldrh    r0, [r3]
        add     r1, r1, ip, asr #24
        add     r2, r1, r2
        mov     r0, r0, asl #16
        add     r0, r2, r0, asr #16
        bx      lr

The real problem is that the RTL expansion passes never generate zero- or
sign-extended values directly.  They expect combine to pick this up. 
Unfortunately, combine won't touch a memory access that is volatile.  

What does still surprise me is that we fail to eliminate the zero-expand
operation.  After expand we have:

(insn 8 7 9 (set (reg:SI 126)
        (zero_extend:SI (mem/v:QI (reg/f:SI 124) [0 MEM[(union io
*)3758096384B].uch+0 S1 A64]))) test.c:30 -1
     (nil))

(insn 9 8 10 (set (reg:QI 125)
        (subreg:QI (reg:SI 126) 0)) test.c:30 -1
     (nil))

(insn 10 9 0 (set (reg/v:SI 111 [ i ])
        (and:SI (subreg:SI (reg:QI 125) 0)
            (const_int 255 [0xff]))) test.c:30 -1
     (nil))

I would have expected at the very least that some pass would have worked out
that regs 126 and 111 are equivalent.