On Thu, Dec 1, 2011 at 10:40 PM, Georg-Johann Lay <a...@gjlay.de> wrote: > Ian Lance Taylor wrote: > >> Georg-Johann Lay 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. > > > Supplying an insn is the backend's way of telling that it is capable of > performing a specific operation. > > In the present case, the backend tells that it has a "Conditional Jump > depending on a bit in the I/O area". > > It does *not* say "It is ok to infringe volatile correctness" and move one > volatile memory access across an other one or similar memory annotation like > memory clobber by means of inline assembly or built-in barrier. > > >> 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 never correct to exchange volatile accesses.
That's not true. volatile accesses to different memory locations have no special dependence. If it happens that GCC doesn't do this kind of things then this is only because most passes don't thouch volatile stmts at all (thus the reports for sub-optimal code with volatile - we don't even try to do legal transformations). Richard.
