Georg-Johann Lay <a...@gjlay.de> writes: > If general_operand can be perceived as > > (define_predicate "general_operand" > (ior (match_operand 0 "memory_operand") > (match_operand 0 "register_operand") > (match_operand 0 "immediate_operand"))) > > how can low_io_mem ever match?
Oh, I see, I did misunderstand your question. Sorry about that. In general combine is just going to honor what your backend is asking for. If your backend says that it is OK to combine a volatile memory operand, then that is what combine is going to do. It's certainly OK in general to combine across a volatile memory operand, as is happening here. I guess you are asking whether combine should have another check: if some operand in the insn is a volatile MEM, and it will cross a volatile MEM not mentioned in the combine, should combine reject that combination. It's a case that will never ordinarily arise. It only arises for you because you are specifically trying to combine a volatile MEM. I don't know if it makes sense for the general purpose combine to try to handle such an unusual special case. Have you tried using a peephole instead of a combine pattern? Ian
