This is the mail archive of the
mailing list for the GCC project.
Re: volatile access optimization (C++ / x86_64)
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Paul Koning <Paul_Koning at dell dot com>, matt at godbolt dot org, GCC Development <gcc at gcc dot gnu dot org>
- Date: Sat, 27 Dec 2014 09:51:29 -0800
- Subject: Re: volatile access optimization (C++ / x86_64)
- Authentication-results: sourceware.org; auth=none
- References: <CAFWXXN3quEdSnaoWuPcQn2k-F99Yaw+6=NqgFgcu9ABpv5ZD3Q at mail dot gmail dot com> <549DE09B dot 8060502 at redhat dot com> <CAFWXXN0V9yvNTpcz54DCK237KPURQs1XkaHcQZK5Eoj_VCj0OA at mail dot gmail dot com> <549DED1B dot 3070006 at redhat dot com> <51562738-4E3B-4EFC-9EE3-DE17AE4C2142 at dell dot com> <549EF04E dot 8030003 at redhat dot com>
On Sat, Dec 27, 2014 at 9:45 AM, Andrew Haley <email@example.com> wrote:
> On 27/12/14 16:02, Paul_Koning@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
>> 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?