Re: asm volatile statement reordering

[David Brown <david at westcontrol dot com>]

On 17/10/17 11:55, Xi Ruoyao wrote:
> On 2017-10-17 11:13 +0200, David Brown wrote:
>> On 17/10/17 09:58, Andrew Haley wrote:
>>> On 17/10/17 08:32, Jeffrey Walton wrote:
>>>> GCC guesses wrong on occasion. It will remove code that has value that
>>>> but does not produce an output because the language does not allow us
>>>> to express it.
>>>>
>>>> The C language lacks what we need to express what we need to do. Its a
>>>> failure of the C (and C++) committees. Its not a GCC failure.
>>
>> gcc is a tool that goes above and beyond C and C++.  It is not /just/ a
>> C and C++ compiler.  After all, the language standards don't have "asm"
>> at all.
>>
>> It is important to remember that gcc is used for many types of
>> programming - in particular, it is the most used tool for embedded
>> programming.  And the point of gcc is to be a useful tool for its users.
>>  So if users have trouble getting the ordering they need from gcc, then
>> it /is/ a gcc failure.  Sure, it would be nice if the C and C++
>> languages gave the features needed (and C11 and C++11 atomics and fences
>> go some way towards that), but it is up to gcc to handle things that are
>> clearly implementation-dependent behaviour, and compiler extensions.
>> And users use /gcc/ - they don't use a standards document.
>>
>> As gcc gets smarter with its optimisations, and doing more code
>> re-organisation, I see more and more problems in embedded code.  We need
>> guarantees about code order - either rules that we /know/ gcc will
>> follow, or additional features to fill the gaps.  gcc developers can't
>> just tell embedded users "You see that code you had that worked fine
>> with gcc 3 to gcc 7?  Well, it won't work now with gcc 8.  You should
>> have studied ISO 9899:201x section 5.1.2.3p6 better".
>>
>> Don't get me wrong here - I am not trying to demand features from gcc.
>> Nor am I suggesting that users (embedded developers or otherwise) should
>> not learn the details of the C language, or that they should not have to
>> read the gcc documentation.
> 
> Yes.  So we need a low-level routine library for embedded environment.
> Either reuse an existing one (for example avr-libc), or customize one for
> your platform.  If it's really necessary, write routines in pure assembly.

Libraries such as avr-libc are written with gcc, in C with gcc
extensions and possibly inline assembly.  Those developers suffer from
exactly the same issues.  And pure assembly does not help - it is the
interaction between assembly and C that is at issue here.

> 
> We can't forbid GCC to perform new optimizations.  The users who don't
> care about embedded developing would be angry.

I don't want to forbid new optimisations in gcc - I am very happy to see
steadily more optimisations, as are most embedded developers.  Better
optimisations means we embedded developers can do more with less
hardware - smaller code means cheaper chips, and faster code means lower
power.

What I want is to be sure that I can use these optimisations without
risking incorrect code.

> 
>> I am trying to establish exactly what gcc does, and what guarantees it
>> may or may not give.  Based on that, I can see if current solutions in
>> source code are strong enough, or if they need workarounds, and if I
>> should be filing an enhancement request.
>>
>>>
>>> I disagree.  If you want a bunch of asms to execute in a particular
>>> order, add a memory clobber or some dependencies.  It's not difficult
>>> once you have the understanding.  In this particular case, fixing it
>>> is trivial, and there are many ways to do it.
>>>
>>
>> I understand about dependencies.  (I also know about memory clobbers,
>> but these tend to be a fairly blunt instrument and can lead to wasted
>> cpu cycles, especially on RISC cpus with lots of registers.  When you
>> are dealing with things like critical sections with interrupts disabled,
>> you are often trying to minimise the cycle time.)  My solution to this
>> particular ordering problem is:
> 
> I performed a simple test on x86_64.  With -O GCC kept "status" in
> register.  The clobber just tells GCC there is a dependency and won't
> slow down the program.

The cost of memory clobbers only appears when you have data that could
have been kept in registers, but is forced out (with extra loads and/or
extra stores) due to the clobber.  You don't see it on simple tests, and
you get it much more often on devices with more registers.

> 
>>     uint32_t status;
>>     asm volatile ("mrs %0, PRIMASK" : "=r" (status) :: );
>>     asm volatile ("cpsid i" :: "" (status) :);
>>
>>     foo();
>>
>>     asm volatile ("msr PRIMASK, %0" :: "r" (status) : );
>>
>>
>> The dependency on "status" in the "cpsid i" assembly line ensures that
>> it must be ordered after the "save PRIMASK" line.  However, I know of no
>> clear way - other than a potentially costly memory clobber - of forcing
>> the ordering of the "cpsid i" assembly before foo(), and the "restore
>> PRIMASK" line after foo().
>>
>> But all my testing suggests that asm volatile statements with no outputs
>> are not moved past each other, or past other observable behaviour
>> (volatile memory accesses, external functions that might have such
>> accesses, etc.).
>>
>> If that suggestion is true, then the solution above is not only a
>> correct fix, but it also results in optimal code - while a memory
>> clobber is definitely sub-optimal.
>>
>>
>>
>>