This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -fno-tree-cselim not working?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]