This is the mail archive of the
gcc@gcc.gnu.org
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 16:10:20 -0400
- Subject: Re: Optimization of conditional access to globals: thread-unsafe?
- References: <Pine.LNX.4.64.0710281753210.23011@wotan.suse.de.suse.lists.egcs> <20071028.180108.71876074.davem@davemloft.net.suse.lists.egcs> <02e701c819c7$be985620$2e08a8c0@CAM.ARTIMI.COM.suse.lists.egcs> <20071028.183401.197068473.davem@davemloft.net.suse.lists.egcs> <20071029162032.GA10611@synopsys.com.suse.lists.egcs> <47260E97.4020309@adacore.com.suse.lists.egcs> <p73zly13dwf.fsf@bingen.suse.de> <472639BF.2000204@adacore.com> <20071029200324.GA1428@one.firstfloor.org>
Andi Kleen wrote:
On Mon, Oct 29, 2007 at 03:51:27PM -0400, Robert Dewar wrote:
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
icache misses are hard in general and agreed the compiler cannot
do too much about them (except for trying not to generate too bloated
code in general)
But adding gratuious dcache misses is a completely different thing.
That is something the compiler has control over and should just
not do.
Generally sounds right, though there are cases where this is OK (I
think for example there are examples of optimizations of priming
the explicit pipeline of the i860 may generate an extra dcache
miss but outside the loop, and conceivably that could be worth while).
-Andi