On Thu, 26 May 2011, Vladimir Makarov wrote:
> On 05/26/2011 04:47 AM, Hans-Peter Nilsson wrote:
> > On Wed, 25 May 2011, Vladimir Makarov wrote:
> > It sounds like you're saying that "the narrowest register
> > classes must be formed of registers for which there are trivial
> > instructions to move between registers inside the class"?
> >
> No it is wrong.  For example, SPARC FPCC (floating point control code
> registers) should form a uniform class but there are no trvial insns to move
> between registers inside the class.

Yah, the code was tweaked to explicitly handle that case by
excluding that condition for regclasses without subclasses.

Is the following update ok with you (and doc maintainers)?
It says what the code requires, and seems a simple enough rule.
It also fills a documentation gap at the narrow end of the
spectrum of register classes.  (I'll update the CRIS port to fit.)

If not, I can tweak the code instead (likely to also exclude the
test for the narrowest code class to which a register belongs),
and regtest that on the compilefarm machines, which IIRC should
cover all the arch's you tested.  But that'd require the code to
keep handling non-minimal regclasses with side-conditions on
moves as pressure classes, which seems less desirable to me, and
judging from your willingness to patch a target the other way, I
believe you agree. ;-)

Tested by generating and inspecting dvi and info.

gcc:
        * doc/tm.texi.in (Register Classes): Document rule for the narrowest
        register classes.
        * doc/tm.texi: Regenerate.

Index: tm.texi.in
===================================================================
--- tm.texi.in  (revision 174376)
+++ tm.texi.in  (working copy)
@@ -2327,6 +2327,11 @@ constraints is through machine-dependent
 You can define such letters to correspond to various classes, then use
 them in operand constraints.

+You must define the narrowest register class for a register so that
+class either has no subclasses, or that for some mode, the move cost
+between registers within the class are cheaper than moving a register
+in the class to or from memory (@pxref{Costs}).
+
 You should define a class for the union of two classes whenever some
 instruction allows both classes.  For example, if an instruction allows
 either a floating point (coprocessor) register or a general register for a

brgds, H-P

Reply via email to