This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -fno-tree-cselim not working?
- From: Ian Lance Taylor <iant at google dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: 25 Oct 2007 10:08:20 -0700
- 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> <p733avzqjce.fsf@bingen.suse.de>
Andi Kleen <andi@firstfloor.org> writes:
> 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?
The current code (noce_try_addcc in ifcvt.c) does not even consider
whether this conversion is being done for a store or not.
I agree that that is most likely an optimization bug that this
conversion is being for a store to a variable which is not on the
stack. This should be filed as an optimization bug (not a correctness
bug) in gcc bugzilla.
(This is of course orthogonal to the main issue of what gcc can do to
help code correctness.)
Ian