This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [new-regalloc] fix_truncdi_nomemory, fix_truncdi_memory.
- From: Jan Hubicka <jh at suse dot cz>
- To: Denis Chertykov <denisc at overta dot ru>
- Cc: Michael Matz <matz at suse dot de>, gcc-patches at gcc dot gnu dot org,Jan Hubicka <jh at suse dot cz>
- Date: Mon, 19 Aug 2002 19:41:17 +0200
- Subject: Re: [new-regalloc] fix_truncdi_nomemory, fix_truncdi_memory.
- References: <auto-000003381565@overta.ru>
> Hello Michael, Jan.
>
> I have successfully bootstrapped C,C++,f77,java with the following
> patch.
> (I have bootstrapped new regalloc with enabled pre-reload on
> i586-pc-linux-gnu.)
>
> Few months ago I have already asked about constraints from
> fix_truncdi_nomemory and fix_truncdi_memory.
> Problem:
> (define_insn "fix_truncdi_memory"
> [(set (match_operand:DI 0 "memory_operand" "=m")
> (fix:DI (match_operand 1 "register_operand" "f")))
> -----------------------------^^ No mode definition here (I know why)
> (use (match_operand:HI 2 "memory_operand" "m"))
> (use (match_operand:HI 3 "memory_operand" "m"))
> (clobber (match_scratch:DF 4 "=&1f"))]
> ---------------------------^^ ----^^^ '=&1' refers to operands[1]
> "TARGET_80387 && FLOAT_MODE_P (GET_MODE (operands[1]))
> && (!SSE_FLOAT_MODE_P (GET_MODE (operands[1])) || !TARGET_64BIT)"
> "* operands[5] = operands[4]; return output_fix_trunc (insn, operands);"
> [(set_attr "type" "fistp")])
>
> operands[4] have a mode definition (DFmode), but operands[4] can be
> equal to operands[1] which can have different mode - IMHO it's wrong.
> Also I can't understand differences between '=&1f' and just '=f'
> What is '=&1f':
> 1. =&1;
> it's operand which will be same as operands[1] and "the
> previous value is discarded and replaced" like gcc info say.
> 2. =&f;
> it's any register exclude register from operands[1].
>
> So, =&1f is any discarded and replaced register exclude operands[1]
> or operands[1] which will be discarded and replaced.
> IMHO: =&1f equal to =f.
>
> Am I wrong ?
I see now the thread :)
The semantic of =&1f is that the operand can be eighter equivalent to
input operand 1 (so the register is clobbered in place) or some other FP
register, but different from all the input registers.
So & is ignored for "1" but holds for "f".
It is different from "=f" that may be same to other floating point input
register. As I see here, there is only one FP input operand, so the
semantic is equivalent for this pattern, but new regalloc should
probably keep the "=&1f" style working as it is usefull in other cases
and always worked and is used by some other ports too.
Honza