This is the mail archive of the
mailing list for the GCC project.
Re: Optimization of conditional access to globals: thread-unsafe?
- From: Robert Dewar <dewar at adacore dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 29 Oct 2007 15:51:27 -0400
- Subject: Re: Optimization of conditional access to globals: thread-unsafe?
- References: <Pine.LNX.email@example.com> <firstname.lastname@example.org> <02e701c819c7$be985620$2e08a8c0@CAM.ARTIMI.COM.suse.lists.egcs> <email@example.com> <20071029162032.GA10611@synopsys.com.suse.lists.egcs> <47260E97.firstname.lastname@example.org> <email@example.com>
Andi Kleen wrote:
Robert Dewar <firstname.lastname@example.org> writes:
a) the standard allows the optimization (or rather does not forbid it)
Assuming it is an optimization. See http://gcc.gnu.org/ml/gcc/2007-10/msg00607.html
for a counter example. In general cache misses are so costly that anything
that risks introducing more is in general a bad idea.
Sure, well nearly every optimization has some case where it is a
pessimization (one interesting thing that happens is that if you
change the length of generated code in *any* way you may be unlucky
and cause a systematic instruction cache miss in a loop, inlining
can do this some times for example). But indeed, it is important
to evaluate a proposed optimization over a reasonable body of
tests, rather than going into the mode "look, I found this test
that speeds up 32.7% isn't that great? we definitely should put
this optimization in".