On Sat, 2014-12-27 at 09:51 -0800, H.J. Lu wrote: > On Sat, Dec 27, 2014 at 9:45 AM, Andrew Haley <a...@redhat.com> wrote: > > On 27/12/14 16:02, paul_kon...@dell.com wrote: > >> > >> In the case of volatile variables, the external interface in > >> question is the one at the point where that address is implemented — > >> a memory cell, or memory mapped I/O device on a bus. So the > >> required behavior is that load and store operations (read and write > >> transactions at that interface) occur as written. > > > > I believe this is incorrect. For accesses to reach memory in program > > order on most architectures would require volatile memory references > > to emit memory barriers, and the C committee decided not to require > > that. > > > >> If a processor has add instructions that support memory references > >> (as in x86 and vax, but not mips), such an instruction will perform > >> a read cycle followed by a write cycle. So as seen at the critical > >> interface, the behavior is the same as if you were to do an explicit > >> load, register add, store sequence. Therefore the use of a single > >> add-to-memory is a valid implementation. > > > > I agree. > > > > Can we add a target hook so that combine will allow a single > add-to-memory instruction for volatile memory reference on > architectures like x86?
Just don't use 'general_operand' in the predicates. On SH I had to do that so that combine would merge sign extending memory loads (expanded as QI/HImode loads) and explicit sign extensions. Cheers, Oleg
