This is the mail archive of the gcc-patches@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]

Re: A new patch for floating point conditional mov on PPo


> H.J. Lu writes:
> 
> > It seems to me that the second (a < b) is never deleted even for
> > 
> > int
> > foo (int x, int i, int y, int z)
> > {
> >   if (y > z)
> >     x = 0;
> > 
> >   if (y > z)
> >     i = 0;
> > 
> >   return x * i;
> > }
> 
> In your example you are moving zero into x which notice_update_cc
> considers to clobber cc0.  As a result the second comparison isn't
> deleted.  This is currently only the case when moving a constant,
> and this may change in the future as notice_update_cc becomes
> smarter (since moving a constant on the i386 processor doesn't
> really clobber cc0).

It doesn't matter. Here is the comment on notice_update_cc ():

/* Set the cc_status for the results of an insn whose pattern is EXP.
   On the 80386, we assume that only test and compare insns, as well
   as SI, HI, & DI mode ADD, SUB, NEG, AND, IOR, XOR, ASHIFT,
   ASHIFTRT, and LSHIFTRT instructions set the condition codes usefully.
   Also, we assume that jumps, moves and sCOND don't affect the condition
   codes.  All else clobbers the condition codes, by assumption.

   We assume that ALL integer add, minus, etc. instructions effect the
   condition codes.  This MUST be consistent with i386.md.

   We don't record any float test or compare - the redundant test &
   compare check in final.c does not handle stack-like regs correctly.
*/

notice_update_cc assumes conditional move clobber cc0. Yes, we may be
able to optimize it for some/all int conditional moves. But we can
always let notice_update_cc know fp conditional moves clobber cc0.

> 
> > I think it is a good thing since the compiler may not know if
> > the body of if_then_else will clobber cc0. If there is a way
> > to tell the compiler about clobbering cc0, we just tell the
> > compiler that the fp conditional move may clobber cc0.
> 
> It isn't safe to assume that the second comparison will not be
> removed.  You must explicitly tell gcc when you clobber cc0,
> usually this is handled in notice_update_cc.
> 

That is exactly what notice_update_cc () does now. So my patch
is safe with the current notice_update_cc ().

H.J.


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