AVR 16-bit I/O access order fix, PR target/20288

[Paul Schlie]

> Marek Michalkiewicz wrote: I've just committed this to mainline ...
> Some background: on the AVR, some 16-bit I/O registers require specific
> access order (read low byte first, write high byte first).  This has
> been the case in avr-gcc for a long time when the address was constant
> (which is the most common case), but was not guaranteed when volatile
> memory (such as I/O registers) was accessed indirectly through pointers.

Hi Marek, Although not likely a big deal, but just in case it hadn't been
considered: unlike the constant addresses which uniquely reference atmel's
defined i/o registers; pointers reference the entire memory space, including
portion mapped externally which may have been used to interface to external
peripherals which may, although unlikely, rely on it's previous behavior?

Personally don't mind much either way; although believe the compiler's
object access sequencing shouldn't be relied upon to satisfy a peripheral's
interface idiosyncrasies; so will likely simply continue to explicitly
specify sequences as required, but understand others may feel otherwise.

Out of curiosity, any insight how to query BLKmode operand's MEM_READONLY_P
property, as it seem to get lost when references are converted to BLKmode?

This would seem necessary to enable the optional simple allocation of
read-only const data into progmem, and then simply identify corresponding
references to it via it's MEM_READONLY_P property, just as you had used
MEM_VOLATILE_P to identify volatile memory reference operands; so suspect
it should be retained for BLKmode operands as well, and may simply be a bug?