On Thu, 29 Jun 2017, Andrew Haley wrote: > On 29/06/17 18:35, Alexander Monakov wrote: > > I think a practical approach is to give the user a degree of control by > > introducing a tri-state compiler option controlling how double-word atomics > > are to be emitted: > > I see what you mean, but I think it's a very bad idea for command line > options to fundamentally affect language semantics in this way. Sure, > they can control optimization and processor versions, but change the > behaviour of what a program means? Is that a good thing? I'm not sure what you mean here. The first option preserves the lousy status quo, the third option does not introduce traps, so as far as I can tell only the second option does something that counts as "affecting language semantics", by *potentially* introducing traps. But if the program by construction never executes an atomic load on a readonly object in the first place, implementing the load via CAS is not observable on the language level. So consider that the second option helps to communicate to the compiler this non-trivial guarantee, which the optimizer cannot easily deduce on its own. And there's plenty of such options with similar motivation: -fwhole-program, -fno-math-errno, -fno-exceptions, etc. They all tell the compiler something it cannot know, improve code generation, lead to breakage if misused. Alexander
