On Sat, Aug 4, 2012 at 8:27 AM, Sean Kelly <[email protected]> wrote: > On Aug 1, 2012, at 10:25 AM, Walter Bright <[email protected]> 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 <[email protected]> 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. Regards, Alex _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
