[committed] Make r10k-cache-barrier-10.c more robust

[Richard Sandiford <rdsandiford at googlemail dot com>]

The loop in this test is supposed to trigger a likely (annulled)
back-branch.  However, "n" is naturally in $4 on entry to the loop
and naturally in $2 on the back edge.  Usually the move from $4
to $2 was outside the loop, but for -funroll-loops it was at the
end of the loop body, and could be safely put in the delay slot
of a normal back-branch.

Perhaps the move should be outside the loop even with -funroll-loops,
but it's hard to say from an artifical test like this.  The move in
its current position is only needed after 8 calls to bar, whereas a
move before the loop would always be executed.  Stuff like that
should be left to real benchmarks, so here I've just tweaked the
test so that "n" can be naturally in $2 on both edges.

Tested on mips64-linux-gnu and applied.

Richard


gcc/testsuite/
	* gcc.target/mips/r10k-cache-barrier-10.c: Make a branch-likely
	instruction more likely.

Index: gcc/testsuite/gcc.target/mips/r10k-cache-barrier-10.c
===================================================================
--- gcc/testsuite/gcc.target/mips/r10k-cache-barrier-10.c	2012-12-23 09:14:02.000000000 +0000
+++ gcc/testsuite/gcc.target/mips/r10k-cache-barrier-10.c	2012-12-23 09:19:45.559582821 +0000
@@ -9,6 +9,12 @@ unsigned char *bar (int);
 NOMIPS16 void
 foo (unsigned char *n)
 {
+  /* n starts in $4, but will be in $2 after the call to bar.
+     Encourage it to be in $2 on entry to the loop as well,
+     by doing some computation on it beforehand (D?ADDIU $2,$4,4).
+     dbr_schedule should then pull the *n load (L[WD] ...,0($2))
+     into the delay slot.  */
+  n += 4;
   do
     n = bar (*n + 1);
   while (n);