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.

Reply via email to