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.
