[RFA] [PATCH][PR tree-optimization/59749] Fix recently introduced ree bug

Jeff Law law@redhat.com
Fri Jan 17 21:51:00 GMT 2014


On 01/16/14 15:07, Jakub Jelinek wrote:
> On Thu, Jan 16, 2014 at 02:31:09PM -0700, Jeff Law wrote:
>> +2014-01-16  Jeff Law  <law@redhat.com>
>> +
>> +	* ree.c (combine_set_extension): Correct test for changing number
>> +	of hard registers when widening a reaching definition.
>> +
>>   2014-01-16  Bernd Schmidt  <bernds@codesourcery.com>
>>
>>   	PR middle-end/56791
>> diff --git a/gcc/ree.c b/gcc/ree.c
>> index 19d821c..96cddd2 100644
>> --- a/gcc/ree.c
>> +++ b/gcc/ree.c
>> @@ -300,7 +300,8 @@ combine_set_extension (ext_cand *cand, rtx curr_insn, rtx *orig_set)
>>     /* We're going to be widening the result of DEF_INSN, ensure that doing so
>>        doesn't change the number of hard registers needed for the result.  */
>>     if (HARD_REGNO_NREGS (REGNO (new_reg), cand->mode)
>> -      != HARD_REGNO_NREGS (REGNO (orig_src), GET_MODE (SET_DEST (*orig_set))))
>> +      != HARD_REGNO_NREGS (REGNO (SET_DEST (*orig_set)),
>> +			   GET_MODE (SET_DEST (*orig_set))))
>
> Shouldn't that be:
>      if (HARD_REGNO_NREGS (REGNO (new_reg), cand->mode)
> 	!= HARD_REGNO_NREGS (REGNO (new_reg), GET_MODE (SET_DEST (*orig_set))))
> instead?
>
> I mean, for the !copy_needed case it is obviously the same thing (and that
> is what triggers in the testcase), but don't we generally want to check if
> the same hard register in a wider mode will not occupy more registers, and
> in particular the hard register we are considering to use on the lhs of the
> defining insn (i.e. new_reg)?
I thought about using that conditional more than once.  But talked 
myself out of it every time on the grounds that I wanted to test the 
original destination REGNO of the reaching def.

Obviously that is REGNO (new_reg) if !copy_needed.  But it's something 
completely different if copy_needed.


In the copy_needed case there's actually two destinations to consider. 
  The original destination as well as the new destination.  Both will be 
set in a mode wider than the destination of the original reaching def. 
(one will be set in the modified reaching def and the other in a copy insn).

ISTM we need the # hard reg checked on the original destination as the 
other (upper) hard regs might be live across the sequence, but not 
used/set in the sequence.   Then we need some kind of check on the upper 
part of the new destination...  But I thought I covered that elsewhere...

Anyway, I clearly need to rethink that test.  Given this is something we 
haven't seen in the wild, I'm going to disable it over the 
weekend/monday so that enable-checking bugs pass and continue to ponder.

jeff




More information about the Gcc-patches mailing list