[Top] [All Lists]

Re: [PATCH] incorrect asm constraints for ll/sc constructs

To: "Kevin D. Kissell" <>
Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs
From: Ralf Baechle <>
Date: Sat, 26 May 2001 19:23:40 -0300
Cc: Daniel Jacobowitz <>,
In-reply-to: <00c901c0e631$4bcebd80$0deca8c0@Ulysses>; from on Sun, May 27, 2001 at 12:14:43AM +0200
References: <> <011801c0e55f$e4d39820$0deca8c0@Ulysses> <> <00c901c0e631$4bcebd80$0deca8c0@Ulysses>
User-agent: Mutt/1.2.5i
On Sun, May 27, 2001 at 12:14:43AM +0200, Kevin D. Kissell wrote:

> Fair enough.  It was an offhand remark.  But seriously, what does
> the "R" constraint mean here?  The only documentation I've got
> (
> says that "Q" through "U" are reserved for use with EXTRA_CONSTRAINT
> in machine-dependent definitions of arbitrary operand types.  When
> and where does it get bound for MIPS gcc, and what is it supposed
> to mean?  If I compile this kind of fragment using a "m" constraint,
> it seems to do the right thing, at least on my archaic native compiler.

Correct, "R" is a machine dependent constraint.  At least when it's working
right it's supposed to expand into offset(reg) where offset is limited
to 16 bits.  That's implemented in gcc/config/gcc/mips/mips.h's
EXTRA_CONSTRAINT macro.  In case of an "R" constraint gcc calls the
simple_memory_operand() function which will return 1 if the memory operand
fits into a single instruction.


<Prev in Thread] Current Thread [Next in Thread>