Andrew MacLeod <amacl...@redhat.com> writes: > I've been working for a while on understanding how the new memory > model and Atomics work, and what the impacts are on GCC.
Thanks for looking at this. One issue I didn't see clearly was how to actually implement this in the compiler. For example, speculated stores are fine for local stack variables, but not for global variables or heap memory. We can implement that in the compiler via a set of tests at each potential speculated store. Or we can implement it via a constraint expressed directly in the IR--perhaps some indicator that this specific store may not merge with conditionals. The latter approach is harder to design but I suspect will be more likely to be reliable over time. The former approach is straightforward to patch into the compiler but can easily degrade as people who don't understand the issues work on the code. I don't agree with your proposed command line options. They seem fine for internal use, but I think very very few users would know when or whether they should use -fno-data-race-stores. I think you should downgrade those options to a --param value, and think about a multi-layered -fmemory-model option. E.g., -fmemory-model=single Assume single threaded execution, which also means no signal handlers. -fmemory-model=fast The user is responsible for all synchronization. Accessing the same memory words from different threads may break unpredictably. -fmemory-model=safe The compiler will do its best to protect you. Ian