Georg-Johann Lay <a...@gjlay.de> writes: > Ian Lance Taylor wrote: > >> 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. > > It's not unusual because: > > * It's not unusual to write down SFRs as violatile memory like > (*((volatile unsigned int*) 0x1234)) or as a cast to a composite > that reflects the SFRs bit(field)s. > > * It's not unusual that microcontrollers can access specific parts > of memory -- in particular I/O -- with special instructions.
Sure. What's unusual here is using combine, not those two requirements. >> Have you tried using a peephole instead of a combine pattern? > > I don't like RTL/text peepholes. They are just a last resort to fix > stuff that wasn't optimized properly in other passes and to clean up > remains from reload. You can fight against the compiler, or you can fight on the same side as the compiler. It's your choice. > What about that predicate? > > (define_predicate "low_io_mem" > (and (match_code "mem") > (match_test "low_io_address_operand (XEXP (op, 0))"))) > > Guess it operates the same because the drag-volatile-over-volatile > happens not in recog(_for_combine) but already when combine > synthesizes new patterns. As combine juggles with data flow, it must > not exchange volatiles. That's all. The backend will know if it's ok > to place a specific operand into a specific insn or not. > > And skipping optimizations like these altogether because they are > uncomfortable to handle is the wrong direction, IMHO. OK, what is your proposed patch to combine? Maybe it is easy to make it do what you want. I haven't looked. Ian
