Adjust rx movsicc tests

Adjust rx movsicc tests

The rx port has target specific test movsicc which is naturally meant to verify
that if-conversion is happening on the expected cases.

Unfortunately the test is poorly written.  The core problem is there are 8
distinct tests and each of those tests is expected to generate a specific
sequence.  Unfortunately, various generic bits might turn an equality test
into an inequality test or make other similar changes.

The net result is the assembly matching patterns may find a particular sequence,
but it may be for a different function than was originally intended.  ie,
test1's output may match the expected assembly for test5.  Ugh!

This patch breaks the movsicc test down into 8 distinct tests and adjusts the
patterns they match.  The nice thing is all these tests are supposed to have
branches that use a bCC 1f form.  So we can make them a bit more robust by
ignoring the actual condition code used.  So if we change eq to ne, as long
as we match the movsicc pattern, we're OK.  And the 1f style is only used by
the movsicc pattern.

With the tests broken down it's a lot easier to diagnose why one test fails
after the recent changes to if-conversion.  movsicc-3 fails because of the
profitability test.  It's more expensive than the other cases because of its
use of (const_int 10) rather than (const_int 0).  (const_int 0) naturally has
a smaller cost.

It looks to me like in this context (const_int 10) should have the same cost
 as (const_int 0).  But I'm nowhere near well versed in the cost model for the
rx port.  So I'm just leaving the test as xfailed.  If someone cares enough,
they can dig into it further.

gcc/testsuite
	* gcc.target/rx/movsicc.c: Broken down into ...
	* gcc.target/rx/movsicc-1.c: Here.
	* gcc.target/rx/movsicc-2.c: Here.
	* gcc.target/rx/movsicc-3.c: Here.  xfail one test.
	* gcc.target/rx/movsicc-4.c: Here.
	* gcc.target/rx/movsicc-5.c: Here.
	* gcc.target/rx/movsicc-6.c: Here.
	* gcc.target/rx/movsicc-7.c: Here.
	* gcc.target/rx/movsicc-8.c: Here.