Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

[David Brown]

On 08/12/16 21:55, Marcin Godlewski wrote:
> 
> 
> W dniu 2016-12-08 21:46:40 użytkownik Georg-Johann Lay <address@hidden> 
> napisał:
>> Marcin Godlewski schrieb:
>>> Dear all,
>>>
>>> Thanks for the reply to David. However I'm not trying to find a solution 
>>> for the described issue. What I'm trying to say in this e-mail is that this 
>>> part of Atmel documentation: 
>>> http://www.atmel.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reorder.html
>>>  is innacurate and should be corrected. The conclusion says:
>>>
>>>     memory barriers ensure proper ordering of volatile accesses
>>>
>>>     memory barriers don't ensure statements with no volatile accesses to be 
>>> reordered across the barrier 
>>>
>>> while it should say:
>>>
>>>     memory barriers ensure proper ordering of global variables accesses
>>>
>>>     memory barriers don't ensure local variables accesses to be reordered 
>>> across the barrier
>>
>> At least the "local" vs. "global" is not completely correct.  After
>> all it's about memory accesses, and it doesn't matter if the memory
>> is local (e.g. local static) or if you are dereferencing a pointer
>> (which might point to a local auto or to an object on heap).
> 
> Ok, let's define it "global" vs "automatic". After all it is all
> about the possibility that the memory can be shared. Global variables > in
general can be shared, automatic variables cannot. But for sure
> it's not the matter of volatile. A barrier that orders only volatile >
accesses is a nonsense - this is already guaranteed by the volatile
> itself.

Local variables that are only in registers, or are optimised away, are
still "automatic" and are unaffected by memory barriers.  And it is not
always easy to know whether a variable has gone in memory or not.  Even
if you take the address of a local variable, it may never move from a
register if the compiler can find a way to avoid it.

Memory barriers will affect all data that is in memory, and that can be
legally accessed as memory from within an assembly statement.  So global
(or file static) data is definitely ordered by a memory clobber,
regardless of whether or not it is volatile.  Local variables whose
/address/ has "escaped" (i.e., been assigned to global data, passed to
external functions, etc.) are also ordered.  Local variables which
remain local need not be ordered, I believe.

What the page here should really be saying here is that memory barriers
do not order /operations/ or /calculations/, only memory accesses.

Does that help?