This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: volatile access optimization (C++ / x86_64)
- From: DJ Delorie <dj at redhat dot com>
- To: <Paul_Koning at dell dot com>
- Cc: matt at godbolt dot org, gcc at gcc dot gnu dot org
- Date: Mon, 5 Jan 2015 16:11:06 -0500
- 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> <xnvbkldsgz dot fsf at greed dot delorie dot com> <CAFWXXN2phpRE3vmrN1-3zDwheEzH3mygxVP93k8cQNeFnX8DVg at mail dot gmail dot com> <201501051847 dot t05Il2bc009156 at greed dot delorie dot com> <2A7339D5-C38F-4FFF-95E3-F82B16EDF1DE at dell dot com>
> To try to generalize from that: it looks like the operating
> principle is that an insn that expands into multiple references to a
> given operand isnât volatile-safe, but one where there is only a
> single reference is safe?
No, if the expanded list of insns does "what the standard says, no
more, no less" as far as memory accesses go, it's OK. Many of the MSP
macros do not access memory in a volatile-safe way. Some do.
If you have a single opcode that isn't volatile-safe (for example, a
string operation that's interruptable and restartable), that wouldn't
be OK despite being a single insn.
So it's kinda mechanical, but not always.