This is the mail archive of the gcc@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: Optimization of conditional access to globals: thread-unsafe?


Dave Korn wrote:
On 27 October 2007 18:27, Darryl Miles wrote:
The "unintended write-access" optimization is a massive headache for
developers of multi-threaded code.

But it's a boon for the autovectoriser, because it means it can transform code with a branch into straight-line code.

Then write to the stack or a register, but not to heap when the programmer didn't explicitly permit the compiler to do so because no memory targeted lvalue expression was to be executed.


This basic rule about is what a threaded programmer expects of the C language, even if there is no written law in C99.


I don't want to stop people using this optimization technique there will always be a useful case for it, I just want to be able to turn that one off, but keep all other optimizations.



...SNIP...



So much control that I would also like to see a pair of
__attribute__((optimization_hint_keywords)) attached to the variable
declaration to provide fine grain control.  Such a solution to the
problem would keep everybody happy.

How about attaching the 'volatile' keyword to the variable?

No we are _HAPPY_ to allow "may optimize read access mode" but not happy to allow "may optimize read and write access mode" (as per my previous description). Volatile can not differentiate this. Nor can volatile instruct the compiler which method to use to perform the load or store, for example a 64bit long long type on i386.


Volatile has its uses but it pretty much a sledgehammer to the problem domain.


Hmm... on this point there can be a problem.  There are 2 major types of
access read from memory (load) and write to memory (store).  It is very
possible to end up performing an optimistic read; only to throw away the
value contained due to a compare/jump.  This is usually considered a
safe optimization.

As embedded programmers who have to deal with registers containing auto-resetting status bits have known for many years, this is not a safe optimisation at all. We use 'volatile' to suppress it.

It is safe for general programming usage which was the original case. See my comment (which you failed to cite) over the use of volatile for the situation you describe. I've already covered this case for you.



NB Marking the variable 'volatile' does not mean anything useful in the
situation you are in.  The exact meaning of what 'volatile' is can be a
problem between compilers, but in the case of GCC it can stop the
re-ordering and the caching of value in register aspect of your entire
problem.  But it will never enforce the method used to perform the
load/store, not will it (at this time) stop the unintended write-access.

Huh? When I tried compiling the test case, it did exactly that. Hang on, I'll check:

We differ slighting on our understanding of volatile. It does not provide exactly what a threaded programmer wants, even thought to you it addresses the problem when used with GCC in the cases you have tried.


Your example you cite is coincidental, thats just how GCC generates code.


Darryl



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