This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64


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.
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]