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 17:24:42 -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> <201501052111 dot t05LB6nx014252 at greed dot delorie dot com> <D5BF0890-C261-4956-9307-50A097FE6F7D at dell dot com>
> Ok, but the converse â if the general_operand is accessed by more
> than one instruction, it is not safe â is correct, right?
In general, I'd agree, but the ISO spec talks about "sequence points"
and there are times when you *can* access a volatile multiple times as
long as the state is correct at the sequence point. GCC won't, for
example, combine insns if it doesn't know if the combined insn follows
the sequence point rules correctly. This is in 5.1.2.3 in the C99
spec but that caveat mostly applies to non-memory-mapped volatiles;
memory-mapped ones are typically more strictly confined (6.7.3.6)
(which is the origin of the -fstrict-volatile-bitfields patch).
So, for example, if you had a volatile on the stack and a special
stack-relative insn to modify it, you would "know" it would be safe to
do so even if it doesn't meed 6.7.3.6. Or if you used atomics to
guard a multi-access macro to make it volatile-safe.