redriver jiang <jiang.redri...@gmail.com> writes:
> test3.c:27: error: insn does not satisfy its constraints:
> (insn 52 51 32 0 (parallel [
> (set (reg:HI 16 BASE0)
> (plus:HI (reg:HI 16 BASE0)
> (const_int -2 [0xfffffffe])))
> (clobber (scratch:QI))
> ]) 9 {*addhi3} (nil)
> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 20 BASE2)
> (const_int -2 [0xfffffffe]))
> (nil)))
> test3.c:27: internal compiler error: in reload_cse_simplify_operands,
> at postreload.c:391
Looks like this insn didn't get a register at all. Reload can
sometimes generate add insns directly, which could perhaps cause this
to happen.
> I think I may not understand the usage of "match_scratch" properly,
> and I make the ACC hard register to be clobbered in rtl generation
> pass:
>
> (define_expand "addhi3"
> [(parallel [(set (match_operand:HI 0 "nonimmediate_operand" "")
> (plus:HI (match_operand:HI 1 "nonimmediate_operand" "")
> (match_operand:HI 2 "general_operand"
> "")))
> (clobber (reg: QI REG_ACC))])]
> ""
> "")
>
> the former problem disappeared.
I would do it that way. There isn't too much point to forcing the
register allocator to allocate a scratch register when you already
know what the register has to be. It can make sense to allocate a
normal register even if the register is fixed, because that will let
reload move the value onto the stack if necessary. But I can't see
any reason to allocate a fixed scratch register.
Ian
