[dmd-internals] Regarding deprecation of volatile statements
Alex Rønne Petersen
xtzgzorex at gmail.com
Mon Aug 6 18:22:11 PDT 2012
On Sat, Aug 4, 2012 at 8:27 AM, Sean Kelly <sean at invisibleduck.org> wrote:
> On Aug 1, 2012, at 10:25 AM, Walter Bright <walter at digitalmars.com> wrote:
>> To reiterate, this is why I need to know what problem you are trying to address, rather than going at it from the solution point of view.
> I think the original request was for there to be some way to prevent compiler optimization of certain plain old loads/stores:
> On Jul 23, 2012, at 2:28 PM, Alex Rønne Petersen <xtzgzorex at gmail.com> wrote:
>> And further: How are people *really* supposed to prevent compiler
>> reordering in modern D2 programs (without using atomics; they are
>> expensive and wasteful for this)?
> This can be useful for tuning concurrent algorithms to avoid unnecessary synchronized operations and also for the occasional store where the ordering isn't important so much as that it simply be issued at all. Using DMD, my suggestion would be to use atomicStore!msync.raw, which performs a plain old store in asm and uses the fact that DMD doesn't optimize across asm blocks to make the operation behave in the desired manner. But I believe GDC and LLDC may both optimize more aggressively with respect to asm code and so this assumption doesn't hold universally. Personally, if I could be guaranteed that at least specific asm blocks would be treated as volatile by the compiler in that there's no code movement across them, etc, then that would probably be enough.
The problem with that is that D inline assembly only works in DMD and
LDC and for x86 only.
Adding a couple of load/store intrinsics seems to be the most portable
and less controversial approach.
More information about the dmd-internals