[Bug c/52897] New: gcc 4.7.0 generates worse code than gcc 3.4.6 for m68000

[Bug c/52897] New: gcc 4.7.0 generates worse code than gcc 3.4.6 for m68000

[fdarkangel at gmail dot com]

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

             Bug #: 52897
           Summary: gcc 4.7.0 generates worse code than gcc 3.4.6 for
                    m68000
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: fdarkangel@gmail.com


cube_flat demo included with SGDK (http://code.google.com/p/sgdk) performed
very differently when compiled with gcc 3.4.6 and gcc 4.7.0. Attached code was
the core of the problem; you can find the assembly codes generated by -O2,
although the problem appears at -O3 as well.

I also noticed that turning off gsce adds a pointless "move.l #12582912,%a1"
instruction (.L3 of bmp-gcc4-O2-no-gcse.s), which doesn't appear in gcc3.

[Bug c/52897] gcc 4.7.0 generates worse code than gcc 3.4.6 for m68000

[fdarkangel at gmail dot com]

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

--- Comment #1 from fdarkangel at gmail dot com 2012-04-07 08:36:41 UTC ---
Created attachment 27110
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27110
C code demonstrating the problem + assembly output of gcc3 and gcc4

[Bug c/52897] gcc 4.7.0 generates worse code than gcc 3.4.6 for m68000

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> 2012-04-07 10:33:05 UTC ---
I see two obvious performance problems in the gcc-4.7.0 code for the second
loop:

- Instead of doing memory-to-memory moves it does load;store sequences.

- GCC apparently attempted to avoid moves with 16-bit immediate offsets by
setting up a bunch of address registers sparsely in the source array and then
using auto-increment addressing modes when loading from them; that could have
been a win, but gcc had to spill one of those address registers so the code
becomes rather awful.

Neither version of gcc managed to hoist the constant destination address into
an address register, so that 32-bit immediate appears many times in the loops.

[Bug target/52897] gcc 4.7.0 generates worse code than gcc 3.4.6 for m68000

[fdarkangel at gmail dot com]

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

--- Comment #3 from fdarkangel at gmail dot com ---
Persists in gcc 4.8.2.

[Bug target/52897] gcc 4.7.0 generates worse code than gcc 3.4.6 for m68000

[fdarkangel at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52897

--- Comment #4 from fdarkangel at gmail dot com ---
Bump. Any news? gcc 4.9.1 doesn't look good either.

[Bug target/52897] gcc 4.7.0 generates worse code than gcc 3.4.6 for m68000

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52897

--- Comment #5 from Mikael Pettersson <mikpelinux at gmail dot com> ---
I'm afraid that improving performance on m68k is not a high priority for most
gcc developers.  Interested parties may have to do the work themselves, or hire
someone to do it for them.

[Bug target/52897] gcc 4.7.0 generates worse code than gcc 3.4.6 for m68000

[fdarkangel at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52897

--- Comment #6 from fdarkangel at gmail dot com ---
I don't think hobbyist Sega Genesis devs are willing to hire gcc a hacker to
solve the issue. 
My bet is no one in the world with money is using m68k.

Why not drop m68k altogether then?

There's still hope for an m68k version of LLVM though.

[Bug target/52897] gcc 4.7.0 generates worse code than gcc 3.4.6 for m68000

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52897

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-16
                 CC|                            |law at redhat dot com
     Ever confirmed|0                           |1

--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
It would be best to describe the m68k port as in maintenance mode only.  As
Mikael noted, it's certainly not a priority anymore, but we do make an effort
to fix correctness issues, particularly those which are regressions relative to
prior releases.

Code generation improvements are significantly lower in terms of priority. 
However, if you're able to show the same code regressing from a performance
standpoint on another more common platform (say m68k, aarch64, power), then
there's a better chance someone will devote some time to the issue since it's
likely a target independent missed optimization.

The first thing I notice when I look at this bug is that as we come out of the
SSA optimizers we've split the memory references.  That isn't inherently wrong
as we have RTL optimizers that ought to be able to put them back together.  
But that doesn't happen because the key memory objects are declared volatile.

If I remove the volatile designation I get dramatically better code because we
end up doing memory->memory moves rather than load into a register then a store
from the register.

I suspect this particular issue is only going to show up on targets where we
have memory-to-memory moves which is relatively rare.