This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -fno-tree-cselim not working?
- From: Andi Kleen <andi at firstfloor dot org>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 25 Oct 2007 17:56:01 +0200
- Subject: Re: -fno-tree-cselim not working?
- References: <87myu7zf9a.fsf@willow.rfc1149.net.suse.lists.egcs> <de8d50360710250310r6f600a30i7a9cdc1a1220dd2e@mail.gmail.com.suse.lists.egcs> <2007-10-25-12-13-49+trackit+sam@rfc1149.net.suse.lists.egcs> <de8d50360710250319j47ee8938u242291aa5e95a955@mail.gmail.com.suse.lists.egcs> <m3k5pbqlxc.fsf@localhost.localdomain.suse.lists.egcs>
Ian Lance Taylor <iant@google.com> writes:
> It would be nice to figure out how gcc could improve matters. The
> answer is not going to be to disable certain optimizations.
It's just very questionable this particular transformation is a
optimization at all. Turning a shared cache line into an exclusive one
can be very expensive even on small MP systems. Also it increases
traffic on the bus even on uniprocessor systems.
For me it looks more like a mistuned optimization: if conversion is useful
for values in registers; but questionable for arbitary memory stores that are not
guaranteed to be in L1. The worst memory overhead will likely swamp what
ever pipeline advantages you can get from not jumping.
Or rather if it's done for stores it needs to guarantee cancel the
store in the not taken case (that is possible even on x86 by
redirecting the store using cmov to a temporary on the stack which
is likely in L1)
I guess that code just needs to cooperate better with the register allocator?
-Andi