This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: The usage of the "clobber "match_scratch""
- From: Ian Lance Taylor <iant at google dot com>
- To: redriver jiang <jiang dot redriver at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 27 Apr 2010 07:56:51 -0700
- Subject: Re: The usage of the "clobber "match_scratch""
- References: <j2j714984df1004270540q7b030084x57ff7ee59ad2bb@mail.gmail.com>
redriver jiang <jiang.redriver@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