Matthew Fortune [off-list ref] writes:

quoted

On Thu, Dec 18, 2014 at 10:50:27AM -0800, David Daney wrote:

quoted

On 12/18/2014 07:09 AM, Markos Chandras wrote:

quoted

MIPS R6 changed the opcodes for LL/SC instructions and reduced the
offset field to 9-bits. This has some undesired effects with the "m"
constrain since it implies a 16-bit immediate. As a result of which,
add a register ("r") constrain as well to make sure the entire
address is loaded to a register before the LL/SC operations. Also use
macro to set the appropriate ISA for the asm blocks

Has support for MIPS R6 been added to GCC?

If so, that should include a proper constraint to be used with the new
offset restrictions.  We should probably use that, instead of forcing
to a "r" constraint.

In a non-public earlier discussion I've requested the same but somehow
that was ignored.

I must have missed that comment or not been on the thread.

quoted

We need suitable constraints or the alternatives will be very, very
ugly.

We can certainly discuss and investigate such things but there is a
general problem of a growing list of different size displacement fields
in load/store instructions.

IMO, there should at least be a constraint sufficient for the smallest
displacement supported by any instruction (in addition to the "r"
constraint which of course always works).  If there is an instruction
limited to, say, 10 bits of displacement, it will work with a constraint
enforcing 9 bits, if not ideally, and it will almost always be better
than resorting to "r".

Obviously you could just opt to keep things the way they are for uMIPS
today and leave the assembler to expand the instruction but my opinion
is that magic expanding assembler macros are infuriating. We have
however had to put support in binutils for many of them, simply to
keep enough software building to ease the transition.

I too find magic assemblers do more harm than good.

So, all this patch does is highlight that magic assembler macros have
been hiding this issue since micromips was added.

From your experiences will people invest the effort to look at the
size of a displacement field for all the memory operations in an inline
asm block and then choose an appropriate memory constraint?

I can't speak for others, but when I use inline asm, I always try to
pick the best possible constraint.

I'm obviously wary of putting things into GCC that are either only used
in a handful of places (or not at all). The alternative to constraints
is of course to try and reduce the need for inline asm and offer builtins
for specific instructions or more complex operations.

If gcc is to implement the __atomic_* operations properly, it will need
suitable constraints for internal use.  I see no reason not to document
these for others as well.

-- 
Måns Rullgård
mans@mansr.com