http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #6 from Oleg Endo <oleg.e...@t-online.de> 2011-10-30 13:53:51 UTC --- (In reply to comment #1) > GCC makes usual mem accesses into those with post_inc/pre_dec at > auto_inc_dec pass. I guess that auto_inc_dec pass can't find > post_inc insns well in that case because other tree/rtl optimizers > tweak the code already. If this is the case, the problem would be > not target specific. Looks like so. For the simple test case... int test (char* p, int c) { int r = 0; r += *p++; r += *p++; r += *p++; return r; } ...the load insns are initially expanded as: (insn 2 5 3 2 (set (reg/v/f:SI 169 [ p ]) (reg:SI 4 r4 [ p ])) (nil)) (insn 7 6 8 3 (set (reg:SI 171) (sign_extend:SI (mem:QI (reg/v/f:SI 169 [ p ]) [0 *p_2(D)+0 S1 A8]))) (nil)) (insn 8 7 9 3 (set (reg:SI 172) (reg/v/f:SI 169 [ p ])) (nil)) (insn 9 8 10 3 (set (reg/f:SI 173) (plus:SI (reg/v/f:SI 169 [ p ]) (const_int 1 [0x1]))) (nil)) (insn 10 9 11 3 (set (reg:SI 174) (sign_extend:SI (mem:QI (reg/f:SI 173) [0 MEM[(char *)p_2(D) + 1B]+0 S1 A8]))) (nil)) (insn 13 12 14 3 (set (reg/f:SI 177) (plus:SI (reg/v/f:SI 169 [ p ]) (const_int 2 [0x2]))) (nil)) (insn 14 13 15 3 (set (reg:SI 178) (sign_extend:SI (mem:QI (reg/f:SI 177) [0 MEM[(char *)p_2(D) + 2B]+0 S1 A8]))) (nil)) The auto_inc_dec pass then fails to realize that (reg:SI 177) = (reg:SI 169) + 2 = (reg:SI 173) + 1. I wonder whether there might be something in the target code that suggests the early optimizers to do that? I've tried playing with the TARGET_ADDRESS_COST hook but it didn't have any effect in this case.