[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: [avr-gcc-list] Re: memcpy() : problem when passing destination pointer
Date: Thu, 12 Feb 2009 20:45:05 +0100
User-agent: Thunderbird (Windows/20081209)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]