[avr-gcc-list] Re: memcpy() : problem when passing destination pointer

[David Brown]

Pertti Kellomäki wrote:
> Joerg Wunsch wrote:
> > Vincent Trouilliez <address@hidden> wrote:
> > > IIRC it said volatile must be used to keep the compiler from
> > > optimizing away access to a variable that he thinks might be
> > > pointless. Like writing a variable that is never read back.
> >
> > Nope, if the variable is a global one, it will always be written.
>
> I'm not a C expert so I might be out of my depth here, but
> wouldn't it be legal for the C compiler to optimize away
> even global variables? Some time ago there was some talk
> about a possible AVR port of LLVM, and this is exactly the
> kind of thing I would expect LLVM's link time optimization
> to do.

It is legal for the compiler to optimise away a global variable store if 
it knows that the variable is never read, or if it can be sure that 
every time it *is* read, its value is available some other way.  This 
can be the case if the variable is static to the compilation unit (then 
the compiler knows everything about the variable), or if you are doing 
whole-program optimisation (such as with --combine and -fwhole-program), 
or if you are using a compiler that supports link-time optimisation or 
other global optimisers (such as LLVM or some commercial compilers).

Even without such global knowledge, it is still legal for the compiler 
to shuffle around stores to a non-volatile global.  If you store a value 
during a loop, for example, the compiler may postpone the stores until 
writing the final value at the end of the loop (or any other time when 
it loses track of the execution thread, such as at the end of a 
non-static function).

mvh.,

David