Ian Lance Taylor wrote:
Georg-Johann Lay writes:
Is insn combine allowed to match the insn because from combine's
perspective just a CONST_INT (i.e. low_io_address_operand) is moved
across the access of UDR0?
Yes.
Or is this a bug in insn combine?
No.
If combine is right -- and thus the pattern is wrong -- how must the
insn be rewritten to produce respective instructions?
The backend must define and use a new recog predicate which recognizes
(mem:QI x)
where x satisfies low_io_address_operand. The predicate should also
check that its operand satisfies general_operand. E.g., something along
the lines of
(define_predicate "low_io_mem"
(and (match_operand 0 "general_operand")
(and (match_code "mem")
(match_test "low_io_address_operand (XEXP (op, 0))"))))
Ian
Thanks for outlining a solution, but I don't understand it.
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?
Or rephrased: What's the difference between general_operand and
memory_operand with respect to volatile_ok?
Johann
