Dave Korn wrote:
On 20 December 2006 02:28, Andrew Pinski wrote:
Paul Brook wrote:
Pretty much all optimization will change the behavior of your program.
Now that's a bit TOO strong a statement, critical optimizations like
register allocation and instruction scheduling will generally not change
the behavior of the program (though the basic decision to put something
in a register will, and *surely* no one suggests avoiding this critical
optimization).
Actually they will with multi threaded program, since you can have a case
where it works and now it is broken because one thread has speed up so much
it writes to a variable which had a copy on another thread's stack. So the
argument about it being too strong is wrong because timing matters now a
days. Instruction scheduling can cause the same issue as it forces a write
too early for another thread to act on.
Why isn't that just a buggy program with wilful disregard for the use of
correct synchronisation techniques?
Excuse me while I beat you on the head with a number of real-life
examples of *lock-free* algorithms. :-) Particularly lock-free queues
(google should help you find one that applies here), whose correct
operation is critically dependent on the order in which the loads and
stores are performed. This is a very real, entirely legitimate example
where the compiler thinking it knows how to do my job better than I do
is wrong.
We (in a major, commercial application) ran into exactly this issue.
'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
(it is a barrier across which neither the compiler nor CPU will reorder
things). Failing that, no-op cross-library calls (that can't be inlined)
seem to do the trick.
--
Matthew
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
