Hans-Peter Nilsson <h...@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
