Re: -frename-registers on d30v

[Michael Meissner <meissner at cygnus dot com>]

On Wed, Nov 22, 2000 at 05:23:21PM -0800, Richard Henderson wrote:
> On Wed, Nov 22, 2000 at 01:17:28PM -0500, Michael Meissner wrote:
> > I've been working mostly on a branch for the last couple of months, so
> > I don't know how widespread the wreakage is, but -frename-registers
> > doesn't work on the d30v (testsuite/gcc.c-torture/compile/cmpdi-1.c
> > when compiled with -O3 -frename-registers).
> 
> The problem exhibited in this test case is that there
> is a hole in the operands for 
> 
> (define_insn "*movcccc_signed_true"
>   [(set (match_operand:CC 0 "flag_operand" "=f,f")
>         (if_then_else:CC (match_operand:CC 1 "br_flag_operand" "f,f")
>              (match_operator:CC 3 "srelational_si_operator"
>                [(match_operand:SI 4 "gpr_operand" "d,d")
>                 (match_operand:SI 5 "gpr_or_constant_operand" "dI,i")])
>              (match_dup 0)))]
> 
> Note the lack of an operand 2.
> 
> I could swear that this is illegal, and I'm quite surprised
> that reload didn't crash on it.
> 
> What is consensus?  Should the operands be compressed (in which case
> an error in genrecog would be appropriate), or should this be handled
> (in which case regrename can check for null operand_loc).

I've certainly been burned by this more than once, and think genrecog or
somebody else should complain.  Note, even if you renumber the
operands/operators, it still fails due the unrelated bug of using 'f' for the
br_flag_case (on the d30v, only flags f0 and f1 can be used in conditional
execution).  The define_cond_exec at the bottom of d30v.md had the same
problem.  I fixed both of these with a new patch.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482