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: <Paul_Koning at Dell dot com>
- To: <dj at redhat dot com>
- Cc: <matt at godbolt dot org>, <gcc at gcc dot gnu dot org>
- Date: Mon, 5 Jan 2015 21:41:13 +0000
- 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> <201501052111 dot t05LB6nx014252 at greed dot delorie dot com>
> On Jan 5, 2015, at 4:11 PM, DJ Delorie <dj@redhat.com> wrote:
>
>
>> 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.
Ok, but the converse â if the general_operand is accessed by more than one instruction, it is not safe â is correct, right?
>
> So it's kinda mechanical, but not always.