Why is targetm.fixed_condition_code_regs a function?

[Ian Lance Taylor]

Richard Earnshaw <rearnsha@arm.com> writes:

> > I returned two registers merely because the ix86 has two, but every
> > other target has one, and I thought it was quite unlikely that any
> > other target would ever have more than one.  The code is more
> > efficient when there is a known limitation on the number of condition
> > code registers, since otherwise there have to be some loops.  Since
> > those loops would be to a variable bound which would always in
> > practice be 1 or 2, I thought it was more efficient to just impose the
> > requirement.
> 
> On ARM we can have 2 now as well (a second one is used for VFP 
> comparisons), I'm not sure if it would be possible/likely to have another 
> one in a further coprocessor -- I doubt it could be ruled out entirely.

I guess my feeling is that we should cross that bridge if we come to
it.

> Incidentally, is there any reason why this bit of code in 
> cse_condition_code_reg:
> 
> 
>       if (reg_referenced_p (cc_reg_1, PATTERN (last_insn)))
> 	cc_reg = cc_reg_1;
>       else if (cc_reg_2 && reg_referenced_p (cc_reg_2, PATTERN 
> (last_insn)))
> 	cc_reg = cc_reg_2;
>       else
> 	continue;
> 
> couldn't be rewritten to use refers_to_regno_p rather than generating RTX 
> expressions for the CC register which may often be just thrown away?  It 
> might even make it possible to apply the optimization for modes other than 
> CCmode.

I think it could.  The mode is actually irrelevant--reg_referenced_p
doesn't care about it, and the optimization does occur for MODE_CC
modes other than CCmode.  I'll try it out.

Ian