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. > 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. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
