On 30/06/17 09:40, Andrew Haley wrote: > On 29/06/17 20:46, Alexander Monakov wrote: >> 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. > > Indeed it does. > >> 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. > > Well, yes, but you can execute an atomic load on a read-only section, so > it is observable; and thus the command-line options have an > effect on semantics. Which was the point of my proposal yesterday. You need a new type which the compiler knows has never been placed in a a read-only section. There's no mechanism for achieving that with the existing type because legacy objects will always exist. And furthermore, such legacy objects will use a different locking mechanism on such types. R. > >> 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. > > Perhaps so. However, it would make more sense and be more maintainable > if, rather than use a command-line option, a variable attribute was used > to tell the compiler what this program is supposed to mean. IMO. >