[PATCH] PR target/65242, Fix powerpc abort in gen_add2_insn

[Jeff Law]

On 03/11/15 08:44, David Edelsohn wrote:
> On Mon, Mar 9, 2015 at 7:30 PM, Michael Meissner
> <meissner@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  <meissner@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  <meissner@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