This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: volatile access optimization (C++ / x86_64)

On Sat, 2014-12-27 at 09:51 -0800, H.J. Lu wrote:
> On Sat, Dec 27, 2014 at 9:45 AM, Andrew Haley <> wrote:
> > On 27/12/14 16:02, 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]