volatile correctness: combine vs. target.md

[Georg-Johann Lay]

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