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.
