This is the mail archive of the
mailing list for the GCC project.
Re: [patch,mips] avoid invalid register for JALR
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Sandra Loosemore <sandra at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 13 May 2014 22:41:48 +0100
- Subject: Re: [patch,mips] avoid invalid register for JALR
- Authentication-results: sourceware.org; auth=none
- References: <53727BC3 dot 3060600 at codesourcery dot com>
Sandra Loosemore <email@example.com> writes:
> When I was trying to benchmark another patch (which I'll be sending
> along shortly) with CSiBE for -mabi=64, I ran into an assembler error
> like this:
> /tmp/ccJv2faG.s: Assembler messages:
> /tmp/ccJv2faG.s:1605: Error: a destination register must be supplied
> `jalr $31'
JALR patterns should have an explicit clobber of $31, which I thought
was also supposed to stop $31 from being used as the call address. E.g.:
int foo (void)
typedef void (*type) (void);
register type fn asm ("$31");
asm ("foo %0" : "=r" (fn));
gives the expected shuffle:
# 5 "/tmp/foo.c" 1
# 0 "" 2
If you change the asm to some other random register then the JALR
uses it directly. Do you have a testcase?
> Indeed, GCC is generating invalid code here; the single-operand JALR
> instruction doesn't permit the use of $31 because it is already the
> implicit destination register. The attached patch introduces a new
> register class JALR_REGS to represent the valid set of registers for
> this instruction, and modifies the "c" register constraint to use it.
> I had some difficulty in regression-testing this patch because of
> unrelated problems on trunk in the past week -- at first I was getting
> ICEs due to a null pointer dereference in tree code, then when I tried
> again a couple days later trunk was not even building.
Could you give more details?