gcc.dg/pr30957-1.c: xfail for mmix.

gcc.dg/pr30957-1.c: xfail for mmix.

IV (loop2_unroll) doesn't like the mmix port.  The feelings are mutual.

For mmix, gcc.dg/pr30957-1.c fails (runtime and rtl-scan) for these
reasons:

- IV doesn't handle the zero-extension-by-shift sequences generated by
  middle-end (expr.c:convert_mode_scalar) in the absence of
  zero-extend patterns in a port.

- (when adding such patterns)
  IV doesn't understand the subreg constructs generated by middle-end
  in the absence of addsi3 and compare/branch in SImode (int).

- (when hacking pr30957-1.c to iterate using a register-mode type)
  IV doesn't understand the admittedly weird SFmode operations
  (performing in DFmode, then truncating, for lack of SFmode
  operations, but presence of truncdfsf2 and float_extendsfdf2) in
  order to perform the "Expanding Accumulator" optimization.  When
  also editing the type in the test to be double instead of float, the
  test passes.

While at least the last point seems like a valid reason to just skip
the test for mmix, it also seems possible that IV (and maybe
convert_mode_scalar by e.g. adding REG_EQUIV notes) be improved to be
both smarter and dumber to actually make the test pass, so I think
it's better to use xfail.  Smarter: understanding zero-extend-
by-shift and subregged operations better, and "seeing" the
accumulation through the DF/SFmode truncations and expansions.
Dumber: ignoring the cost; unrolling the several operations per SFmode
add anyway.

I'm considering adding a variant of this test with "double" and
"__SIZE_TYPE__" iteration types, as that passes for mmix as-is.
Maybe as a mmix-specific test; the world has suffered enough from the
questionable gcc.dg/pr30957-1.c (see the test and its history).

gcc/testsuite:
	* gcc.dg/pr30957-1.c: xfail for mmix.