[RFC,IRA] Fix PR87507, IRA unnecessarily uses non-volatile registers during register assignment

PR87507 shows a problem where IRA assigns a non-volatile TImode reg pair to
a pseudo when there is a volatile reg pair available to use.  This then
causes us to emit save/restore code for the non-volatile reg usage.

The problem here is that the only volatile reg pair that is available is an
odd/even reg pair (r7,r8) and ira-costs.c:ira_tune_allocno_costs() disparages
odd/even reg pairs by increasing their cost.  That's fine, but an even/odd
non-volatile reg pair should still be more expensive than an odd/even reg
pair given the save/restore that we'd need to use it.  However, the costs
used in assign_hard_reg() show that non-volatile reg pair (r30,r31) is
cheaper than odd/even reg pair (r7,r8) (15 versus 1000).  That's a huge
disparity in costs, so looking at where the non-volatile cost comes from,
it comes from the code below in ira-color.c:assign_hard_reg():

       if (!HONOR_REG_ALLOC_ORDER)
	{
	  if ((saved_nregs = calculate_saved_nregs (hard_regno, mode)) != 0)
	  /* We need to save/restore the hard register in
	     epilogue/prologue.  Therefore we increase the cost.  */
	  {
	    rclass = REGNO_REG_CLASS (hard_regno);
	    add_cost = ((ira_memory_move_cost[mode][rclass][0]
			 + ira_memory_move_cost[mode][rclass][1])
			* saved_nregs / hard_regno_nregs (hard_regno,
							  mode) - 1);
	    cost += add_cost;
	    full_cost += add_cost;
	  }
	}

I'm not sure I understand the "* saved_nregs / h_r_n (h_r, m) - 1" part
of the calculation.  If saved_nregs is the number of hard regs that
need to be saved for hard_regno in mode MODE (ie, we don't need to
save a hard reg if it's already been saved, etc.), then why aren't we
just multiplying by saved_nregs?  The other problem I see here is
that we're not scaling the cost by the basic block frequency of the
prologue/epilogue, which is what is causing the non-volatile reg
cost to be so low compared to the odd/even volatile reg use, which
is scaled.  However, even if I fix that, improve_allocation() comes
along and undoes it, because it too does not correctly compute the
cost of non-volatiles, so that seems to me that it needs fixing too.

I have the following work in progress patch I'd like some comments on.
Am I on the right track here?  I noticed that assign_hard_reg() tracks
min_cost and min_full_cost, but min_cost is actually never used for
anything other than setting min_cost, so I removed it.  I also don't
understand why we don't charge non-volatile usage for targets that define
HONOR_REG_ALLOC_ORDER.  Why shouldn't we always account for save/restore
of non-volatile reg usage?  I'll note I did not change that behavior.

Thoughts on the patch below?  Vlad, can you comment on some of my
questions above?

Peter


gcc/
	PR rtl-optimization/87507
	* ira-color.c (calculate_saved_nregs): Rename from this...
	(calculate_saved_nregs_cost): ...to this.  Return cost of saving NREGS.
	(assign_hard_reg):
	(improve_allocation):

gcc/testsuite/
	PR rtl-optimization/87507
	* gcc.dg/pr10474.c: Don't XFAIL for powerpc*-*-*.
	* gcc.target/powerpc/vsx-vector-6.p8.c: Update expected output.

On 10/08/2018 03:36 PM, Peter Bergner wrote:
> PR87507 shows a problem where IRA assigns a non-volatile TImode reg pair to
> a pseudo when there is a volatile reg pair available to use.  This then
> causes us to emit save/restore code for the non-volatile reg usage.
>
> The problem here is that the only volatile reg pair that is available is an
> odd/even reg pair (r7,r8) and ira-costs.c:ira_tune_allocno_costs() disparages
> odd/even reg pairs by increasing their cost.  That's fine, but an even/odd
> non-volatile reg pair should still be more expensive than an odd/even reg
> pair given the save/restore that we'd need to use it.  However, the costs
> used in assign_hard_reg() show that non-volatile reg pair (r30,r31) is
> cheaper than odd/even reg pair (r7,r8) (15 versus 1000).  That's a huge
> disparity in costs, so looking at where the non-volatile cost comes from,
> it comes from the code below in ira-color.c:assign_hard_reg():
>
>         if (!HONOR_REG_ALLOC_ORDER)
> 	{
> 	  if ((saved_nregs = calculate_saved_nregs (hard_regno, mode)) != 0)
> 	  /* We need to save/restore the hard register in
> 	     epilogue/prologue.  Therefore we increase the cost.  */
> 	  {
> 	    rclass = REGNO_REG_CLASS (hard_regno);
> 	    add_cost = ((ira_memory_move_cost[mode][rclass][0]
> 			 + ira_memory_move_cost[mode][rclass][1])
> 			* saved_nregs / hard_regno_nregs (hard_regno,
> 							  mode) - 1);
> 	    cost += add_cost;
> 	    full_cost += add_cost;
> 	  }
> 	}
>
> I'm not sure I understand the "* saved_nregs / h_r_n (h_r, m) - 1" part
> of the calculation.  If saved_nregs is the number of hard regs that
> need to be saved for hard_regno in mode MODE (ie, we don't need to
> save a hard reg if it's already been saved, etc.), then why aren't we
> just multiplying by saved_nregs?  The other problem I see here is
> that we're not scaling the cost by the basic block frequency of the
> prologue/epilogue, which is what is causing the non-volatile reg
> cost to be so low compared to the odd/even volatile reg use, which
> is scaled.  However, even if I fix that, improve_allocation() comes
> along and undoes it, because it too does not correctly compute the
> cost of non-volatiles, so that seems to me that it needs fixing too.
It would be right if we have only one pseudo using non-volatile regs.  
But at this stage we don't know how many pseudos will use the 
non-volatile reg.  Once the non-volotile reg is used, it is free for all 
other pseudo uses (and they can be in hot regions as loops).

The costs were heuristically tuned on SPEC2000 on x86/x86-64.  As the 
functions are bigger (now we have aggressive inlining), the only small 
increase for non-volatile reg works better.  That is why I don't like 
small test RA PRs, the heuristics can be bad for them but they can work 
better for real programs.  When I change this code, I always check SPEC 
because sometimes the results are opposite to the expected ones.

May be you could find better heuristics which works for small and big 
functions.
> I have the following work in progress patch I'd like some comments on.
> Am I on the right track here?  I noticed that assign_hard_reg() tracks
> min_cost and min_full_cost, but min_cost is actually never used for
> anything other than setting min_cost, so I removed it.  I also don't
> understand why we don't charge non-volatile usage for targets that define
> HONOR_REG_ALLOC_ORDER.  Why shouldn't we always account for save/restore
> of non-volatile reg usage?
Once min_cost was used for different heuristics.  Still it is useful for 
debugging because full_cost calculations is very complicated (it is 
affected by conflict allocnos preferences and allocnos connected 
directly and indirectly by copies).  Min_cost can be useful in debugging 
to see the picture because its calculation is more straightforward.

A few years ago IRA did not use HONOR_REG_ALLOC_ORDER but people filled 
a PR (I don't remember the number) and that is what behaviour they 
exactly wanted.