Committed: fix PR49285, breakage building libgcc2 for MMIX

I needed a baseline for PR48542 (problems with setjmp/longjmp), but
building MMIX was broken on trunk.  It was "bitten" by the fixups to
predicate matching done recentlish.  The comment above the MMIX
truncdfsf2 expander complains about having to use an expander to
force an operand to memory - and then goes on and uses memory_operand
for that operand anyway!  That accidentally worked before the fixup,
because after copying the failing operand to a new pseudo, the
expander was called without the optabs machinery doublechecking the
new pseudo against the predicate.  While I stand by the comment and
still think the optabs machinery could automatically fix up operands
as needed to force an operand into memory when the predicate says so,
it hasn't worked like that before, and I guess it's no use adding
something like that just for one port, where an expander will do.

Committed after building and regtesting for MMIX, where the build
failed in libgcc2.c.  FWIW, there's a whopping 252 regressions on the
4.6-branch and 256 on trunk (after this patch) according to Geoff's
test-script compared to gcc-4.5 era, with "just" 1..6 regressions for
the 4.3, 4.4 and 4.5 branches.  Ouch.

gcc:

	PR target/49285
	* config/mmix/mmix.md ("truncdfsf2", "extendsfdf2"): Correct
	predicate to nonimmediate_operand from memory_operand for the
	operand that is to be forced to memory by the expander.  Lose
	the constraints.


brgds, H-P

Hans-Peter Nilsson <hp@bitrange.com> writes:
> I needed a baseline for PR48542 (problems with setjmp/longjmp), but
> building MMIX was broken on trunk.  It was "bitten" by the fixups to
> predicate matching done recentlish.  The comment above the MMIX
> truncdfsf2 expander complains about having to use an expander to
> force an operand to memory - and then goes on and uses memory_operand
> for that operand anyway!  That accidentally worked before the fixup,
> because after copying the failing operand to a new pseudo, the
> expander was called without the optabs machinery doublechecking the
> new pseudo against the predicate.  While I stand by the comment and
> still think the optabs machinery could automatically fix up operands
> as needed to force an operand into memory when the predicate says so,
> it hasn't worked like that before, and I guess it's no use adding
> something like that just for one port, where an expander will do.

FWIW, having a target-independent feature sounds like a good idea to me.
It's similar in spirit to the new code that tries to force addresses
into registers if a memory predicate rejects a mem.  That too is something
that was often handled by expanders, but which is nicer without.

The implementation could be along the same lines.  Have an allows_reg
field in recog_data that says whether the predicate allows registers.
If it doesn't, try forcing to a stack slot instead of to registers.

Richard