On 03/11/15 08:44, David Edelsohn wrote:
On Mon, Mar 9, 2015 at 7:30 PM, Michael Meissner
<meiss...@linux.vnet.ibm.com> wrote:
This bug was one I unfortunately introduced with the -mupper-regs support. If
the reload pass needed to reload a PLUS operation (for example, due to using
odd address with the LD/STD instructions), it would go through all of the
registers you could load DImode into, and see if it is a preferred register
class. This lead the compiler to believe it could do integer arithmetic in the
floating point registers.
This patch fixes the problem, by not allowing PLUS to be reloaded into FPR
registers. I have done bootstraps and make checks on both a big endian Power7
and a little endian Power8 system, and there were no regressions. Is the patch
ok to apply? I do not believe it needs to be back ported to GCC 4.9 since the
-mupper-regs changes are not installed currently on that branch.
[gcc]
2015-03-09 Michael Meissner <meiss...@linux.vnet.ibm.com>
PR target/65242
* config/rs6000/rs6000.c (rs6000_preferred_reload_class): Do not
allow reloads of PLUS in floating point/VSX registers.
[gcc/testsuite]
2015-03-09 Michael Meissner <meiss...@linux.vnet.ibm.com>
PR target/65242
* g++.dg/pr65242.C: New test.
This is okay.
What about Jeff Law's Bugzilla comment #6 to change ?m to !m in the
movdi_internal64 pattern? That also seems reasonable.
It doesn't matter much to me either way as long as it gets fixed :-)
Avoiding floating point registers via preferred reload class is a valid
approach. My only concern then would be cases where we have similar
looking arithmetic and even though we no longer prefer the FP classes,
we still end up selecting that problematical alternative -- say perhaps
because the pseudos in question have many other uses where FP regs make
sense.
I know we could get into those kind of situations on the PA because of
the weird way in which integer multiplies were implemented (FP unit,
using FP regs) -- which could occur even when using '?' to disparage
those alternatives. I'm not familiar enough with PPC implementations to
know if we can get into that same situation with that port.
Jeff
