volatile correctness: combine vs. target.md

[Ian Lance Taylor]

Georg-Johann Lay <avr@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