Hard registers in RTL templates, -fomit-frame-pointer

[Ian Dall <ian at beware dot dropbear dot id dot au>]

I am trying to track down the cause of incorrect code generation
with the -fomit-frame-pointer option for the ns32k.

What happens is 

(insn 20 19 21 (set (reg:SI 1 r1)
        (plus:SI (reg/f:SI 24 fp)
            (const_int -36 [0xffffffdc]))) 60 {*frame_addr} (nil)
    (nil))

after local register allocation gets translated to

(insn 20 18 22 (set (reg:SI 1 r1)
        (plus:SI (reg/f:SI 25 sp)
            (const_int 40 [0x28]))) 60 {*frame_addr} (nil)
    (nil))

after global register allocation. This is wrong because it doesn't
match the pattern for "*frame_addr", which is:

(define_insn "*frame_addr"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=rm<")
	(plus:SI (reg:SI 24)
		 (match_operand:SI 1 "immediate_operand" "i")))]
  "GET_CODE (operands[1]) == CONST_INT"
  "addr %c1(fp),%0")


There is a corresponding "*stack_addr" which would match.  I know one
way I can fix this: replace the hard register number with a match_operand
which can only match fp or sp, then make the assembly generation conditional
on REGNO (operands[...]).

The question I have is is this the Right Thing To Do (tm). I notice no
prohibition against hard register numbers in RTL templates in the
documentation and they are quite widely used in most machine
descriptions. If it is the right thing to do, how far do I go? Should I
eliminate all such hard register numbers? Only references to sp or fp?

I guess the global register allocation pass is too late to be making
major optimisations, but at the very least, it should be checking that
the insn is still legal after substituting a sp expression for a fp
expression, and it should be possible to look for a new insn which can
match.

Ian