This is the mail archive of the 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: asm, 'r' constraint, floating point registers?

> Date: Thu, 11 Oct 2001 08:43:57 -0700
> To:
> From: Zack Weinberg <>

> I've been talking off list with a user about his asm() problems and
> discovered something odd.

> If you write

>   int n;
>   asm ("frob %0" : "+r" (n));

> one would generally expect n not to be put into a floating point
> register.

?  Why?  This sounds like a misconception.  "r" is a constraint that means:

@cindex @samp{r} in constraint
@cindex registers in constraints
@item @samp{r}
A register operand is allowed provided that it is in a general

That is all, and that is it.  If you want a particular register, or a
subset of registers, you must _ask_ for it.  You _must_ use a
constraint that exactly names what register (or subset of registers)
you want.  From the doc, we can understand how to control this, and
the effect we are seeing:

@item HARD_REGNO_MODE_OK (@var{regno}, @var{mode})
A C expression that is nonzero if it is permissible to store a value
of mode @var{mode} in hard register number @var{regno} (or in several
registers starting with that one).  For a machine where all registers
are equivalent, a suitable definition is

@end smallexample

You need not include code to check for the numbers of fixed registers,
because the allocation mechanism considers them to be always occupied.

@cindex register pairs
On some machines, double-precision values must be kept in even/odd
register pairs.  You can implement that by defining this macro to reject
odd register numbers for such modes.

The minimum requirement for a mode to be OK in a register is that the
@samp{mov@var{mode}} instruction pattern support moves between the
register and other hard register in the same class and that moving a
value into the register and back out not alter it.

Since the same instruction used to move @code{word_mode} will work for
all narrower integer modes, it is not necessary on any machine for
@code{HARD_REGNO_MODE_OK} to distinguish between these modes, provided
you define patterns @samp{movhi}, etc., to take advantage of this.  This
is useful because of the interaction between @code{HARD_REGNO_MODE_OK}
and @code{MODES_TIEABLE_P}; it is very desirable for all integer modes
to be tieable.

Many machines have special registers for floating point arithmetic.
Often people assume that floating point machine modes are allowed only
in floating point registers.  This is not true.  Any registers that
can hold integers can safely @emph{hold} a floating point machine
mode, whether or not floating arithmetic can be done on it in those
registers.  Integer move instructions can be used to move the values.

On some machines, though, the converse is true: fixed-point machine
modes may not go in floating registers.  This is true if the floating
registers normalize any value stored in them, because storing a
non-floating value there would garble it.  In this case,
@code{HARD_REGNO_MODE_OK} should reject fixed-point machine modes in
floating registers.  But if the floating registers do not automatically
normalize, if you can store any bit pattern in one and retrieve it
unchanged without a trap, then any machine mode may go in a floating
register, so you can define this macro to say so.

The primary significance of special floating registers is rather that
they are the registers acceptable in floating point arithmetic
instructions.  However, this is of no concern to
@code{HARD_REGNO_MODE_OK}.  You handle it by writing the proper
constraints for those instructions.

On some machines, the floating registers are especially slow to access,
so that it is better to store a value in a stack frame than in such a
register if floating point arithmetic is not being done.  As long as the
floating registers are not in class @code{GENERAL_REGS}, they will not
be used unless some pattern's constraint asks for one.

> The user insists this is what happens.

I'm sure it did.

> Is this (a) a bug in his port,

Only he can answer that.  If he intended the 'r' constraint to allow
floating point regs, then no, it is not, if he didn't, then, yes it

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