[Bug tree-optimization/51281] New: GCC fails to hoist stores in loop

[darkshikari at gmail dot com]

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

             Bug #: 51281
           Summary: GCC fails to hoist stores in loop
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: darkshikari@gmail.com


void foo( int *x )
{
    for(int i=0; i<100; i++) 
        asm("inc %0" :"+r"(*x));
}

This generates the following on gcc 4.5.3:

0000000000000000 <foo>:
   0:   b8 64 00 00 00          mov    eax,0x64
   5:   8b 17                   mov    edx,[rdi]
   7:   ff c2                   inc    edx
   9:   0f 1f 80 00 00 00 00    nop    dword[rax+0x0]
  10:   83 e8 01                sub    eax,0x1
  13:   89 17                   mov    [rdi],edx
  15:   75 f9                   jne    10 <foo+0x10>
  17:   f3 c3                   repz ret

And the following on gcc svn:

0000000000000000 <foo>:
   0:   b8 64 00 00 00          mov    eax,0x64
   5:   8b 17                   mov    edx,[rdi]
   7:   ff c2                   inc    edx
   9:   0f 1f 80 00 00 00 00    nop    dword[rax+0x0]
  10:   83 e8 01                sub    eax,0x1
  13:   89 17                   mov    [rdi],edx
  15:   75 f9                   jne    10 <foo+0x10>
  17:   f3 c3                   repz ret

gcc fails to hoist out the store, doing it on every loop iteration, despite
being told to keep *x in a register.  This occurs in all versions of gcc,
including latest svn.

This may seem like an utterly pointless test case, but this is causing
significant performance degradation in actual code, where gcc repeatedly stores
the outputs of inline assembly at the end of each loop iteration, instead of
keeping them in registers as it should.  This causes insertion of huge numbers
of redundant stores in certain cases.  I initially thought it was an aliasing
issue of some sort, but this test case demonstrates that it happens even in the
simplest of cases, which is rather bizarre.

Is this optimization supposed to happen, or is a missing optimization?