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


> 
> > 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.
> 
> notice_update_cc may assume that conditional moves clobber cc0, however

I have verified that the current notice_update_cc will clear cc0 for
all conditional moves. Given

	if (x > y)
	   z = q;
	if (x > y)
	   i = j;

with conditional moves, int or fp, it becomes

	set cc0 (x > y)
	conditional move z
	set cc0 (x > y)
	conditional move i

final_scan_insn calls notice_update_cc on "conditional move z", which
will clear cc0. So the second "set cc0 (x > y)" won't be deleted because
it noticed that cc0 is clobbered by the previous insn.

> it doesn't assume that a integer comparison clobbers cc0.  When you
> emit the integer comparison you look ahead to see if a floating point
> conditional move is being performed in which case you setup cc0
> so that it reflects if the move should be performed or not.  Notice
> that at this point cc0 doesn't reflect the integer comparison mentioned
> in the RTL ... it instead merely reflects if the conditional move should
> be performed.

That is not a problem, see above.

> 
> It may be cleaner to implement this along the lines of ffssi2, or by
> keeping the comparison as part of the conditional move instruction.
> 
> > 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 would imagine that it's desirable to make notice_update_cc smarter
> about integer conditional moves.  I don't belive that cc0 has to be
> clobbered even in the case of floating point conditional moves based
> on unsigned integer comparisons or signed EQ / NE comparions.

It may not be hard to do. But it is an optimization which we can
implement after signed integer comparison is fixed.

-- 
H.J. Lu (hjl@gnu.org)


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